W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2011

Re: [#95] Multiple Content-Lengths

From: Willy Tarreau <w@1wt.eu>
Date: Thu, 10 Mar 2011 00:03:40 +0100
To: Julian Reschke <julian.reschke@gmx.de>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20110309230340.GE29190@1wt.eu>
On Wed, Mar 09, 2011 at 11:44:20PM +0100, Julian Reschke wrote:
> I can think of three ways for recipients to handle these:
> 
> a) fail to parse C-L, and treat the message as invalid (closing the 
> connection because of broken framing)
> 
> b) accept the duplicate value, and use the C-L as if it wasn't repeated
> 
> c) fail to parse C-L, and just treat the C-L header field as invalid, 
> but continue processing by reading until the end of connection
> 
> Smuggling could only happen if some recipients did c), right? Those that 
> do this IMHO are already non-compliant, so I'm not sure how mandating b) 
> helps...

I think that doing only c) could have impacts on pipelined requests,
because if a client sends 3 requests, and receives a duplicate C-L in
the first response, then it will read all three responses as the first
one because it ignores C-L and waits for the close. Also we don't know
how other intermediaries in the chain will proceed. So basically treating
the C-L as invalid on *some* components seems more dangerous to me than
trying to keep in sync with the stream. I'd say you've listed the solutions
in the order of the least risky to the most risky ones, with the first one
causing issues in some environments.

Regards,
Willy
Received on Wednesday, 9 March 2011 23:04:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:37 GMT