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). -BorisReceived on Monday, 5 February 2007 17:53:15 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:57 GMT