Re: HTTP/1.1 : Chunking

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