Padding size in chunked encoding

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
http://www.w3.org/pub/WWW/Protocols/HTTP/Performance/Pipeline.html)
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

                 0057CRLF

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

                 57;pad="xxx"CRLF

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

John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu

Received on Friday, 21 February 1997 06:10:20 UTC