Subject: Re: HTTP 1.1, proxy servers, and failed connections

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 17 May 2002 16:18:10 -0700

On Friday, May 17, 2002, at 03:45  PM, Bob Scheifler wrote:
>> An invalid HTTP response is any response which is not valid HTTP, which
>> is certainly defined by the specification.
>>
>> 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.
>
> To me, the absence of any HTTP-level data does not constitute an
> HTTP-level response; ECONNREFUSED is a (valid) TCP-level response, which
> implies that no HTTP-level response will be received, so there is
> no HTTP-level response that has been received that one could ascertain
> the (in)validity of.

That is a perfectly reasonable interpretation if you are thinking of HTTP
as a transport protocol.  But HTTP isn't a transport protocol.

>>> 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.
>
> I didn't say I was trying to distinguish between temporary and
> permanent failures. I'm trying to identify failures that I believe
> may practically (not theoretically) be worth retrying, and that
> are guaranteed to preserve at-most-once semantics.
>
> At any rate, I have my answer, HTTP 1.1 simply does not convey the
> information I seek. I won't trouble this list further on the subject.

HTTP doesn't have at-most-once semantics.  Such things are typically done
within the exchanged representation (the message body), since that is an
end-to-end semantic which is very application-specific.  Simply include
an identifier of the request.

>>> 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."
>
> Pity that there is a special code for a rare case, and no code for the
> common case of ECONNREFUSED.

502 is for ECONNREFUSED, cosmic rays, and all of the other asynchronous
events that might cause a gateway to receive an invalid response from
the origin.  HTTP is independent of TCP and there is no reason to make
its response codes specific to TCP.  The specific reason for the 502 can
be included in the 502 response body.

....Roy