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
