- From: Ross Patterson <Ross_Patterson@ns.reston.vmd.sterling.com>
- Date: Thu, 29 Jan 98 14:27:07 EST
- To: http-wg@cuckoo.hpl.hp.com
Adrien de Croy <adrien@qbik.com> writes: >Hi all, sorry if I am not following correct protocol in mailing to this >group. Nope, that's exactly the protocol. >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. As John Franks has pointed out, chunked encoding is intended to allow a TCP connection to be used for several HTTP transactions in sequence (described in the spec as a "persistent connection"). The major goal was to cope with content of initially-unknown length, which is handled just fine in HTTP 1.0 by closing the TCP connection after the last byte of data. That still works in HTTP 1.1, but only for the last entity sent on the connection (of course). So persistent connections require that every entity sent have a determinable length, even if only upon completion of the entity. Chunked encoding does exactly that. > The receiver would then know >if had received the whole entity by examining the last packet received >before the connection was closed. Unfortunately, TCP connections are byte streams, not packet streams. While it would be possible to check the last N bytes of the last entity on a connection for some tag, it would not be possible on any prior entities. So this new type of encoding wouldn't help persistent connections, which are believed to be an important part of HTTP 1.1. Ross Patterson Sterling Software, Inc. VM Software Division
Received on Thursday, 29 January 1998 11:37:45 UTC