Responses to api commands via HTTP don't make sense

Report & discuss bugs found in SABnzbd
Forum rules
Help us help you:
  • Are you using the latest stable version of SABnzbd? Downloads page.
  • Tell us what system you run SABnzbd on.
  • Adhere to the forum rules.
  • Do you experience problems during downloading?
    Check your connection in Status and Interface settings window.
    Use Test Server in Config > Servers.
    We will probably ask you to do a test using only basic settings.
  • Do you experience problems during repair or unpacking?
    Enable +Debug logging in the Status and Interface settings window and share the relevant parts of the log here using [ code ] sections.
Post Reply
User avatar
jcfp
Release Testers
Release Testers
Posts: 986
Joined: February 7th, 2008, 12:45 pm

Responses to api commands via HTTP don't make sense

Post by jcfp »

While working with an init script using wget to shutdown the program, I noticed something strange: return values from wget always indicated failure even though shutdown actually was successful:

Code: Select all

$ wget --tries=1 -S -v --delete-after "http://127.0.0.1:8080/sabnzbd/api?mode=shutdown"; echo "RET = $?"
--20:35:33--  http://127.0.0.1:8080/sabnzbd/api?mode=shutdown
           => `api?mode=shutdown'
Connecting to 127.0.0.1:8080... connected.
HTTP request sent, awaiting response... No data received.
Giving up.

RET = 1
Wget (rightfully IMHO) assumes not receiving any data means failure. From the scripting point of view, there's no difference between this and actual failure like when using the wrong port number and getting connection refused (the return value is 1 in both cases).

In addition, sending bogus stuff via the api (?mode=foobar) results in replies (and thus wget return values) indicating success which, although not currently a real issue, is probably not the best thing either if this api gets more complex in the future.

And lastly, sending unneccessary extra parameters like a username and password while the web interface doesn't have these set, causes an "internal error" rather than something a bit more descriptive or even success:

Code: Select all

$ wget --tries=1 -S -v --delete-after "http://127.0.0.1:8080/sabnzbd/api?mode=shutdown&ma_username=user&ma_password=pass"; echo "RET = $?"
--20:50:15--  http://127.0.0.1:8080/sabnzbd/api?mode=shutdown&ma_username=user&ma_password=pass
           => `api?mode=shutdown&ma_username=user&ma_password=pass'
Connecting to 127.0.0.1:8080... connected.
HTTP request sent, awaiting response...
  500 Internal error
  Date: Sat, 16 Aug 2008 18:50:15 GMT
  Server: CherryPy/2.2.1
  Content-Type: text/html
  Set-Cookie: session_id=efb2e75f082671d674a425e67805290b0f4b4695; expires=Sat, 16-Aug-2008 19:50:15 GMT; Path=/
20:50:15 ERROR 500: Internal error.

RET = 1
(I had to modify the 500 Internal Error line slightly to get the forum software to allow this post)
User avatar
switch
Moderator
Moderator
Posts: 1380
Joined: January 17th, 2008, 3:55 pm
Location: UK

Re: Responses to api commands via HTTP don't make sense

Post by switch »

Shutdown is a tricky one because we can't return a response on whether the shutdown was successful or not as the webserver (cherrypy) is closed in the process. To return a value of success, it has to be the last action in the api function, so we cannot return "ok" then shut down sabnzbd. We could possibly get around this by creating a new thread and sleeping it for a few seconds before shutting down to allow cherrypy to return something.
In addition, sending bogus stuff via the api (?mode=foobar) results in replies (and thus wget return values) indicating success which, although not currently a real issue, is probably not the best thing either if this api gets more complex in the future.
Surely an error in wget indicates a connection issue; and should not be used for validating the success of sabnzbd operations. We return a response of "error" or "ok" to allow for easier validation of any errors without having to mess about detecting response codes in simple programs.
And lastly, sending unneccessary extra parameters like a username and password while the web interface doesn't have these set, causes an "internal error" rather than something a bit more descriptive or even success
Looks like a bug, I'll file a ticket for this.
User avatar
jcfp
Release Testers
Release Testers
Posts: 986
Joined: February 7th, 2008, 12:45 pm

Re: Responses to api commands via HTTP don't make sense

Post by jcfp »

switch wrote: Shutdown is a tricky one because we can't return a response on whether the shutdown was successful or not as the webserver (cherrypy) is closed in the process. To return a value of success, it has to be the last action in the api function, so we cannot return "ok" then shut down sabnzbd. We could possibly get around this by creating a new thread and sleeping it for a few seconds before shutting down to allow cherrypy to return something.
Strange thing is, this does work when using http://127.0.0.1:8080/sabnzbd/shutdown rather than the api in the url; that is, a "200 OK" that makes wget happy, followed by program shutdown.
switch wrote:
In addition, sending bogus stuff via the api (?mode=foobar) results in replies (and thus wget return values) indicating success which, although not currently a real issue, is probably not the best thing either if this api gets more complex in the future.
Surely an error in wget indicates a connection issue; and should not be used for validating the success of sabnzbd operations. We return a response of "error" or "ok" to allow for easier validation of any errors without having to mess about detecting response codes in simple programs.
Didn't know that but makes sense then. I was for no particular reason assuming such would be handled via the HTTP response codes ;). Btw: wget only cares if it succesfully completes the full request including a positive response from the server; if so it returns 0, otherwise 1 but that is of course of no concern when programming on sabnzbd. I'll just have to inspect the content of any reply too I guess.
User avatar
switch
Moderator
Moderator
Posts: 1380
Joined: January 17th, 2008, 3:55 pm
Location: UK

Re: Responses to api commands via HTTP don't make sense

Post by switch »

jcfp wrote:
switch wrote: Shutdown is a tricky one because we can't return a response on whether the shutdown was successful or not as the webserver (cherrypy) is closed in the process. To return a value of success, it has to be the last action in the api function, so we cannot return "ok" then shut down sabnzbd. We could possibly get around this by creating a new thread and sleeping it for a few seconds before shutting down to allow cherrypy to return something.
Strange thing is, this does work when using http://127.0.0.1:8080/sabnzbd/shutdown rather than the api in the url; that is, a "200 OK" that makes wget happy, followed by program shutdown.
Ah yes, it uses yield, I completely forgot about the posssibility of using that, I'll make it yield "ok" before it shutdown the web server.
jcfp wrote:
switch wrote:
In addition, sending bogus stuff via the api (?mode=foobar) results in replies (and thus wget return values) indicating success which, although not currently a real issue, is probably not the best thing either if this api gets more complex in the future.
Surely an error in wget indicates a connection issue; and should not be used for validating the success of sabnzbd operations. We return a response of "error" or "ok" to allow for easier validation of any errors without having to mess about detecting response codes in simple programs.
Didn't know that but makes sense then. I was for no particular reason assuming such would be handled via the HTTP response codes ;). Btw: wget only cares if it succesfully completes the full request including a positive response from the server; if so it returns 0, otherwise 1 but that is of course of no concern when programming on sabnzbd. I'll just have to inspect the content of any reply too I guess.
Well we could return "501 Not Implemented" Response codes, it's just easier for small programs to just look for "error" at the start of the response and supply more detailed information about why it failed (well for other errors).
Post Reply