Re: HTTP 1.1, proxy servers, and failed connections

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

Received on Thursday, 16 May 2002 17:48:13 UTC