Re: HTTP 1.1, proxy servers, and failed connections

>> Yes, I am sure.  ECONNREFUSED is a response, but not an HTTP response.
>
> If you say so. The spec simply says "invalid response", not
> "invalid HTTP response" and not "an invalid HTTP response or an
> explicit indication that no HTTP response will ever be received".

An invalid HTTP response is any response which is not valid HTTP, which
is certainly defined by the specification.
>
>>> How do you define "invalid response"?
>>
>> Why does that matter?
>
> Are you asking why it matters how terms in a specification are defined?

No, I am saying that you shouldn't expect the specification to define every
term in the English language.  "invalid" and "response" are fully defined.

>> You will find that what the user agent needs to do for no-connection is
>> identical to what it needs to do for other 502 situations.
>
> Quite the contrary. If I interpret 502 as meaning the upstream server
> is non-conforming (broken), I won't ever retry an operation that
> gets a 502 result. But if I got the equivalent of ECONNREFUSED back,
> I might well retry the operation. That is, if I could get the equivalent
> back, which apparently I can't.

I don't follow that reasoning.  There is no way for the recipient to
distinguish between a temporary failure on the part of the gateway and
a permanent failure.  This is a distributed system in which components
are changed independently and frequently.  All 502 responses are
indications of a temporary problem.

> In your interpretation, why do both 502 and 503 exist?

Because 503 is for origin servers to indicate that service is unavailable
using a valid HTTP response.  It is rarely used on the Web, but does 
indicate
semantics that are different from "the origin didn't respond with a valid
message."

....Roy