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

[Mark Nottingham <[e-mail]>]

Now <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/429>.


On 17/01/2013, at 5:32 AM, Zhong Yu <[e-mail]> wrote:

> On Wed, Jan 16, 2013 at 12:52 AM, Willy Tarreau <[e-mail]> wrote:
>> On Tue, Jan 15, 2013 at 05:12:51PM -0800, Roy T. Fielding wrote:
>>> On Jan 15, 2013, at 4:07 PM, Nico Williams wrote:
>>> 
>>>> On Tue, Jan 15, 2013 at 6:01 PM, Mark Nottingham <[e-mail]> wrote:
>>>>> On 16/01/2013, at 10:57 AM, Nico Williams <[e-mail]> wrote:
>>>>>> No.  I'm saying that it's OK for apps to do that but not any other
>>>>>> entities (middleboxes), mostly because middleboxes can't possibly know
>>>>>> about headers that hadn't been registered when they were implemented.
>>>>> 
>>>>> OK. Is this an actual problem you've encountered?
>>>>> 
>>>>> I'm fine with adding some clarifying text if it helps implementers, but I haven't seen this confusing any middlebox vendors; they tend to leave the bits alone...
>>>> 
>>>> I noticed Poul's and someone else's replies that in their middlebox
>>>> implementations they concluded that it's never safe to merge headers.
>>>> If that's the case (and I do think it follows from the facts that it
>>>> is the case) then we should say so rather than leave each implementor
>>>> to figure this out on their own.
>>> 
>>> The requirement is on generating headers, so it does not concern
>>> middlebox vendors other than for the fields that they add to a message.
>>> 
>>> Apache httpd merges header fields as they are read from the network.
>>> So does any correctly written client that reads internet message format
>>> (like all of the common MIME and libwww libraries).  If you want to
>>> interoperate on the Web, field generators must obey that requirement.
>> 
>> Roy, you're totally right here. If Apache merges multiple instances of
>> a header, it is because the client did so, and as per the spec, it was
>> allowed to do so because the headers were mergeable.
>> 
>> However I've seen some corner cases caused by applications (not middleboxes)
>> sometimes adding a header that was already present and not mergeable (eg:
>> the Date or Location header). I know that Apache has a special handling of
> 
> 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)
> 
> We probably should require that an application either reject the
> message, or merge the header first if it wants to parse the header.
> 
> Zhong Yu
> 
>> the Set-Cookie header, I don't know if it does so for other well-known
>> non-mergeable headers which are supposed to contain commas.
>> 
>> Due to this mess caused by bogus applications, I finally decided that I
>> won't merge headers in haproxy, I didn't want to start dealing with a list
>> of exceptions. And I think it's the same reasoning for Poul Henning.
>> 
>> That said, I disagree with having the spec declare Apache non-compliant,
>> as it is doing the correct job in my opinion, as long as clients are
>> compliant.
>> 
>> But probably we could discourage future middlebox implementors from merging,
>> by making them aware of the difficulty of doing it right. This would just be
>> a non-normative warning then.
>> 
>> Willy
>> 
>> 
> 

--
Mark Nottingham   http://www.mnot.net/