[Bug 16297] New: combining multiple author request headers

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