good chemistry is complicated, and a little bit messy -LW |
|
PerlMonks |
LWP::UserAgent Client-Warning 500 against HTTP standards?by Discipulus (Canon) |
on Sep 30, 2022 at 07:35 UTC ( [id://11147169]=perlmeditation: print w/replies, xml ) | Need Help?? |
Hello community, being our halls so quite in these days I'm lazily inviting you to meditate about LWP::UserAgent behaviour returning 500 when LWP can't connect to some URL or when other failures in protocol handlers occur. Is this breaking HTTP specification? If ever glanced current rfc or not you should know that all 5** status code are server side. The LWP doumentation is very clear on this: > There will still be a response object returned when LWP can't connect to the server specified in the URL or when other failures in protocol handlers occur. These internal responses use the standard HTTP status codes, so the responses can't be differentiated by testing the response status code alone. Error responses that LWP generates internally will have the "Client-Warning" header set to the value "Internal response". If you need to differentiate these internal responses from responses that a remote server actually generates, you need to test this header value. Infact..
The message returned is already very clear Can't connect.. is oblviously client side: so why the choose of an error of the 5** class? In the chat LanX suggested 418 I'm a teapot and is fun and new to me, but not usable: teapots are reserved to IANA :) In the 4** class are defined status codes 401-418 plus 421 422 426 so there is room to have something like: 419 - Can't connect See also other status numbers used to craft a HTTP::Response So (and I dont want to blame LWP authors) why they choosed to return 500 setting an header internally to disambiguate it? What other frameworks do? Quickly trying Mojo::UserAgent I see it uses it's own Mojo::Message::Response and does not return any status code for unexisting urls:
..and this error is defined in Mojo::IOLoop::Client it seems to me a better design, but... wait this is a die behaviour! if you switch URLs in the above code you never reach the second GET. By other hand curl tell us it is unable to resolve the URL:
..and it is right. What do you think about? What other frameworks I missed do? Is 200 if you post 203 but no 204 will be accepted! :) L*
There are no rules, there are no thumbs.. Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
Back to
Meditations
|
|