- From: Mark Nottingham <mnot@mnot.net>
- Date: Sun, 20 Jan 2013 13:51:20 +1100
- To: Willy Tarreau <w@1wt.eu>
- Cc: Zhong Yu <zhong.j.yu@gmail.com>, "Roy T. Fielding" <fielding@gbiv.com>, Nico Williams <nico@cryptonector.com>, Karl Dubost <karld@opera.com>, Julian Reschke <julian.reschke@gmx.de>, Piotr Dobrogost <p@ietf.dobrogost.net>, ietf-http-wg@w3.org
On 17/01/2013, at 6:41 AM, Willy Tarreau <w@1wt.eu> wrote: > Hi, > > On Wed, Jan 16, 2013 at 12:32:22PM -0600, Zhong Yu wrote: >> If different applications interpret duplicate headers differently, we >> have a serious problem >> >> Location: http://abc.com >> Location: http://xyz.com >> >> Some chooses the 1st one, some chooses the 2nd one, and some may see >> the merged `http://abc.com,http://xyz.com` (a valid URI) > > Obviously and the issue is the same with many headers. I was just explaining > that this is an example of a *non-compliant* input which is then turned into > a different non-compliant output by a middlebox. The problem clearly is with > the input and not with the operation performed by the middlebox. So we could > recommend middlebox authors against merging the headers because it's hard to > do it right, but we have no reason to add a SHOULD NOT which would turn some > existing implementations to non-compliant for no reason. I think the middlebox aspect of this is a red herring. What's happening above is that a non-conformant message is being turned into, potentially, conformant input (if there's no space around the comma) -- regardless of where it takes place. I.e., that combination into a single value could just as easily be done in the UA, before the Location is followed. It seems to me that that's worth at least a note in Security Considerations. I do agree that a requirement -- especially targeted at a particular kind of recipient, rather than *all* recipients -- is probably too much. This is more on the scale of implementation advice. YMMV. -- Mark Nottingham http://www.mnot.net/
Received on Sunday, 20 January 2013 02:51:50 UTC