Re: HTTP/1.1 : Chunking

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.

John Franks
john@math.nwu.edu

Received on Thursday, 29 January 1998 09:58:01 UTC