W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: Sticky stuff.

From: Koen Holtman <koen@win.tue.nl>
Date: Fri, 9 Aug 1996 01:12:34 +0200 (MET DST)
Message-Id: <199608082312.BAA16892@wsooti04.win.tue.nl>
To: Paul Leach <paulle@microsoft.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, hallam@etna.ai.mit.edu
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1258
Paul Leach:
>>From:  hallam@Etna.ai.mit.edu[SMTP:hallam@Etna.ai.mit.edu] 
>>2) I'm not sure of the amount that these proceedures buy us. It
>>would be nice to have figures. 

I guess this is a good time for me to repost the figures I calculated
almost a year ago.  Look for a message `Statistics on reusing request
headers in persistent connections'.  The conclusion:

 My conclusion is that the gains are too small to bother about request
 header reuse at this point:
      - HTTP traffic savings would be about 1.3%
      - speedup of browsing response time would be minimal:
        page+inline loading times would be noticeably faster in
        about 17% of all cases.

 Much higher gain/effort ratios can be had by focusing on other
 desirable features of future HTTP software, for example [...]

The conclusion still seems to be valid.

>>Jim G. has made good points about
>>the importance of getting as much usefull information in
>>the first packet send out (i.e. before we hit the slow start
>>throttle). This mechanism appears to be aimed more at increasing
>>the efficiency of later packets.
>There's not much that can be done about initial packets, unless somehow
>the negotiation step can be skipped.

If you mean `unless somehow the Accept headers can be left out': you
can indeed leave them out under transparent content negotiation.  And
in most requests, you will leave them out.  See Section 11.6
(construction of short requests) in the conneg draft.  Does the

      GET /paper HTTP/1.1
      Host: x.org
      User-Agent: WuxtaWeb/2.4

fit into one packet?

Received on Thursday, 8 August 1996 16:21:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC