Re: HTTP 1.1, proxy servers, and failed connections

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

At best, we can clarify the existing specification from draft to full 
standard in this area.  Proposals of wording to clarify the spec gratefully 
accepted.  Going to full standard is currently blocked by MIME (which 
HTTP depends on), but the day will come, hopefully in the not too distant 
future.  So I encourage you (and/or others) to try to draft language you 
think would minimise the opportunity for implementers to do the "wrong 
thing", whatever we think that is.  We can at least get every one doing
the same thing eventually, by clarification of the specification.

One of the issues is we don't have any good mechanism to propage the right 
information of what failed in the protocol.

One could design one, and put together an internet draft to cover this 
very foggy area to extend the protocol.  I suspect/hope it would meet 
with general acceptance.

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

Yes, your credentials (to me at least, knowing your background and what
you've worked on over the years) are impeccable in this area.  Most
(but not all) of the HTTP working group, myself included, share your
distaste with the "everything in the world on top of HTTP" mania,
and I know that you are working on this against better judgement,
and due to the lack of viable alternatives presently.

Anyone ranting at Bob on this topic who is not working on alternatives
seriously should leap into /dev/null...
			- Jim


--
Jim Gettys
Cambridge Research Laboratory
HP Labs, Hewlett-Packard Company
Jim.Gettys@hp.com

Received on Friday, 17 May 2002 10:44:58 UTC