Page 1 of 1
Responses to api commands via HTTP don't make sense
Posted: August 16th, 2008, 2:12 pm
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
Re: Responses to api commands via HTTP don't make sense
Posted: August 16th, 2008, 4:53 pm
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.
Re: Responses to api commands via HTTP don't make sense
Posted: August 16th, 2008, 5:45 pm
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.
Re: Responses to api commands via HTTP don't make sense
Posted: August 16th, 2008, 6:00 pm
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).