- 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>
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 UTC