API returns invalid JSON booleans
tunloop opened this issue · comments
SABnzbd version
4.2.1
Operating system
Debian 12
Using Docker image
None
Description
I was using the API and noticed that it uses the Python JSON capitalized boolean values. I know this may not be your fault, most likely upstream python package, but I'll just leave this here.
According to the JSON specification from json.org and RFC 8259, JSON boolean values not inside quotations cannot be capitalized.
This breaks tools such as JQ and Cyberchef (and most likely many others) from ingesting the JSON.
I know that when querying the API I could just make every true and false lowercase, but this should really be handled as far upstream as possible.
Can you shown an example?
I tested with all 3 of our json serliaizers (orjson/ujson/json) and everytime I get:
Ah, you didn't specify output=json in your request.
In that case you will get a text-response, which is Python serialization.
Ah, you didn't specify
output=jsonin your request. In that case you will get a text-response, which is Python serialization.
Ah! haha, that took me for a ride. I thought it looked like a wild JSON.
My mistake, its proper now : )
Having text/json/xml prob doesn't make much sense in this day.. pretty much everything expects json (passes to use it). just the issue is some legacy apps never got around to updating to use sab json output so it was coded for text response.. but that's mainly abandonware apps i would assume. So if we dropped text output or default to json the same outcome would happen with it breaking the app. I assume if we dropped xml+text options we could prob streamline some things with just doing json as the output by default as it's the only output. Then silently ignore the output option to prevent the need to have apps drop the argument.
I'll have to poke around to see if there's any concerns (browser extensions/add-ons/3rd part apps) to not go forward with the change.
If we do depreciate/drop xml+text I would vote for it to be in 4.5. semver and all
I would only change that the default is json, not dropping xml/text. Would you still expect problems?
I would only change that the default is
json, not dropping xml/text. Would you still expect problems?
yes if the app really isnt passing output=text and just using the assumed default response of it being text.. with that changing it would prob break said app. It would require them to update to add output=text explicitly but if we were going to get them to update then might as well get them to just use json rather than have a choice (if text/xml we dont really want to keep supporting).
update
so far everything I can find is in fact using output=json, so if there is really some one off scripts or really old abandoned software from back in the day that just used text output for whatever reasons.. we prob dont really care to much.
I can confirm sabconnect++/nzb-unity/nzbdonkey browser extensions all pass output=json, all the current stack of apps *arr/or sickbeard forks including mylar3/headphones/couchpotato as well do json explicitly with sab. so I think we are actually pretty good to change the default..
We should probably make
jsonthe default if nothing is specified..
Thetextformat is pretty useless..
I don't expect changing the default output style would cause any major issues. Text format is an obvious no-go when doing significant exchanges via the api, but for a single call from simple scripts that "ok" response is often enough and easily understood even by people that otherwise never deal with code.
Oh yeah.. I forgot about the "ok" indeed.
I will drop text for 4.3, but I will keep the XML as it's not so much work to support.
It wasn't removed? You can still use it to specify xml.
Ha yeah I deleted almost instantly as I was looking via phone. All good