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

[Willy Tarreau <[e-mail]>]

Hi Mark,

On Mon, Jan 21, 2013 at 11:17:14AM +1100, Mark Nottingham wrote:
> 
> 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).

Oh Great.

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

Location has no special status here in my opinion. I provided it as an
example but it's harmless (at least as harmless as many other fields).

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

In my opinion, as long as framing is not affected, I don't think so.
And the other fields which affect framing already support commas (eg:
Connection, Transfer-Encoding). I suspect that Content-Length was the
only one to have such a nasty effect.

One might consider that Max-Forwards could affect how far the message
goes, but this is seldom used and more for tracing than anything else.

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

I think that's OK.

Cheers,
Willy