- From: Larry Masinter <LMM@acm.org>
- Date: Mon, 5 Nov 2001 22:22:34 -0800
- To: "HTTP Working Group" <http-wg@hplb.hpl.hp.com>
Greg Robson reported that there is a reference to a non-existent
section 3.6.2. Jeff Mogul points out that in
http://www1.ics.uci.edu/pub/ietf/http/hypermail/1998q3/0135.html
[+ subsequent messages in the same thread]
that, although the working group had decided to eliminate
the "identity" transfer coding in issue CHUNKEDTRAILERS,
the edit to remove it was incomplete: Section 3.6.2 was removed, but
other references to the "identity" transfer-coding was not removed.
A simple edit in the errata would remove all mention of the
'identity' transfer-coding token value. Are there any
implementations that use it?
I've written one possible way of handling this; another way would
be to add a section 3.6.2 that describes the "identity" token,
notes that it was half-left in by mistake in RFC 2616 and that
it MUST NOT be used.
--------------------------------------------
Section 3.6 (remove reference to non-existant section)
--------------------------------------------
OLD:
The Internet Assigned Numbers Authority (IANA) acts as a registry for
transfer-coding value tokens. Initially, the registry contains the
following tokens: "chunked" (section 3.6.1), "identity" (section
^^^^^^^^^^^^^^^^^^^^
3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate"
^^^^^^^^
(section 3.5).
NEW:
The Internet Assigned Numbers Authority (IANA) acts as a registry for
transfer-coding value tokens. Initially, the registry contains the
following tokens: "chunked" (section 3.6.1), "gzip" (section 3.5),
"compress" (section 3.5), and "deflate" (section 3.5).
--------------------------------------
Section 4.4 (remove 'other than identity' for Transfer-Encoding case
since identity is not a valid value
---------------------------------------
OLD:
2.If a Transfer-Encoding header field (section 14.41) is present and
^^^^
has any value other than "identity", 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.
NEW:
2.If a Transfer-Encoding header field (section 14.41) is present,
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.
---------------------
OLD:
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-coding, the Content-Length MUST be ignored.
NEW:
Messages MUST NOT include both a Content-Length header field and a
transfer-coding. If the message does include a transfer-coding,
the Content-Length MUST be ignored.
---------------------
Section 19.4.5 -- remove 'identity' CTE?
---------------------
OLD:
HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST
remove any non-identity CTE ("quoted-printable" or "base64") encoding
^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
prior to delivering the response message to an HTTP client.
NEW:
HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST
remove any CTE encoding prior to delivering the response message to
an HTTP client.
Received on Tuesday, 6 November 2001 06:25:17 UTC