Hacker News new | ask | show | jobs
by TheSwordsman 2986 days ago
I'm not sure I agree with your assessment that sending an incorrect Content-Length is permitted. This specific post quotes a section in RFC-2616 that deals with this directly[1]:

  When a Content-Length is given in a message where a message-body is allowed, its field value MUST exactly
  match the number of OCTETs in the message-body.
According to this, the Content-Length MUST match the data. Can you share an example of the opposite being stated?

[1] https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4....

1 comments

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'd say the HEAD section is the best implication about the behavior they expect. Where in this section there is precedent set for the spec requiring it to be equal.

I'll agree and admit that implication is not explicit specification, but I think it's a reasonable example to follow.

It's worth noting that browsers allow a lot of things that either look like errors to a human or are forbidden by the RFCs. Some people want defacto behavior, others want dejure.