- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Fri, 12 Dec 97 16:53:04 PST
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> 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
Received on Friday, 12 December 1997 16:54:24 UTC