Hello,

A HTTPbis WG member noticed that the XHR2 draft gives special status to HTTP 
headers starting with Sec-* and Proxy-*:

<http://www.w3.org/TR/XMLHttpRequest2/#the-setrequestheader-method>

"""
Terminate these steps if header is a case-insensitive match for one of the 
following headers … or if the start of header is a case-insensitive match for 
Proxy- or Sec- (including when header is just Proxy- or Sec-).
"""

This is problematic. XHR2 is effectively reserving a name space in the range of 
possible HTTP header field names. Future applications with similar requirements 
will use this as precedence, and will mint their own header prefixes. When 
those prefixes need to be combined, we'll see fragmentation (e.g., the 
Sec-Private-Special-ID header, with all of the associated parsing and special 
handling of the field name that this entails).

Instead, it would be much better to use an approach somewhat like the 
Connection header does; i.e., have the sender declare what headers it isn't 
allowing the client to modify in a separate header. E.g.,

  XHR2-Secure: Foo, Bar, Baz

This way, another application can still talk about existing headers without 
changing their names; e.g.,

  FooAPI-Private: Bar, Boo

Cheers,


--
Mark Nottingham   http://www.mnot.net/




Reply via email to