[Bug 16297] combining multiple author request headers

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

--- Comment #10 from Glenn Adams <glenn@skynav.com> 2012-03-11 01:17:30 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > ...
> > that's what produces intedeterminate behavior; that's what causes
> > non-interoperability, when one UA does X and another UA does Y;
> > 
> > the point in standardization is not just writing down arbitrary complicated
> > rules rather, it is creating greater interoperability and consistency
> 
> HTTP says both forms are allowed. XHR requiring one with no good reason would
> be a layering violation.

we seem to be talking past each other... let me try again

the current XHR spec 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)."

this means that a UA has three choices:

(1) use multiple headers
(2) combine all values into one header
(3) use multiple headers *and* combine *some* values

it also cites 2616 4.2, but does not specify what if any part of 4.2 applies,
so the reference to 2616 is effectively informative only

the application (JS author) has no idea which of these three options are chosen
by a given UA

the UA implementer has no idea (other than the tangential reference to 2616
4.2) what rules to apply to determine which of these three cases apply

to me, this means the behavior is indeterminate for the app (JS author) and is
arbitrary for the UA implementer

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)]."

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.

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

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

-- 
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 01:17:34 UTC