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.

cheers





On 28 May 2015 at 22:41, Willy Tarreau <w@1wt.eu> 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 <gregw@webtide.com <gregw@intalio.com>>  - *an Intalio.com
subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.