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

From: Bob Scheifler - SMI Software Development <[email-masked]>
Date: Fri, 17 May 2002 18:45:56 -0400 (EDT)

> 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

---

From: [email-masked]
Date: Mon, 20 May 2002 11:27:59 -0400 (EDT)

Bob,

Could you at least describe the differing behavior you are seeing
between implementations?  I think it would be wise to clarify the spec
to get implementations to "do the same thing" if we can on similar
failures.  Any time we are getting different implemeters reading the same
spec and producing different behavior in the same circumstance, it is showing
a shortcoming in the spec.

And while HTTP is not TCP specific, I can't see any reason why some
header could not be invented to convey TCP specific failure information,
if you wanted to explore an extension to HTTP further.
			Thanks,
				- Jim

--
Jim Gettys
Cambridge Research Laboratory
HP Labs, Hewlett-Packard Company
[email-masked]