| RFC2616 is obsoleted by RFC7230. Relevant section: https://tools.ietf.org/html/rfc7230#section-3.3.2 Occurrences of MUST NOT for the server in that section are: A sender MUST NOT send a Content-Length header field in any message that contains a Transfer-Encoding header field. (so can't send both Content-Length and Transfer-Encoding) A server MAY send a Content-Length header field in a response to a HEAD request (Section 4.3.2 of [RFC7231]); a server MUST NOT send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent in the payload body of a response if the same request had used the GET method. (if you send Content-Length on HEAD, it must match the length of the response you would have sent for GET) A server MAY send a Content-Length header field in a 304 (Not Modified) response to a conditional GET request (Section 4.1 of [RFC7232]); a server MUST NOT send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent in the payload body of a 200 (OK) response to the same request. (you can send Content-Length on conditional GET; if you do, must match length of the response you would have sent for GET) A server MUST NOT send a Content-Length header field in any response with a status code of 1xx (Informational) or 204 (No Content). A server MUST NOT send a Content-Length header field in any 2xx (Successful) response to a CONNECT request (Section 4.3.6 of [RFC7231]). (some other situations that can't use Content-Length) It may be an oversight, but nothing in that section requires that the Content-Length, in general, must match the size of the response body. |
I'll agree and admit that implication is not explicit specification, but I think it's a reasonable example to follow.