Re: What is Content-Length?

Content-Length certainly has been a thorn in my side for a long time,
from the very beginning.  Trying to rationalize the contradictory
definitions for Content-Length in HEAD vs GET, and the fact that servers
used it to indicate message length while browsers ignored it except
for measuring the size of a POST, hasn't worked very well.  We have
skated by so long as the only transfer encoding is chunked, but John
is right in that the basic abstractions break down when considering
digests or transfer codings in general.

>Personally I would like to see Content-Length remain an entity header.
>All the other Content-* headers are entity headers and apply to the
>entity before transfer encoding.
>
>One way to do this would be to introduce a new "Transfer-Length"
>header with the stipulation that its default value is the
>Content-Length.  The Content-Length would be defined as it is now in
>section 7, i.e. the entity length.  Thus the Transfer-Length header
>would only be needed when the message length and entity length
>differed.  This would give us consistent terminology (Content-* for
>entity, Transfer-* for message).  It would also not break any current
>of which I am aware.  At present the only widely deployed TE is
>chunked and it needs neither header.  If new TEs arise which need
>to have the message length specified they would have to use 
>Transfer-length (or both).

That is a reasonable solution.  My only concern would be for proxies,
but I think they'd be better off in the long run with a clear definition.
The one exception to the above is that Transfer-Length would default
to zero for responses to HEAD requests, 204, and 304.

....Roy

Received on Wednesday, 10 December 1997 18:46:26 UTC