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

Surely that connection is terminal and must be closed.   It is impossible
for the proxy to determine if the origin server has erred by adding a
content-length when there is no body or by adding a body to a 204 when it
should not have.   If it ignores the body indicated by the content-length
then it will be vulnerable to a smuggling attack.

At the very least, at a Connection:close.

But you'd be in your rights to just send a 500 and close.


On 28 May 2015 at 22:41, Willy Tarreau <> wrote:

> On Thu, May 28, 2015 at 12:03:47PM +0000, Adrien de Croy wrote:
> > 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.
> But it must not send one, that's explcitly forbidden by the spec. It's
> as broken as sending a body in response to a HEAD request.
> > Is this a potential smuggling attack of some sort?
> If it does so, absolutely since it will desynchronize the reader,
> thinking it's reading the response to the second request while
> reading the body of the first one!
> > 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.
> I agree. The other possibility is to break the connection as the response
> violates the spec.
> An intermediate solution could consist in only sending the headers to the
> client and breaking the connection after that. Any possibly pipelined
> request will be replayed without issue since pipeline is only permitted
> for idempotent requests.
> Willy

Greg Wilkins < <>>  - *an
subsidiary* HTTP, SPDY, Websocket server and client that scales  advice and support for jetty and cometd.

Received on Friday, 29 May 2015 02:41:04 UTC