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

[Mark Nottingham <[e-mail]>]

On 20/01/2013, at 6:15 PM, Willy Tarreau <[e-mail]> wrote:

> Hi Mark,
> 
> On Sun, Jan 20, 2013 at 01:53:39PM +1100, Mark Nottingham wrote:
>> Now <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/429>.
> 
> Quite frankly, I'd prefer to stay on Roy's side which consists in saying
> that when a compliant message is passed to an intermediary, the output is
> a compliant message, and when a non-compliant message is passed, the
> output is indetermined.
> 
> Otherwise we'll have to document all possible corner cases, which will
> result in even worse implementations givent that we won't be exhaustive.
> 
> Probably that all the trouble comes from the obligations made to senders,
> with senders sometimes being intermediaries. I've been bothered by this
> in the past. So the point above at least would solve the issue for them :
> they have to emit clean things but if they forward stupid things, well,
> it's the other side's fault.


I know, and agree with the spirit of what you're saying. 

Digging around, it's gratifying to see that we already cover this somewhat in [1]:

> Whether the field is a single value, or whether it can be a list (delimited by commas; see Section 3.2 of [Part1]).
> 
> If it does not use the list syntax, document how to treat messages where the field occurs multiple times (a sensible default would be to ignore the field, but this might not always be the right choice).
> 
> Note that intermediaries and software libraries might combine multiple header field instances into a single one, despite the field's definition not allowing the list syntax. A robust format enables recipients to discover these situations (good example: "Content-Type", as the comma can only appear inside quoted strings; bad example: "Location", as a comma can occur inside a URI).

I think the remaining questions are:

 - Is it necessary to say anything regarding Location? The security aspect here is pretty limited, AFAICT; while it can certainly cause interop problems (the easy answer to which is "don't do that"), I don't see how it's useful to say anything about the security risks, because if an attacker can insert a new Location header in your response, they can do pretty much anything else they want too... And, unlike Content-Length (where we *have* said something), it doesn't affect framing.

 - Are there any other headers that we define where something should be said? I think we've already reviewed and said no. Anyone?

So, absent any further discussion, I'll close the issue.

Cheers,


1. https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#considerations.for.new.header.fields

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