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 MaynardReceived on Tuesday, 22 February 2011 04:11:18 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:16 UTC