W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: [XHR2] Feedback on sec-* headers

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 21 Feb 2011 15:09:42 -0800
Message-ID: <AANLkTimXKLgk=yXmjNBup7s4wAayoYaK=2tzGqUpSmxf@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: public-webapps@w3.org
I replied on HTTPbis, but I can reply here too.  It seems like the
XMLHttpRequest API is free to decide which headers can and can't be
set using the XMLHttpRequest API.  For example, the XMLHttpRequest API
could decide that it can or cannot be used to set the Banana HTTP
header as the designers of that API see fit.

Adam


On Mon, Feb 21, 2011 at 2:38 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 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/
>
>
>
>
>
Received on Monday, 21 February 2011 23:10:51 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT