←  Suggestions

ComputerCraft | Programmable Computers for Minecraft

»

preventing http.get from returning nil

Kilobyte's Photo 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
Quote

Cloudy's Photo Cloudy 12 Nov 2012

Will look into!
Quote

AfterLifeLochie's Photo 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.
Quote

Cloudy's Photo Cloudy 12 Nov 2012

View PostAfterLifeLochie, 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.
Quote

AfterLifeLochie's Photo AfterLifeLochie 12 Nov 2012

View PostCloudy, on 12 November 2012 - 08:49 AM, said:

View PostAfterLifeLochie, 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?
Quote

Kilobyte's Photo 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"
Quote

ElvishJerricco's Photo ElvishJerricco 12 Nov 2012

View PostAfterLifeLochie, on 12 November 2012 - 09:11 AM, said:

View PostCloudy, on 12 November 2012 - 08:49 AM, said:

View PostAfterLifeLochie, 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.
Quote

AfterLifeLochie's Photo AfterLifeLochie 12 Nov 2012

View PostElvishJerricco, on 12 November 2012 - 12:29 PM, said:

View PostAfterLifeLochie, 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).
Quote

ElvishJerricco's Photo ElvishJerricco 12 Nov 2012

View PostAfterLifeLochie, on 12 November 2012 - 05:36 PM, said:

View PostElvishJerricco, on 12 November 2012 - 12:29 PM, said:

View PostAfterLifeLochie, 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.
Quote

AfterLifeLochie's Photo AfterLifeLochie 12 Nov 2012

View PostElvishJerricco, on 12 November 2012 - 05:59 PM, said:

View PostAfterLifeLochie, on 12 November 2012 - 05:36 PM, said:

View PostElvishJerricco, on 12 November 2012 - 12:29 PM, said:

View PostAfterLifeLochie, 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/>
Quote

ElvishJerricco's Photo ElvishJerricco 12 Nov 2012

View PostAfterLifeLochie, on 12 November 2012 - 06:31 PM, said:

View PostElvishJerricco, on 12 November 2012 - 05:59 PM, said:

View PostAfterLifeLochie, on 12 November 2012 - 05:36 PM, said:

View PostElvishJerricco, on 12 November 2012 - 12:29 PM, said:

View PostAfterLifeLochie, 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.
Quote

Espen's Photo Espen 13 Nov 2012

@Cloudy:
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.
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
Quote

Cloudy's Photo 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.
Quote

jag's Photo jag 30 Jun 2015

View PostCloudy, 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!?!
Quote