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

On 02/14/2017 01:12 PM, Adrien de Croy wrote:
> The first sentence in 3.3.2
>
> "When a message does not have a Transfer-Encoding header field, a
> Content-Length header field can provide the anticipated size, as a
> decimal number of octets, for a potential payload body."
>
> "can provide"???
> "anticipated size"???
> "potential payload body"???

Seems to me that those weird qualifications are there mostly for the 
case where Content-Length is sent without a payload body. From the same 
paragraph:

    [...] 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.  For messages that do not include a payload
    body, the Content-Length indicates the size of the selected
    representation (Section 3 of [RFC7231]).

Without the (admittedly vague) language, you'll have people trying to 
parse bodies from responses to HEAD requests if they have a 
Content-Length, or people complaining because the server changed the 
size of a representation between the HEAD and the GET, or whatever. 
Thus, "anticipated size" and "potential payload body".

I'm curious to know what use case someone could possibly create for a 
client to send an incorrect Content-Length.

--Jacob

Received on Tuesday, 14 February 2017 21:54:04 UTC