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

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 <mnot@mnot.net> wrote:
> >> On 16/01/2013, at 10:57 AM, Nico Williams <nico@cryptonector.com> 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
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

Received on Wednesday, 16 January 2013 06:53:54 UTC