On Mon, Feb 21, 2011 at 5:13 PM, Mark Nottingham <m...@mnot.net> wrote: > On 22/02/2011, at 11:39 AM, Adam Barth wrote: >> On Mon, Feb 21, 2011 at 3:53 PM, Mark Nottingham <m...@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.
I'm not sure I understand how this would work. Let's take the example of Sec-WebSocket-Key. When would the user agent send XHR2-Secure: Sec-WebSocket-Key ? Adam >>> * 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 <m...@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/ > > > >
