Re: What is Content-Length?

David W. Morris (dwm@xpasc.com)
Wed, 10 Dec 1997 20:22:36 -0800 (PST) 

 

On Wed, 10 Dec 1997, John Franks wrote:

> On Wed, 10 Dec 1997, Roy T. Fielding wrote:
> 
> > 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.
> > 
> > John Franks wrote
> > >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.
> 
> I think proxies should be ok.  If they understand a new TE which requires
> Transfer-length then they should also understand Transfer-length.  If
> they don't understand the TE they have to reject it.  Proxies are not
> supposed to touch digests so that shouldn't be a problem.
> 
> > The one exception to the above is that Transfer-Length would default
> > to zero for responses to HEAD requests, 204, and 304.
> > 
> 
> Yes, you are right.  Indeed, any request or response should have
> Transfer-length 0 if and only if it has an empty message body.  And
> an empty messge body should imply Transfer-length 0 without the header
> being present.

I am quite confused here. We introduced CHUNKed transfer encoding 
because it is difficult for some servers to know the content length
prior to beginning to send data.

Exactly HOW would a server know transfer-length before sending
data? I can define a reasonable use of content-length in the
trailer of a chunk-encoded transfer ... since content length is
the entity length, it could serve as a double check of the
receipt of the chunk-encoded entity.  But clearly, transfer
length couldn't appear in the trailer as the length wouldn't
be known until after the trailer was complete.  It makes no
sense to me for a server which knows the length of the transfer
encoded entity to ever use transfer encoding.

Sounds like protocol cruft to me.  What am I missing?

Dave Morris