Re: Multiple header fields with the same field name - unwritten assumption about quoted commas in values?

[Mark Nottingham <[e-mail]>]

On 17/01/2013, at 6:41 AM, Willy Tarreau <[e-mail]> 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/