preventing http.get from returning nil

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

Will look into!

I definitely agree; but if a failure should occur, an integer HTTP status code would be much better than just "false", to be honest.

AfterLifeLochie, on 12 November 2012 - 08:48 AM said:

I definitely agree; but if a failure should occur, an integer HTTP status code would be much better than just "false", to be honest.

If we return the object anyway, you can just call getStatusCode on the http object.

Cloudy, on 12 November 2012 - 08:49 AM said:

AfterLifeLochie, on 12 November 2012 - 08:48 AM said:

I definitely agree; but if a failure should occur, an integer HTTP status code would be much better than just "false", to be honest.

If we return the object anyway, you can just call getStatusCode on the http object.

Yeah, I realized that now… but that still means we need an object back. :unsure:/>/>
Does that mean the body of the request will just be empty, then?

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"

AfterLifeLochie, on 12 November 2012 - 09:11 AM said:

Cloudy, on 12 November 2012 - 08:49 AM said:

AfterLifeLochie, on 12 November 2012 - 08:48 AM said:

I definitely agree; but if a failure should occur, an integer HTTP status code would be much better than just "false", to be honest.

If we return the object anyway, you can just call getStatusCode on the http object.

Yeah, I realized that now… but that still means we need an object back. :unsure:/>/>
Does that mean the body of the request will just be empty, then?

even 404 returns typically have body.

ElvishJerricco, on 12 November 2012 - 12:29 PM said:

AfterLifeLochie, on 12 November 2012 - 09:11 AM said:

{snip}
Does that mean the body of the request will just be empty, then?

even 404 returns typically have body.

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).

AfterLifeLochie, on 12 November 2012 - 05:36 PM said:

ElvishJerricco, on 12 November 2012 - 12:29 PM said:

AfterLifeLochie, on 12 November 2012 - 09:11 AM said:

{snip}
Does that mean the body of the request will just be empty, then?

even 404 returns typically have body.

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.

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:

AfterLifeLochie, on 12 November 2012 - 09:11 AM said:

{snip}
Does that mean the body of the request will just be empty, then?

even 404 returns typically have body.

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. :P/>/>

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:

AfterLifeLochie, on 12 November 2012 - 09:11 AM said:

{snip}
Does that mean the body of the request will just be empty, then?

even 404 returns typically have body.

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. :P/>/>

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.

@Cloudy:
While experimenting and researching I found the following:

The observed behavior is as expected - if the http server returns an error then getInputStream will throw an IOException.

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:

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

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.

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!?!