- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 22 Feb 2011 12:13:49 +1100
- To: Adam Barth <w3c@adambarth.com>
- Cc: public-webapps@w3.org
On 22/02/2011, at 11:39 AM, Adam Barth wrote: > On Mon, Feb 21, 2011 at 3:53 PM, Mark Nottingham <mnot@mnot.net> wrote: >> Probably best to follow up here. >> >> Yes, of course it can define the specific headers it can or cannot send. >> >> The problem is XHR not only enumerates the headers, it also defines a prefix; by doing so, you're effectively defining a convention that *all* people who register new HTTP headers need to consider; > > I guess I don't see a difference between an enumeration and a prefix. An enumeration is specific; you will (presumably) only include headers that are already existant and understood. Furthermore, an enumeration doesn't force the header name into a specific syntactic form. A prefix includes a potentially unbounded set of headers, both existant and yet to come. >> * If I want to register a header and make it secure in XHR2, I have to start its name with those four characters. If another convention comes along that requires a different prefix, and I want to invoke both behaviours with my header, I'm out of luck. > > I'm not sure what you mean by "secure" in XHR2. The list that > contains Sec- also contains a number of headers that don't start with > any particular characters. We can certainly extend that list in the > future. Sec- is just a convenient way to avoid having to update all > the XMLHttpRequest implementations. As would be defining a header that carries this information separately, as I suggested. > >> * If I'm registering a header and am completely oblivious to XHR2, I still need to know that my choice of name makes a difference in some contexts. > > That's the case regardless of whether we use an enumeration or a > prefix or our current strategy of using both. If we decide to block > setting the Banana header and you're completely oblivious to XHR2, > then your choosing to use or not use the name Banana has the same > effect. Really? You're going to enumerate a header that isn't yet defined? > Adam > > >> On 22/02/2011, at 10:09 AM, Adam Barth wrote: >>> 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/ >>>> >>>> >>>> >>>> >>>> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> >> -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 22 February 2011 01:14:21 UTC