On 22/02/2011, at 11:39 AM, Adam Barth wrote: > On Mon, Feb 21, 2011 at 3:53 PM, Mark Nottingham <[email protected]> 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 <[email protected]> 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/
