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

Padding size in chunked encoding

From: John Franks <john@math.nwu.edu>
Date: Fri, 21 Feb 1997 08:05:54 -0600 (CST)
To: HTTP Working Group <http-wg@cuckoo.hpl.hp.com>
Message-Id: <Pine.SUN.3.95.970221073220.24698E-100000@hopf.math.nwu.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2515
Some time ago someone (I forget who) raised the issue of size padding in 
chunked entities.  

The recent paper on pipelining by Nielsen, Gettys, et al (see
adds new salience to this concern.

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.

This problem could be cleanly solved if we could zero pad the size
of a chunk.  I.e. if a chunk size could look like


The current BNF disallows this, however.  Is there some reason for
disallowing a leading zero?  If this cannot be changed I suspect
we will end up with rather inelegant extensions like


with a variable number of x's adjusted to create the padding.

John Franks 	Dept of Math. Northwestern University
Received on Friday, 21 February 1997 06:10:20 UTC

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