[Bug 16297] combining multiple author request headers

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

--- Comment #5 from Julian Reschke <julian.reschke@gmx.de> 2012-03-10 19:51:33 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > (In reply to comment #1)
> > > > Setting a header multiple times when the header syntax does not allow this is a
> > > > case of "garbage in garbage out", so this is fine.
> > > > 
> > > > Optimally, there were ways to remove headers, so the caller can make sure that
> > > > it doesn't set a header twice when it doesn't want to.
> > > 
> > > are you agreeing with me to have the application code handle this rather than
> > > the UA? or are you suggesting the UA should implement the "combine" function as
> > > currently specified, and that the results are indeterminate?
> > 
> > Neither.
> > 
> > I don't think the results are indeterminate. They may be *undesirable* in some
> > cases, but that's a different problem.
> 
> 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".

> > The core problem is not this rule, but the lack of control for the caller (who
> > should be able to reliably *replace* a header field). This issue has been
> > raised again and again, but we still have no API for that.
> 
> 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.

What's needed is something that allows the caller to reliably set the header
field no matter whether it was set before or not.

-- 
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 19:51:36 UTC