W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1994

Re: Connection Header

From: Roy T. Fielding <fielding@blanche.ICS.UCI.EDU>
Date: Mon, 19 Dec 1994 11:52:10 -0800
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9412191152.aa03549@paris.ics.uci.edu>
I think people are getting quite a bit carried away with all this
speculation about keep-alive versus MGET.  A couple salient points:

1) The Connection header (or something with identical semantics)
   is necessary regardless of whether or not it is used to support
   a keep-alive. There is simply no other way to communicate in-band options
   to your nearest-neighbor in a world of multiple hierarchical proxies,
   without requiring that your nearest-neighbor always be a proxy.

2) Just because the Connection header exists doesn't mean a server has
   to support it or do anything with it aside from NOT forwarding it.

3) The SESSION method (or something with identical semantics) is necessary
   regardless of whether or not it is used to support a multi-request
   connection.  There is simply no other way to send in-band commands to your
   nearest neighbor without risk of that action being forwarded downstream
   (where it would be misinterpreted as coming from the downstream's
   neighbor).

4) Just because the SESSION method exists doesn't mean a server has
   to support it or do anything with it aside from NOT forwarding it.

The above is what is covered for HTTP/1.0.  For 1.1, we can consider
what can be done with this stuff once it is available.  Starting from the
keep-alive example I described, here are some points which do not seem
to have been made clear:

5) The decision on whether or not to allow a kept-alive connection,
   how long the connection should stay open, and the maximum number
   of requests that are accepted, IS ENTIRELY UP TO THE SERVER!
   Whether or not it is in the 1.1 spec has no effect on any server
   software which doesn't wish to implement it, nor does it prevent
   methods like MGET from also being defined and used.

6) Because the server's decision regarding keep-alive is, if accepted,
   visible in the returned response's headers, the client does not have
   to wait until the end of the connection in order to find out what
   the server will do.

7) The decision on whether or not keep-alive and/or SESSION and/or
   MGET/MPUT/MPOST/MWHIP/... *should* be implemented will be made
   based on actual measurements of test implementations, some indication
   of how difficult they are to implement, and an explicit test of
   that warm-fuzzy-feeling that engineers get when they think they've
   found the right solution.

8) There is no such thing as a bloody MGET proposal, because no one
   has ever attempted to specify it beyond some vague notion, let alone
   actually implement the sucker.  I don't want to hear any more arguments
   about how much *more* efficient this method is until someone gets up
   the gumption to specify exactly what the beastie will entail. 
   Volunteers will be gratefully accepted!!!!

9) If one or more of the above methods are implemented and can achieve
   a user perceived performance improvement to within 20% of the visible
   performance of multiple simultaneous requests for a page with four
   inlined images on a congested line, I will personally block out all
   requests from my site (and will recommend the same for all sites)
   of any browser which continues to use multiple independent connections.


......Roy Fielding   ICS Grad Student, University of California, Irvine  USA
                                     <fielding@ics.uci.edu>
                     <URL:http://www.ics.uci.edu/dir/grad/Software/fielding>
Received on Monday, 19 December 1994 12:02:06 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:10 EDT