Re: 204 no content response with Content-Length header.

ok thanks

I guess the issue is that even if you ignore the Content-Length in the 
message, the framing on the stream is potentially broken, since if the 
emitter of the message decides to send a body of that length, you can't 
process it as another message.

Is this a potential smuggling attack of some sort?

Also whilst a 304 can update metadata and the Content-Length can be used 
to validate a stored entity, it's not clear 204 does.

Adrien


------ Original Message ------
From: "Willy Tarreau" <w@1wt.eu>
To: "Adrien de Croy" <adrien@qbik.com>
Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
Sent: 28/05/2015 11:58:06 p.m.
Subject: Re: 204 no content response with Content-Length header.

>Hi Adrien,
>
>On Thu, May 28, 2015 at 11:48:03AM +0000, Adrien de Croy wrote:
>>
>>  Hi everyone.
>>
>>  I'm seeing some responses coming back from a server with status code 
>>204
>>  and a non-zero Content-Length header.
>>
>>  Since the spec says that 204 responses MUST not contain a body, and
>>  therefore are terminated by the first empty line, what should one 
>>make
>>  of the Content-Length header?
>>
>>  Should we (in a proxy)
>>
>>  a) ignore it and pass it to client
>>  b) strip it from message to client
>>  c) treat it as some meta data being communicated / updated
>>  d) something else
>
>In haproxy, we process them exactly like 304 which are defined pretty
>similarly, in that we ignore the content-length since the message 
>doesn't
>contain one. This is the behaviour defined in 7230#3.3.3 :
>
>    1.  Any response to a HEAD request and any response with a 1xx
>        (Informational), 204 (No Content), or 304 (Not Modified) status
>        code is always terminated by the first empty line after the
>        header fields, regardless of the header fields present in the
>        message, and thus cannot contain a message body.
>
>Please note the "regardless of the header fields present in the 
>message",
>this is the key here.
>
>Best regards,
>Willy
>

Received on Thursday, 28 May 2015 12:06:00 UTC