W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1998

Re: HTTP/1.1 : Chunking

From: Adrien de Croy <adrien@qbik.com>
Date: Fri, 30 Jan 1998 10:11:07 +1200
Message-Id: <2.2.32.19980129221107.00f956d0@192.168.0.1>
To: John Franks <john@math.nwu.edu>
Cc: http-wg@cuckoo.hpl.hp.com
Hi

At 11:53 29/01/98 -0600, John Franks wrote:
>On Thu, 29 Jan 1998, Adrien de Croy wrote:
>> 
>> 1. The chunk size may be arbitrary, and the resulting latency introduced at
>> the server (since chunking at the server requires some form of buffering)
>> may cause performance degradation in applications such as streamed media
>> through HTTP.  Is there any recommendation on how to chunk the data?
>> 
>
>The server may chunk anyway it chooses.  It can choose to do so in a
>way it finds most efficient.
>
>> 2. Any intermediary (proxy) must continually monitor the transfer through
>> itself. Is it allowed to re-chunk the data, and if so under what guidelines.
>> 
>
>It is not only allowed, but expected to be the most common practice
>for caching proxies.  The proxy can re-chunk anyway it chooses.
>
>> 
>> Proposal:
>> 
>> Addition of a new option to specify that transmission of the entity is
>> terminated by a certain sequence of octets (like an end tag) transmitted by
>> the server before closing the TCP connection.  The receiver would then know
>> if had received the whole entity by examining the last packet received
>> before the connection was closed.  If the end tag was there, then it got the
>> lot, else it didn't - simple. 
>> 
>
>As you said, the point of chunking is so the receiver can know when
>the entity ends.  But the point of knowing when the entity ends is not
>only to recognize if the connection closed prematurely.  The main
>point is to allow multiple HTTP transactions to occur in one TCP/IP
>connection.  This is a big performance win.  This means, though, that
>the entity does not end with the last packet and, in fact, entities
>will typically end in the middle of a packet.  This makes it less
>efficient (among other problems) to use an end marker.  The receiver
>would have to read all the incoming data and look for the marker.
>Chunking is both more robust and more efficient.
>

I see your point here.

However, reflecting more on that issue, the chances of a client requiring
multiple created entitities (i.e those where the server cannot know a priori
the size) in a single connection is rather low, at least at the moment.
Multiple normal requests per connection would still be possible, and
unaffected by this proposal.  So, overall, the performance gains by allowing
for maintained connections in this scenario may be outweighed by the data
overhead in chunking.


Cheers

Adrien


>John Franks
>john@math.nwu.edu
>
>
----------------------------------------------------------------------------
------
Adrien de Croy - adrien@qbik.com.  Qbik New Zealand Limited, Auckland, New
Zealand
                 See our pages and learn about WinGate at http://www.qbik.com/
----------------------------------------------------------------------------
------
Received on Thursday, 29 January 1998 13:20:51 EST

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