W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

Re: What is Content-Length?

From: John Franks <john@math.nwu.edu>
Date: Wed, 10 Dec 1997 21:50:02 -0600 (CST)
To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.LNX.3.95.971210214145.1757A-100000@hopf.math.nwu.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4897
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.

John Franks
Received on Wednesday, 10 December 1997 19:55:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:21 UTC