- From: <bugzilla@jessica.w3.org>
- Date: Sat, 10 Mar 2012 00:19:42 +0000
- To: public-webapps@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16297 Summary: combining multiple author request headers Product: WebAppsWG Version: unspecified Platform: All URL: http://dvcs.w3.org/hg/xhr/raw-file/8d4e9ccfdbd4/Overvi ew.html OS/Version: All Status: NEW Severity: normal Priority: P2 Component: XHR AssignedTo: annevk@opera.com ReportedBy: glenn@skynav.com QAContact: public-webapps-bugzilla@w3.org CC: mike@w3.org, public-webapps@w3.org section 4.7.2 step 7 is ambiguous or non-testable or both; i.e., as defined, consistent behavior cannot be predicted... the current language 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)." in order to reliably implement the rules cited in HTTP, namely "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." one must have a priori knowledge of which headers satisfy this constraint and which headers do not while it is possible to determine this information at a fixed point in time, e.g., the date 2616 was published (June 1999), it is not possible to know this information for headers defined in the future given this ambiguity, I wonder if the implementation of XHR should make any decisions about combining headers?? perhaps it is better to allow the JS client code to make this determination... that is, to have the implementation *always* use multiple headers (in the order added) -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Saturday, 10 March 2012 00:19:44 UTC