[Bug 16297] combining multiple author request headers

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16297

--- Comment #7 from Julian Reschke <julian.reschke@gmx.de> 2012-03-10 21:33:37 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > How can a UA implement the combine rule in a determinate, testable manner in
> > > the presence of future header fields for which it is unknown whether
> > > combination would change the semantics or not?
> > 
> > It does exactly what the spec says.
> > 
> > I agree that the outcome might be undesirable if the header field doesn't use
> > list syntax, but that is different from "indeterminate".
> 
> my contention is that the spec says either too little (doesn't prescribe a
> reliable, future-proof combination rule) or too much (defines combination be
> performed by UA behind the back of the app).
> 
> XHR says:
> 
> "If header is in the author request headers list either use multiple headers,
> combine the values or use a combination of those (section 4.2, RFC 2616)."
> 
> my problem is with the use of "either"; the choice is left up to the UA;
> looking at 2616 4.2 does not resolve this into a concrete answer without
> knowledge of the future;

Why is that a problem? Both forms are allowed.

> > > I'm suggesting the punt on having the UA perform *any* combination, and let the
> > > app be responsible for producing garbage (or not).
> > 
> > XHR implementations currently *do* implement combination, so specifying
> > something else without good reason makes little sense to me.
> 
> ok, you're making a backwards compatibility argument here (though one might
> argue that the spec is still in WD and subject to any change), but in this case
> the spec should be more specific and align with implemented behavior; e.g.,
> 
> it might say to perform combination in all cases on the assumption that the
> field value syntax is #(values)
> 
> or
> 
> it might say that, unless it is known that a given header's value syntax is not
> #(values), then perform combination on the assumption that it is #values
> 
> either of these would be an improvement over the current language (IMO)

I don't see how. Right now implementations can do both, and there's nothing
wrong with it.

> > What's needed is something that allows the caller to reliably set the header
> > field no matter whether it was set before or not.
> 
> ok, but that is an orthogonal problem, yes?

It's orthogonal, but if it was solved, the whole issue we're discussing here
would be less important from an application's point of view (because the case
of having to recombine values would happen less frequently)

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Saturday, 10 March 2012 21:33:41 UTC