Re: LWP::UserAgent Client-Warning 500 against HTTP standards?

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?

The message is being returned to you by the client in the absence of any status code from the server because it cannot connect. This doesn't mean that it's a problem with the client - the server could be down or unroutable or the DNS could be screwy or whatever. The 4xx set is for operations where the client is at fault: malformed requests, unauthorized or forbidden access, unsatisfiable negotiation requests and so on.

The HTTP spec defines response codes which the server should provide. An absence of a response at all from the server rather renders a response code irrelevant. I'd be happy for the code to be undefined in the client in such a scenario but 500 seems a reasonable compromise in the absence of anything better. Consider 500 to mean "the request did not complete due to reasons beyond our knowledge".

🦛

Comment on Re: LWP::UserAgent Client-Warning 500 against HTTP standards?

Replies are listed 'Best First'.
Re^2: LWP::UserAgent Client-Warning 500 against HTTP standards? by pryrt (Abbot) on Sep 30, 2022 at 13:30 UTC
The 4xx set is for operations where the client is at fault: malformed requests, unauthorized or forbidden access, unsatisfiable negotiation requests and so on. Playing devil's advocate for a 4xx response: When a client requesting `https://valid.host/invalid/file.dne` gets a 404 from the server, because the file doesn't exist (so the client made a "mistake" by requesting a resource that doesn't exist); this is true even when the true error is that `index.html` linked to `invalid/file.dne` and the only "mistake" the client made was trying to download a resource linked from `index.html` . Likewise, requesting `https://invalid.host/index.html` from a server that doesn't exist is similarly the client's fault for asking for a server that doesn't exist... but in the absence of a server to tell it that the client made a mistake, it wouldn't be unreasonable for the client to admit "User, I made a mistake in trying to access `invalid.host` , even though you're the one who asked me to access it". I would even argue for the literal `400 BAD REQUEST` response, because it "indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing)." -- where the client error was "asking for a server that doesn't exist (or isn't currently online)" But similarly, the choice of a 500 error also makes sense: normally, 500 errors are a server's response to an error that it doesn't have better answer for (like "the underlying CGI doesn't know how to generate proper headers" or "doesn't have the proper linux permissions to execute the script"); so when the server is so dissociated that the client cannot see it, I could see the client arbitrarily deciding "this must be a 500, because the server is so confused or messed up that it refuses to respond at all". But honestly, I think it would be better for LWP::UserAgent to `die` instead, for reasons given elsewhere in this discussion. That really seems like the best and most natural choice to me.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: LWP::UserAgent Client-Warning 500 against HTTP standards?
by pryrt (Abbot) on Sep 30, 2022 at 13:30 UTC

The 4xx set is for operations where the client is at fault: malformed requests, unauthorized or forbidden access, unsatisfiable negotiation requests and so on.

Playing devil's advocate for a 4xx response: When a client requesting https://valid.host/invalid/file.dne gets a 404 from the server, because the file doesn't exist (so the client made a "mistake" by requesting a resource that doesn't exist); this is true even when the true error is that index.html linked to invalid/file.dne and the only "mistake" the client made was trying to download a resource linked from index.html . Likewise, requesting https://invalid.host/index.html from a server that doesn't exist is similarly the client's fault for asking for a server that doesn't exist... but in the absence of a server to tell it that the client made a mistake, it wouldn't be unreasonable for the client to admit "User, I made a mistake in trying to access invalid.host , even though you're the one who asked me to access it". I would even argue for the literal 400 BAD REQUEST response, because it "indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing)." -- where the client error was "asking for a server that doesn't exist (or isn't currently online)"

But similarly, the choice of a 500 error also makes sense: normally, 500 errors are a server's response to an error that it doesn't have better answer for (like "the underlying CGI doesn't know how to generate proper headers" or "doesn't have the proper linux permissions to execute the script"); so when the server is so dissociated that the client cannot see it, I could see the client arbitrarily deciding "this must be a 500, because the server is so confused or messed up that it refuses to respond at all".

But honestly, I think it would be better for LWP::UserAgent to die instead, for reasons given elsewhere in this discussion. That really seems like the best and most natural choice to me.

[reply]
[d/l]
[select]