[Bug 16297] combining multiple author request headers

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

--- Comment #11 from Julian Reschke <julian.reschke@gmx.de> 2012-03-11 10:42:37 UTC ---
(In reply to comment #10)
> ...
> to me, this means the behavior is indeterminate for the app (JS author) and is
> arbitrary for the UA implementer

You say "indeterminate", I say "there are multiple ways to do it". The outcome
shouldn't matter.

> in contrast, the language in 2616 4.2 says:
> 
> " Multiple message-header fields with the same field-name MAY be
>    present in a message if and only if the entire field-value for that
>    header field is defined as a comma-separated list [i.e., #(values)].
>    It MUST be possible to combine the multiple header fields into one
>    "field-name: field-value" pair, without changing the semantics of the
>    message, by appending each subsequent field-value to the first, each
>    separated by a comma."
> 
> Firstly, the language "MAY be present" makes it optional whether or not *any*
> combination occurs. It is up to the HTTP client, in the present case, the UA
> implementation of XHR to choose whether to perform combination or not. It need
> not even perform combination to be compatible with 2616.
> 
> If combination is performed, however, it must be the case that the "header
> field is defined as a comma-separated list [i.e., #(values)]."

This just says that *if* you have multiple header fields, and you *want* to
combine them, they need to use a certain syntax.

Consider Content-Type, which does not use that syntax.

The point of the time the problem occurs is when you have multiple values to
combine. It does not matter whether you combine them or not, the HTTP message
will be invalid in both cases (no matter whether you combine the values or
not).

> Now this is already different from what XHR says, since XHR does not say that
> this rule applies. It only cites 2616 4.2 without specifying what (if any)
> aspect of it normatively applies.
> 
> Also, 2616 4.2 does not mention the case where some combination of using
> multiple headers and combining into one header occurs (for a given header
> name). So that is yet another difference in XHR.
> 
> I believe this leaves the current text in a state where it does not match 2616
> and also does not improve (but instead diminishes) interoperability.

The text doesn't need to "match". Actually, it shouldn't define anything that
is already defined by HTTP, and it also shouldn't define anything that doesn't
need to be defined.

> What I believe XHR should say is the following:
> 
> "If header is in the author request headers list, then perform the sub-steps:
> (1) if header is known by the UA to be defined as a comma-separated list [i.e.,
> #(values)], then it must combine the values into a single header;
> (2) otherwise, use multiple headers."

It could say that, but I don't see how that helps. XHR usually is implemented
on top of a network stack, and that stack might not give you the option.
Furthermore, what the UA sends may not be what the server receives, because
intermediates are allowed to recombine header fields.

> Even better, would be introducing a new boolean attribute combineHeaders [or a
> hidden variable initialized by a combineHeaders argument to open(), or an
> additional combineHeaders argument on setRequestHeader()], then change the XHR
> language to:
> 
> "If header is in the author request headers list, then perform the sub-steps:
> (1) if header is known by the UA to be defined as a comma-separated list [i.e.,
> #(values)] and the combineHeaders flag is set, then it must combine the values
> into a single header;
> (2) otherwise, use multiple headers."

I have no idea how this helps.

Maybe you could give a concrete example where the current definition is a
problem, and then we can start from there?

-- 
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 Sunday, 11 March 2012 10:42:41 UTC