- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 05 Feb 2007 11:52:29 -0600
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: Web APIs WG <public-webapi@w3.org>
Julian Reschke wrote:
>> It gives the encoded length, since Content-Length is how many bytes
>> you need to read from the connection.
>
> This is true for Content-Encoding, but IMHO not for Transfer-Encoding.
> Don't confuse them! :-)
Ah, indeed. The relevant text in RFC 2616 section 14.13
("Content-Length") is:
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.
and section 4.4 says:
3.If a Content-Length header field (section 14.13) is present, its
decimal value in OCTETs represents both the entity-length and the
transfer-length. The Content-Length header field MUST NOT be sent if
these two lengths are different (i.e., if a Transfer-Encoding header
field is present). If a message is received with both a
Transfer-Encoding header field and a Content-Length header field,
the latter MUST be ignored.
So as long as servers are compliant, the issue of Transfer-Encoding
combined with Content-Length is moot anyway (and in that case, the
chunked stuff is used to determine the transfer-length).
-Boris
Received on Monday, 5 February 2007 17:53:15 UTC