proposed solution for CONTENT-LENGTH

[This proposal has been circulated among the editorial group
with no dissent.  -Jeff]

Most of the changes below are editorial, in that they clarify
the language of the specification but don't actually make any
normative changes.  The only real normative change is that
we require the use "chunked" to delimit any other kind of
transfer-coding.  We also remove the "proxies MUST NOT
modify Content-Length" rule, which makes no sense when
combined with (for example) "Transfer-Encoding: gzip".

I think we need to clean up the terminology in 14.36.1 (Byte Ranges),
but that's probably a separate editorial issue.

The following edits are based on draft-ietf-http-v11-spec-rev-01.txt,
which you might need to refer to when reviewing these edits.

(1) In section 3.6 (Transfer Codings), after:
       All transfer-coding values are case-insensitive. HTTP/1.1 uses
       transfer coding values in the TE header field (section 14.48) and
       in the Transfer-Encoding header field (section 14.40).

Add (as a new paragraph) [NORMATIVE CHANGES]:
	Whenever a transfer-coding other than "identity" is applied to
	a message-body, the set of transfer-codings MUST include
	"chunked", unless the message is terminated by closing the
	connection.  When the "chunked" transfer-coding is used, it
	MUST be the last transfer-coding applied to the message-body.
	The "chunked" transfer-coding MUST NOT be applied more than
	once to a message-body.  These rules allow the recipient to
	determine the transfer-length of the message (section 4.4).

(2) In section 4.4 (Message Length), insert at the beginning:
	The transfer-length of a message is the length of the
	message-body as it appears in the message; that is, after any
	transfer codings have been applied.

Change
	When a message-body is included with a message, the length of
	that body is determined by one of the following (in order of
	precedence):
To
	When a message-body is included with a message, the
	transfer-length of that body is determined by one of
	the following (in order of precedence):

Change
	 2. If a Transfer-Encoding header field (section 14.40) is
	 present and indicates that the "chunked" transfer coding has
	 been applied, then the length is defined by the chunked
	 encoding (section 3.6).
To
	 2. If a Transfer-Encoding header field (section 14.40) is
	 present and indicates that any non-identity transfer
	 coding has been applied, then the transfer-length is defined
	 by use of the "chunked" transfer coding (section 3.6),
	 unless the message is terminated by closing the connection.

Change
	 3. If a Content-Length header field (section 14.14) is
	 present, its decimal value in OCTETs represents the length of
	 the message-body.
To
	 3. If a Content-Length header field (section 14.14) is
	 present, its decimal value in OCTETs represents both the
	 entity-length and the transfer-length.  The Content-Length
	 header field MUST NOT be used if these two lengths are
	 different (i.e., if a Transfer-Encoding header field is
	 present).

Change
	 4. If the message uses the media type "multipart/byteranges",
	 which is self-delimiting, then that defines the length. This
	 media type MUST NOT be used unless the sender knows that the
	 recipient can parse it; the presence in a request of a Range
	 header with multiple byte-range specifiers implies that the
	 client can parse multipart/byteranges responses.
To
	 4. If the message uses the media type "multipart/byteranges"
	 and the transfer-length is not otherwise specified, then this
	 self-delimiting media type defines the transfer-length. This
	 media type MUST NOT be used unless the sender knows that the
	 recipient can parse it; the presence in a request of a Range
	 header with multiple byte-range specifiers implies that the
	 client can parse multipart/byteranges responses.

Change
       Messages MUST NOT include both a Content-Length header field and
       the "chunked" transfer coding. If both are received, the
       Content-Length MUST be ignored.
To
       Messages MUST NOT include both a Content-Length header field and
       a non-identity transfer coding.  If the message does include
       a non-identity transfer code, the Content-Length header field
       MUST be ignored.

(3) Change section 7.2.2 from

	7.2.2 Length

	The length of an entity-body is the length of the message-body
	after any transfer codings have been removed. Section 4.4
	defines how the length of a message-body is determined.

To
	7.2.2 Entity-Length

	The entity-length of a message is the length of the
	message-body before any transfer codings have been applied.
	Section 4.4 defines how the transfer-length of a message-body
	is determined.

(4) In section 13.5.2 (Non-modifiable Headers)

Change [NORMATIVE CHANGE]:
	A cache or non-caching proxy MUST NOT modify any of the
	following fields in a response:
 
	  .  Expires
	  .  Content-Length
 
	but it may add any of these fields if not already present. If an
	Expires header is added, it MUST be given a field-value
	identical to that of the Date header in that response. If a
	Content-Length header is added, it MUST correctly reflect the
	length of the entity-body.
 
	  Note: a typical reason for adding the Content-Length header is
	  that the origin server sent the content chunked encoded.
 
To
	A cache or non-caching proxy MUST NOT modify any of the
	following fields in a response:
 
	  .  Expires
 
	but it may add any of these fields if not already present. If an
	Expires header is added, it MUST be given a field-value
	identical to that of the Date header in that response.
 
at the end of section 13.5.2, add this new paragraph:

	The Content-Length field of a request or response is added or
	deleted according to the rules in section 4.4.  A cache or
	non-caching proxy MUST preserve the entity-length (section
	7.2.2) of the entity-body, although it MAY change the
	transfer-length (section 4.4).

(5) In section 14.14 (Content-Length)

Change
	The Content-Length entity-header field indicates the size of
	the message-body, in decimal number of OCTETs, sent to the
	recipient or, in the case of the HEAD method, the size of the
	entity-body that would have been sent had the request been a
	GET.
To
	The Content-Length entity-header field indicates the size of
	the entity-body, in decimal number of OCTETs, sent to the
	recipient or, in the case of the HEAD method, the size of the
	entity-body that would have been sent had the request been a
	GET.

[NB: there is exactly one word changed above.]

Change
	Applications SHOULD use this field to indicate the size of the
	message-body to be transferred, regardless of the media type
	of the entity. It must be possible for the recipient to
	reliably determine the end of HTTP/1.1 requests containing an
	entity-body, e.g., because the request has a valid
	Content-Length field, uses Transfer-Encoding: chunked or a
	multipart body.
To
	Applications SHOULD use this field to indicate the
	transfer-length of the message-body, unless this is prohibited
	by the rules in section 4.4.

Change
	 Note: The meaning of this field is significantly different
	 from the corresponding definition in MIME, where it is an
	 optional field used within the "message/external-body"
	 content-type. In HTTP, it SHOULD be sent whenever the
	 message's length can be determined prior to being
	 transferred.
To
	 Note: The meaning of this field is significantly different
	 from the corresponding definition in MIME, where it is an
	 optional field used within the "message/external-body"
	 content-type. In HTTP, it SHOULD be sent whenever the
	 message's length can be determined prior to being
	 transferred, unless this is prohibited by the rules in
	 section 4.4.

(6) In section 14.17 (Content-Range), change all occurrences
of "entity-length" to "instance-length".  (The non-terminal
"entity-length" appears nowhere else in the -rev-01 version
of the HTTP/1.1 specification.)

[end]

Received on Tuesday, 3 February 1998 10:52:04 UTC