[Bug 16297] combining multiple author request headers

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

--- Comment #12 from Glenn Adams <glenn@skynav.com> 2012-03-11 13:39:46 UTC ---
(In reply to comment #11)
> (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.

no, it defines the condition under which combination can occur; it precludes
combinations when a header is not defined as #(values);

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

irrelevant; the first is an implementation detail; the second is outside the
scope of the UA, and is not true in general [1] as I'm sure you know

[1]
http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-18.html#non-modifiable.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?

because it is ambiguous

ambiguous:
adjective
(of language) open to more than one interpretation; having a double meaning
• unclear or inexact because a choice between alternatives has not been made

because ambiguity is a barrier to interoperability [2]

[2] http://en.wikipedia.org/wiki/Semantic_interoperability

by analogy, a similar problem was reported in SOAP JMS Binding [3], and
resolved by qualifying when to apply a specific choice (of results)

[3] http://www.w3.org/2002/ws/soapjms/tracker/issues/69

-- 
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 13:40:00 UTC