Re: [XHR2] Feedback on sec-* headers

On Mon, Feb 21, 2011 at 9:28 PM, Mark Nottingham <mnot@mnot.net> wrote:

>
> On 22/02/2011, at 1:08 PM, Adam Barth wrote:
>
> > 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 ?
>
>
> Ah, I see; you want to dynamically prohibit the client sending a header,
> rather than declare what headers the client didn't allow modification of.
>
> A separate header won't help you, no.
>
> The problems I brought up still stand, however. I think we need to have a
> discussion about how much convenience the implementers really need here, and
> also to look at the impact on the registration procedure for HTTP headers.
>

The only practical issue I can see is the classic "must be first"
problem--only one string can be first, so two specs doing this would be
mutually exclusive.  It would have been nicer to treat header names as a
hyphen-delimited list, and prohibiting "sec" elements; eg.
"Sec-WebSocket-Key", "WebSocket-Sec-Key", "WebSocket-Key-Sec".

It's not worth changing at this point; it just means any other spec matching
a group of headers needs to do that, to avoid colliding with XHR.

(It's a little annoying that specs can't group headers together with a
prefix; eg. if WebSocket defines a restricted "Key" header and an
unrestricted "Value" header, it can't have all of its headers prefixed with
"WebSocket"; some need to be "Sec-WebSocket".  But that's just cosmetics.)

-- 
Glenn Maynard