preventing http.get from returning nil
Kilobyte 12 Nov 2012
Hey Together,
If http.get() calls a website which returns for example a 404 Not Found. the method will return nil.
My suggestion is to change that. you will the be able to find out why the http request failed. this would make error handling and outputting a lot easier. to prevent the change from breaking existing programs you could also add a second parameter to http.get which is a boolean whether to return nil(set it to false or nil) or a handle(set it to true) if an error occured
greetz, Stiepen/Kilobyte
If http.get() calls a website which returns for example a 404 Not Found. the method will return nil.
My suggestion is to change that. you will the be able to find out why the http request failed. this would make error handling and outputting a lot easier. to prevent the change from breaking existing programs you could also add a second parameter to http.get which is a boolean whether to return nil(set it to false or nil) or a handle(set it to true) if an error occured
greetz, Stiepen/Kilobyte
AfterLifeLochie 12 Nov 2012
I definitely agree; but if a failure should occur, an integer HTTP status code would be much better than just "false", to be honest.
Cloudy 12 Nov 2012
AfterLifeLochie 12 Nov 2012
Kilobyte 12 Nov 2012
you might also add some function to the object to return the string associated with the code. so for code 404 this usually would be "Not Found"
ElvishJerricco 12 Nov 2012
AfterLifeLochie 12 Nov 2012
ElvishJerricco, on 12 November 2012 - 12:29 PM, said:
Yes, but the present behaviour is nil on failure, in contrast with a HTTP code response.
If we actually get an object back then the response would contain a document anyway, but, if people just look for *a* response, they might take an "error" as a valid reply (and so, checking should occur on the HTTP reply).
ElvishJerricco 12 Nov 2012
AfterLifeLochie, on 12 November 2012 - 05:36 PM, said:
ElvishJerricco, on 12 November 2012 - 12:29 PM, said:
Yes, but the present behaviour is nil on failure, in contrast with a HTTP code response.
If we actually get an object back then the response would contain a document anyway, but, if people just look for *a* response, they might take an "error" as a valid reply (and so, checking should occur on the HTTP reply).
I think that if that's the case, they'll likely be using the http.get or http.post functions (as they'd rather do that than roll their own with http.request) so maybe have those two functions do what you're talking about, but have http.request return something we can deal with? I dunno I'm looking for the best of both worlds because I *want* my 404 failure bodies.
AfterLifeLochie 12 Nov 2012
ElvishJerricco, on 12 November 2012 - 05:59 PM, said:
AfterLifeLochie, on 12 November 2012 - 05:36 PM, said:
ElvishJerricco, on 12 November 2012 - 12:29 PM, said:
Yes, but the present behaviour is nil on failure, in contrast with a HTTP code response.
If we actually get an object back then the response would contain a document anyway, but, if people just look for *a* response, they might take an "error" as a valid reply (and so, checking should occur on the HTTP reply).
I think that if that's the case, they'll likely be using the http.get or http.post functions (as they'd rather do that than roll their own with http.request) so maybe have those two functions do what you're talking about, but have http.request return something we can deal with? I dunno I'm looking for the best of both worlds because I *want* my 404 failure bodies.
http.status; http.getResponse(); http.getErrorResponse();
Everyone's happy. />
ElvishJerricco 12 Nov 2012
AfterLifeLochie, on 12 November 2012 - 06:31 PM, said:
ElvishJerricco, on 12 November 2012 - 05:59 PM, said:
AfterLifeLochie, on 12 November 2012 - 05:36 PM, said:
ElvishJerricco, on 12 November 2012 - 12:29 PM, said:
Yes, but the present behaviour is nil on failure, in contrast with a HTTP code response.
If we actually get an object back then the response would contain a document anyway, but, if people just look for *a* response, they might take an "error" as a valid reply (and so, checking should occur on the HTTP reply).
I think that if that's the case, they'll likely be using the http.get or http.post functions (as they'd rather do that than roll their own with http.request) so maybe have those two functions do what you're talking about, but have http.request return something we can deal with? I dunno I'm looking for the best of both worlds because I *want* my 404 failure bodies.
http.status; http.getResponse(); http.getErrorResponse();
Everyone's happy. />
Meh. I just think that's a little weak. I'd really much rather not have a layer of abstraction that doesn't make much sense on the lower levels.
Espen 13 Nov 2012
@Cloudy:
While experimenting and researching I found the following:
Source: http://www-01.ibm.co...uid=swg21249300
That means if the server returns a response code >= 400 then getInputStream() will throw an IOException.
Possible solution (in HTTPRequest):
Before:
After:
Edit:
Even if this fix were to be implemented, having only http_failure as a fail event would still be too abiguous, as others have mentioned.
Suggestion:
Let it return the same values as http_success does, so that the returned response code would either be whatever the connection returned, or 0 if there was no successful connection.
This way one can distinguish the different states better:
While experimenting and researching I found the following:
Quote
The observed behavior is as expected - if the http server returns an error then getInputStream will throw an IOException.
That means if the server returns a response code >= 400 then getInputStream() will throw an IOException.
Possible solution (in HTTPRequest):
Before:
InputStream is = connection.getInputStream();
After:
InputStream is; if (connection.getResponseCode() < 400) { is = connection.getInputStream(); } else { is = connection.getErrorStream(); }
Edit:
Even if this fix were to be implemented, having only http_failure as a fail event would still be too abiguous, as others have mentioned.
Suggestion:
Let it return the same values as http_success does, so that the returned response code would either be whatever the connection returned, or 0 if there was no successful connection.
This way one can distinguish the different states better:
- http_success, response < 400 --> Connection successful
- http_failure, response >= 400 --> Connection successful, but returned an error
- http_failure, response == 0 --> Connection not successful
Cloudy 13 Nov 2012
I can just return the object regardless, and let people decide what to do with it - an extra boolean just returning the http table inside the Lua handling.
jag 30 Jun 2015
Cloudy, on 13 November 2012 - 07:10 AM, said:
I can just return the object regardless, and let people decide what to do with it - an extra boolean just returning the http table inside the Lua handling.
I just want to ask because this is annoying me a lot, but why does it still return nil when the request is like anything except status 200???
I want to know what I did wrong, but no I have nothing to bugtest with!?!