- From: <bugzilla@jessica.w3.org>
- Date: Sun, 11 Mar 2012 13:39:48 +0000
- To: public-webapps-bugzilla@w3.org
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