Jump to content




preventing http.get from returning nil


13 replies to this topic

#1 Kilobyte

  • Members
  • 122 posts

Posted 12 November 2012 - 07:03 AM

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

#2 Cloudy

    Ex-Developer

  • Members
  • 2,543 posts

Posted 12 November 2012 - 07:16 AM

Will look into!

#3 AfterLifeLochie

    Wiki Oracle

  • Moderators
  • 480 posts
  • LocationAfterLifeLochie's "Dungeon", Australia

Posted 12 November 2012 - 08:48 AM

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

#4 Cloudy

    Ex-Developer

  • Members
  • 2,543 posts

Posted 12 November 2012 - 08:49 AM

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.

#5 AfterLifeLochie

    Wiki Oracle

  • Moderators
  • 480 posts
  • LocationAfterLifeLochie's "Dungeon", Australia

Posted 12 November 2012 - 09:11 AM

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?

#6 Kilobyte

  • Members
  • 122 posts

Posted 12 November 2012 - 10:37 AM

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"

#7 ElvishJerricco

  • Members
  • 803 posts

Posted 12 November 2012 - 12:29 PM

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.

#8 AfterLifeLochie

    Wiki Oracle

  • Moderators
  • 480 posts
  • LocationAfterLifeLochie's "Dungeon", Australia

Posted 12 November 2012 - 05:36 PM

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

#9 ElvishJerricco

  • Members
  • 803 posts

Posted 12 November 2012 - 05:59 PM

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.

#10 AfterLifeLochie

    Wiki Oracle

  • Moderators
  • 480 posts
  • LocationAfterLifeLochie's "Dungeon", Australia

Posted 12 November 2012 - 06:31 PM

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/>

#11 ElvishJerricco

  • Members
  • 803 posts

Posted 12 November 2012 - 06:43 PM

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.

#12 Espen

    Curious Explorer

  • Members
  • 708 posts

Posted 13 November 2012 - 03:31 AM

@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


#13 Cloudy

    Ex-Developer

  • Members
  • 2,543 posts

Posted 13 November 2012 - 07:10 AM

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.

#14 jag

  • Members
  • 533 posts
  • LocationStockholm, Sweden

Posted 30 June 2015 - 02:25 PM

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





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users