Re: HTTP 1.1, proxy servers, and failed connections

Thanks for the response.

> I think you should probably assume that HTTP/1.1 is inherently a "best
> efforts" delivery mechanism.

I have no quarrel with that.

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

I'm not really looking for "reliable" error-delivery semantics;
I'm looking for "accurate" and "best efforts" error delivery.
The varying interpretations I've seen (based on how proxy servers
currently work) and heard (from the on-list and off-list responses
to my question) leave me with the impression that the RFC is not
being uniformly interpreted with respect to error delivery (an
accuracy problem), and with the impression that it is lacking in
best-efforts error propagation through proxy servers (information
is being tossed that could be propagated).

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

I'm trying to preserve at-most-once semantics for RPC-over-HTTP,
while trying to maximize the ability to retry calls when there
are transient errors (like ECONNREFUSED when accept queues fill up
or a server is restarting). I don't think entity tags help there
in the general case.

[Rants about RPC-over-HTTP to /dev/null; I probably like it less than you.]

- Bob

Received on Thursday, 16 May 2002 18:13:56 UTC