Re: What is Content-Length?

    > 	If a message is sent on a persistent connection using
    > 	a transfer-coding that does not exactly preserve the
    > 	length of the data being encoding, then the "chunked"
    > 	transfer-coding MUST be used, and MUST be the last
    > 	transfer-coding applied.
    > 
    
    Is there a reason to require that chunked be applied after a
    self-delimiting transfer encoding?  There would be a (probably
    slight)  performance penality for doing it and I don't see the
    purpose.

It seems like a mistake to get into the business of specifying
self-delimiting transfer codings (aside from chunked, which is
a generic way to do that).  This way, we have some modularity
in the protocol design.  I.e., we have only three ways to find
the end of a message (EOF, Content-Length, chunked); why add
more?

I can see a small performance penalty for parsing the chunk size,
but this is hex (not decimal) so it's actually cheaper than parsing
content-length, and much cheaper than parsing the silly HTTP-date format.
And it's likely that any self-delimiting transfer coding would have
nearly as much added overhead.

-Jeff