Re: What is Content-Length?
John Franks (john@math.nwu.edu)
Thu, 11 Dec 1997 18:00:00 -0600 (CST)
On Thu, 11 Dec 1997, Scott Lawrence wrote:
> At this point there are a great many reasons not to introduce a new
> header without a compelling reason - they are called deployed
> implementations.
Any current implementation that is compliant would remain compliant
if a Transfer-length header is added.
>
> There are no transfer encodings in 1.1 for which the length is
> ambiguous; we don't need to change the spec now.
>
Ambiguity may be in the eye of the beholder, but many people believe
that the content length of a chunked object is the length AFTER
chunking. They have a very good case based on section 14.14 of the
Rev01 spec. Even a smart guy like Dave Kristol expressed this view
here recently, but I hope we've converted him. :)
It can also be argued based on section 7 that the content length is
the length before chunking. You and I agree that this is what it
should be, but I don't in all honesty see how one can say the spec is
unambiguous.
The specification is very explicit that if a Content-length header
exists it must contain the length AFTER the transfer coding is applied.
The only reason this is not a problem for chunked is the spec also
forbids the existence of a Content-length header if chunking is used.
It would be possible to forbid the existance of a Content-length
header whenever any transfer encoding exists, but then it is pretty
stupid to say that Content-length is the length after encoding.
For Authentication-info to work content-length must be the length
before a transfer encoding is applied. If everyone could agree on
that as the definition of content length, I would be happy. Then in
the future we would either have to introduce Transfer-length or forbid
the use of Content-length with all transfer encodings (as we do with
chunked).
John Franks
john@math.nwu.edu