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

From: Bob Scheifler - SMI Software Development <[email-masked]>
Date: Mon, 13 May 2002 19:03:00 -0400 (EDT)

> Resent-Date: Mon, 13 May 2002 18:04:16 -0400 (EDT)
> Resent-Message-Id: <[email-masked]>
> Mime-Version: 1.0 (Apple Message framework v481)
> Cc: [email-masked]
> To: Bob Scheifler - SMI Software Development <[email-masked]>
> From: "Roy T. Fielding" <[email-masked]>
> Content-Transfer-Encoding: 7bit
> Subject: Re: HTTP 1.1, proxy servers, and failed connections
> Resent-From: [email-masked]
> 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".

> > How do you define "invalid response"?
> 
> Why does that matter?

Are you asking why it matters how terms in a specification are 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.

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

- Bob

---

From: Jeffrey Mogul <[email-masked]>
Date: Thu, 16 May 2002 14:48:10 -0700

I don't want to get into the "502 vs. 503" discussion, but I think
you should probably assume that HTTP/1.1 is inherently a "best
efforts" delivery mechanism.  We certainly did not try to provide
reliable delivery semantics, or even reliable delivery-error
semantics, during the design process (although we did try to provide
reliable caching-error indications, but that's [sort of] one layer
higher in the stack).

Applying the venerable "end-to-end argument" of Saltzer et al., this
implies that if you want to determine if an HTTP method truly
succeeded or not ("at most once") then you need something at a higher
layer than the message-delivery indication.  There is some
possibility that the entity-tag mechanism could be used to prevent
duplicate update operations.  For example, if the client does a GET
and gets back 'Etag: "abc"' and then does a PUT (or POST) with
'If-Match: "abc"', this should prevent the operation from taking
place *if* both of these assumptions hold:

	(1) the server changes the entity tag upon each PUT/POST
	(2) the server actually supports If-Match

A plausible reading of the spec (RFC 2616) implies that any server
that hands out Etag headers must support If-Match, but this isn't
explicit (unfortunately) and I am not sure that you can count on it.

See section 14.24 for a little more discussion of this mechanism,
which (as stated there) is intended "on updating requests, to prevent
inadvertent modification of the wrong version of a resource" which I
think is basically why you want at-most-once semantics, right?

-Jeff

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 17 May 2002 14:35:23 -0700

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

> 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