Question on Chunk-Size sect 3.6, 8/12/96

Clever implementations of chunked transfer encoding will do it
by using the tcp buffer directly, thereby eliminating the need to
copy to another buffer and reducing the working set.

This is accomplished by reserving space at the beginning of a chunk for
the size and any chunk arguments, and then filling them in before transmitting
the buffer. Most simply, this requires using come padding characters before
or after the hex chunk size.

This has been achieved under the following operating systems for
CL-HTTP: MAC OS, UNIX, WindowsNT, Lisp Machine.

Whereas I had the impression from reading earlier drafts that trailing 
whitespace was a feasible for padding, one of our users has pointed out 
that the current implementation does not match the description in section 
3.6 of the august, 12, 1996 draft.

However, at first blush, the spec seems cleverly engineered to prevent 
using any padding, front or back. 

BUT, in section 2.1 where implied *LWS is discussed, it suggests that
whitespace may appear between  and delimiters without changing the interpretation of a field.

Thus, hex-no-zero *lws CRLF would be legal. 

Does this mean that padding the chunk-sized with spaces on the right is
legal in the current http 1.1 spec?

If so, section 3.6 should be updated to make this clear.
If not, section 3.6 should be amended to correct this mistake.

All the known 1.1 clients that have tested against the server (2 W3C clients
and one from Switzerland) have been able to deal fine with trailing
whitespace before a ";" or the CRLF

I think this mistake should be corrected as quickly as possible.

In the event that this mistake cannot be corrected swiftly, we are
prepared to employ the following workaround, which although legal,
is quite likely to break current 1.1 clients that do not handle chunk-size
arguments.

hex-no-zero ";" *lws CRLF

or one could imortalize it with

hex-no-zero ";"fyrCRLF

Constructive suggestions?

Received on Thursday, 29 August 1996 17:32:52 UTC