Re: Sections 3.3.2 and 3.3.3 allow bogus Content-Length?

[Matthew Kerwin <[e-mail]>]

On 15 Feb 2017 06:54, "Adrien de Croy" <[e-mail]> wrote:


The language in RFC 7230 section 3.3.2 is extremely non-commital about
whether Content-Length needs to be correct or not.

I'm currently having a dispute about this with someone who quoted these
sections at me as being proof that you can use any value for C-L regardless
of the body length.

I think it could be a lot more forcefully written

Or is the person correct and we don't need to have C-L match the body
length?

In this particular case the discussion is around request messages.

Adrien


"For messages that do include a payload body, the Content-Length
field-value provides the framing information necessary for determining
where the body (and message) ends."


That seems pretty significant to me. Especially when you consider how
pipelining works. Then in the next section:


"If a valid Content-Length header field is present without
Transfer-Encoding, its decimal value defines the expected message
body length in octets.  If the sender closes the connection or
the recipient times out before the indicated number of octets are
received, the recipient MUST consider the message to be
incomplete and close the connection."


That, along with everything else in 3.3.2 & 3.3.3, and 3.4 makes me
wonder how anyone could find ambiguity there. If C-L is present, it
has to be correct.


Cheers (and sorry if gmail messes up the formatting)