Re: HTTP 1.1, proxy servers, and failed connections

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

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

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

- Bob

Received on Friday, 17 May 2002 18:46:18 UTC