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

Re: Padding size in chunked encoding

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Fri, 21 Feb 1997 13:03:46 -0500
Message-Id: <>
To: John Franks <john@math.nwu.edu>, HTTP Working Group <http-wg@cuckoo.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2520
At 08:05 AM 2/21/97 -0600, John Franks wrote:

>The pipelining paper emphasizes the importance of avoiding small TCP
>packets.  This seems awkward to do efficiently with the chunked
>encoding unless it is somehow possible to insert the size of a chunk
>at the beginning of a buffer after the data has been put in the
>buffer.  The alternative of moving all the data in the buffer to
>adjust the amount of space at the beginning is not appealing.  And, of
>course, the main point of chunking is to deal with situations where we
>don't know the size in advance.

In the particular case of the libwww pipelining implementation, buffering
is not done at the HTTP client level but at a lower level:

            Request 1        Request 2         Request 3

                           Buffer Stream


That is, each request just writes and the buffer stream is responsible for
flushing the data as a function of time and buffer size. That way, you can
get multiple requests (or responses) to fit into same TCP segment if their
sizes allow it.

However, even if you are using "direct" buffering then I can't see why you
can't count backwards from the start of the data and then let the start of
the size part vary (no param in this example):

                       x x x x x x | x x x x x x ...
                                 |   |
                     <- size start   data start ->

or use vwrite for writing multiple buffers at once.

Understanding leading 0s should of course be part of a solid implementation


Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium, MIT/LCS NE43-346
545 Technology Square, Cambridge MA 02139, USA
Received on Friday, 21 February 1997 10:04:31 UTC

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