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

[Zhong Yu <[e-mail]>]

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