- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 22 Feb 2011 09:38:03 +1100
- To: public-ietf-w3c <public-ietf-w3c@w3.org>
W3C folk, 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 really needs to be coordinated, for a few reasons. First of all, this is a bit of a land grab. 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). Rather than name-spacing the headers, 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 Secondly, if this approach *were* to go forward, we'd need to reflect this practice in the registration procedure for message headers (RFC3864) and HTTP specification (RFC2616, currently under revision in the HTTPbis WG). I've raised this as a comment to the WG, and I'd like to discuss it briefly on our upcoming call. Regards, -- Mark Nottingham http://www.mnot.net/
Received on Monday, 21 February 2011 22:38:35 UTC