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

On 29/05/2015 6:55 p.m., Willy Tarreau wrote:
> On Fri, May 29, 2015 at 04:26:22PM +1000, Greg Wilkins wrote:
>> On 29 May 2015 at 16:03, Willy Tarreau wrote:
>>
>>> Not necessarily if everyone in the chain acts as specified both in 2616
>>> and 7230 : response message doesn't contain a body *regardless of headers*.
>>
>>
>> except by definition this situation occurs when somebody in the chain is
>> acting NOT according to 2616/7230 and has either attached a body when they
>> should not have, or indicated a content-length when there is no content.
>>
>> My point is that it is dangerous to try to distinguish between those two
>> alternatives. Somebody in the chain is acting badly, so cut the chain!
> 
>>From a spec interpretation perspective I disagree since if you look at
> the paragraph about message size, it's pretty clear that content-length
> doesn't matter for 204. *BUT* from a developer point of view, I cannot
> see a valid case where a 204 could contain a non-zero content-length,
> so I'd be tempted to explain that situation via a bug only, and then I
> agree with the principle of cutting the chain to prevent that bug from
> having nastier effects.
> 
> The case where you'd find a transfer-encoding header could be slightly
> more difficult to sort out since you're supposed to ignore it with 204
> though you don't know yet if you'll find some data, and a bogus server
> could unconditionally respond with 204+T-E and a zero-length chunk to
> mark the end of the body. In that case there's no risk of smuggling
> attack since the body will always start with hex digits, so there's no
> way they'll match "HTTP/1.1 <status>" and be confused with a second
> response.

Except for encodings which are not "chunked". With nothing to transfer
T-E should not exist either by the definition of 204.

Smuggling attack or not closing the connection on garbage is the right
way to go. That passes the harm back to the broken server in the form of
extra TCP round trips each time it does it.

Amos

Received on Friday, 29 May 2015 09:30:35 UTC