- From: Adrien de Croy <adrien@qbik.com>
- Date: Thu, 28 May 2015 12:30:25 +0000
- To: "Willy Tarreau" <w@1wt.eu>
- Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
Actually I checked our code and we do ignore it, but do pass it on. This appears to be breaking some clients (e.g. some web filtering AV client which doesn't know to ignore it). So we might want to revisit the approach of passing it on. 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:32:38 UTC