- From: Bob Scheifler - SMI Software Development <rws@east.sun.com>
- Date: Thu, 16 May 2002 18:13:03 -0400 (EDT)
- To: mogul@pa.dec.com
- Cc: ietf-http-wg@w3.org
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