W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

Re: i28 proposed replacement text

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Tue, 13 May 2008 23:16:13 +0200
To: Jamie Lokier <jamie@shareable.org>
Cc: Adrien de Croy <adrien@qbik.com>, ietf-http-wg@w3.org
Message-Id: <1210713373.3675.11.camel@henriknordstrom.net>

On tis, 2008-05-13 at 18:16 +0100, Jamie Lokier wrote:

> That makes no sense.  Specifically, "it's an entity attribute
> therefore it is banned with Transfer-Encoding" makes no sense, because
> other entity attributes are not banned with Transfer-Encoding.

It's banned because Content-Length is BOTH a entity header and a
transport header. But unfortunately the specs does not make a clear
distinction between transport and message..

Other transport headers are Transfer-Encoding, Connection, Trailer,
Upgrade, TE and Keep-Alive. Expect could also be counted as transport
but it's another odd beast..

> Imho, RFC 2616 section 4.4 rule 3 (Content-Length is not allowed with
> transfer-coding) is illogical and inconsistent with Content-Length
> being an entity header.  The rule is there only for compatibility, and
> might be safe to relax in some cases where the receiver is known to
> implement HTTP/1.1.

Maybe in some years. Something to revisit for HTTP/1.2.

The reals reason why it's there is to prevent badness when chunked
encoding is removed by an intermediary hop and the advertised
Content-Length does not match the acual length sent by chunked encoding.

Received on Tuesday, 13 May 2008 21:17:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:45 UTC