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

What is Content-Length?

From: John Franks <john@math.nwu.edu>
Date: Wed, 10 Dec 1997 07:09:02 -0600 (CST)
To: Dave Kristol <dmk@bell-labs.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.LNX.3.95.971210070722.6432B-100000@hopf.math.nwu.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4882

Studying the specification some more I see there seems to be
some ambiguity about the meaning of Content-length.  Here are
some quotes:

       7.1 Entity Header Fields

       Entity-header fields define optional metainformation about the entity-
       body or, if no body is present, about the resource identified by the

              entity-header  = ...
                             | Content-Length           ; Section 14.14
       7.2.2 Length

       The length of an entity-body is the length of the message-body after any
       transfer codings have been removed...

But later we have

       14.14 Content-Length

       The Content-Length entity-header field indicates the size of the
       message-body, in decimal number of OCTETs, sent to the recipient...

These seem inconsistent.  If Content-Length means the length after
transfer encodings have been applied then it is hop-by-hop and not
end-to-end.  It also cannot be an entity header as described in
7.1.  There probably is also a need for a header meaning entity-length.

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).

I see no alternative other than rewriting the specification to make
Content-length a hop-by-hop general header and not an entity header.
The authentication specification would also need to be modified 
since it is not possible to put Authentication-Info in a chunked
trailer as it is currently defined if Content-length is the length
of the chunked message.

John Franks
Received on Wednesday, 10 December 1997 04:52:40 UTC

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