Re: [XHR2] Feedback on sec-* headers
On Tue, 22 Feb 2011 20:19:33 +0100, Richard L. Barnes rbar...@bbn.com wrote: Mark's XHR2-Secure proposal satisfies the requirement by explicitly listing the headers that are secure (I'll assume the enumeration stays, though it doesn't necessarily have to). Any header name that is contained either in the fixed enumeration or in the XHR2-Secure header is secure, otherwise it's insecure. This allows any header to be marked as secure, regardless of its name. It's also arguably easier to implement: 1. On the sending side: 1.curr. Check membership in a fixed enum || prefix 1.XHR2-Secure.1. Check membership in a fixed enum (spec enum + UA-chosen enum) 1.XHR2-Secure.2. Add fixed header value XHR2-Secure with UA-chosen enum 2. On the receiving side: 2.curr. Check membership in a fixed enum || prefix 2.XHR2-Secure. Add XHR2-Secure names to spec enum; check membership in fixed enum The major concern is backward compatibility. I don't really know what the state of the art is on the use of Sec-* headers, so I can't comment much on practical concerns. But you could accommodate this to some extent with some wildcarding in the XHR2-Secure header and a recommendation to include Sec-* in the UA-chosen enum. Would this not mean that for each new header introduced servers would have to check an XHR2-secure header in addition to it to make sure it is not being spoofed? That kind of complexity seems like something we should avoid. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] Feedback on sec-* headers
On Thu, 24 Feb 2011 14:43:47 +0100, Richard L. Barnes rbar...@bbn.com wrote: On Feb 24, 2011, at 6:53 AM, Anne van Kesteren wrote: Would this not mean that for each new header introduced servers would have to check an XHR2-secure header in addition to it to make sure it is not being spoofed? That kind of complexity seems like something we should avoid. Even with the Sec-*, you need to check any new headers belong to that namespace or the fixed enumeration. So it's just a question of how you check, set containment vs. prefix match. I'll admit that checking membership in a set is slightly more complex than a memcmp, but the difference doesn't seem all that significant. With Sec-* only the client needs to be aware of the tricks. The server can simply trust the values because it can never get spoofed secure headers from compliant clients. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] Feedback on sec-* headers
On 24.02.2011 15:00, Anne van Kesteren wrote: On Thu, 24 Feb 2011 14:43:47 +0100, Richard L. Barnes rbar...@bbn.com wrote: On Feb 24, 2011, at 6:53 AM, Anne van Kesteren wrote: Would this not mean that for each new header introduced servers would have to check an XHR2-secure header in addition to it to make sure it is not being spoofed? That kind of complexity seems like something we should avoid. Even with the Sec-*, you need to check any new headers belong to that namespace or the fixed enumeration. So it's just a question of how you check, set containment vs. prefix match. I'll admit that checking membership in a set is slightly more complex than a memcmp, but the difference doesn't seem all that significant. With Sec-* only the client needs to be aware of the tricks. The server can simply trust the values because it can never get spoofed secure headers from compliant clients. As long as the server relies on the request being sent by XmlHttpRequest, right? Use a different type of client, and the header fields could be sent... BR, Julian
Re: [XHR2] Feedback on sec-* headers
On Feb 24, 2011, at 6:53 AM, Anne van Kesteren wrote: On Tue, 22 Feb 2011 20:19:33 +0100, Richard L. Barnes rbar...@bbn.com wrote: Mark's XHR2-Secure proposal satisfies the requirement by explicitly listing the headers that are secure (I'll assume the enumeration stays, though it doesn't necessarily have to). Any header name that is contained either in the fixed enumeration or in the XHR2-Secure header is secure, otherwise it's insecure. This allows any header to be marked as secure, regardless of its name. It's also arguably easier to implement: 1. On the sending side: 1.curr. Check membership in a fixed enum || prefix 1.XHR2-Secure.1. Check membership in a fixed enum (spec enum + UA-chosen enum) 1.XHR2-Secure.2. Add fixed header value XHR2-Secure with UA-chosen enum 2. On the receiving side: 2.curr. Check membership in a fixed enum || prefix 2.XHR2-Secure. Add XHR2-Secure names to spec enum; check membership in fixed enum The major concern is backward compatibility. I don't really know what the state of the art is on the use of Sec-* headers, so I can't comment much on practical concerns. But you could accommodate this to some extent with some wildcarding in the XHR2-Secure header and a recommendation to include Sec-* in the UA-chosen enum. Would this not mean that for each new header introduced servers would have to check an XHR2-secure header in addition to it to make sure it is not being spoofed? That kind of complexity seems like something we should avoid. Even with the Sec-*, you need to check any new headers belong to that namespace or the fixed enumeration. So it's just a question of how you check, set containment vs. prefix match. I'll admit that checking membership in a set is slightly more complex than a memcmp, but the difference doesn't seem all that significant. --Richard
Re: [XHR2] Feedback on sec-* headers
On Tue, 22 Feb 2011 03:28:00 +0100, Mark Nottingham m...@mnot.net wrote: 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. This is not about convenience for implementors. This is about allowing specifications to introduce headers that cannot be spoofed via XMLHttpRequest. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] Feedback on sec-* headers
On 22.02.2011 12:52, Anne van Kesteren wrote: On Tue, 22 Feb 2011 03:28:00 +0100, Mark Nottingham m...@mnot.net wrote: 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. This is not about convenience for implementors. This is about allowing specifications to introduce headers that cannot be spoofed via XMLHttpRequest. It would be good if this could be rephrased as a general design question, and specified in a way that it also applies in other contexts (such as browser plugins doing HTTP, applets, Flash, Silverlight, whatnot). BR, Julian
Re: [XHR2] Feedback on sec-* headers
On Tue, 22 Feb 2011 14:19:58 +0100, Julian Reschke julian.resc...@gmx.de wrote: On 22.02.2011 12:52, Anne van Kesteren wrote: This is not about convenience for implementors. This is about allowing specifications to introduce headers that cannot be spoofed via XMLHttpRequest. It would be good if this could be rephrased as a general design question, and specified in a way that it also applies in other contexts (such as browser plugins doing HTTP, applets, Flash, Silverlight, whatnot). Yeah, I suppose. When such a higher-level document exists I can update XMLHttpRequest to point to it. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] Feedback on sec-* headers
[sorry if this is a repeat, sent first copy in the process of joining the list] Jumping over to this list (hi, I'm new here!) from another list. To recap: I had chimed in in support of Mark's proposal, and Anne said It fails to meet the goal of Sec-, with a pointer to this thread. It seems like the high-level requirement is for the recipient of an HTTP request to know which parts of the request are secure, in the sense that they were set by the UA, and which are insecure, in the sense that they are, or may have been, set by a script. Presumably the entity-body is always insecure, so we're confined to header fields. The current XHR and XHR2 specs satisfy this requirement by means of an enumeration of headers plus a prefix. Any header name in the enumeration, or starting with the prefix, is secure, otherwise it's insecure. As Mark noted, this deals poorly with extensibility, since any new secure headers have to go in the Sec-* prefix. This is especially problematic if a UA wants to protect some standard field beyond the enumeration (say, X-Forwarded-For), or if there is some other convention that calls for a different prefix. Mark's XHR2-Secure proposal satisfies the requirement by explicitly listing the headers that are secure (I'll assume the enumeration stays, though it doesn't necessarily have to). Any header name that is contained either in the fixed enumeration or in the XHR2-Secure header is secure, otherwise it's insecure. This allows any header to be marked as secure, regardless of its name. It's also arguably easier to implement: 1. On the sending side: 1.curr. Check membership in a fixed enum || prefix 1.XHR2-Secure.1. Check membership in a fixed enum (spec enum + UA-chosen enum) 1.XHR2-Secure.2. Add fixed header value XHR2-Secure with UA-chosen enum 2. On the receiving side: 2.curr. Check membership in a fixed enum || prefix 2.XHR2-Secure. Add XHR2-Secure names to spec enum; check membership in fixed enum The major concern is backward compatibility. I don't really know what the state of the art is on the use of Sec-* headers, so I can't comment much on practical concerns. But you could accommodate this to some extent with some wildcarding in the XHR2-Secure header and a recommendation to include Sec-* in the UA-chosen enum. --Richard
[XHR2] Feedback on sec-* headers
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/
Re: [XHR2] Feedback on sec-* headers
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/
Re: [XHR2] Feedback on sec-* headers
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; * 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. * 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. Cheers, 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/
Re: [XHR2] Feedback on sec-* headers
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. * 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. * 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. 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/
Re: [XHR2] Feedback on sec-* headers
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. * 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/
Re: [XHR2] Feedback on sec-* headers
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/
Re: [XHR2] Feedback on sec-* headers
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. Cheers, -- Mark Nottingham http://www.mnot.net/
Re: [XHR2] Feedback on sec-* headers
On Mon, Feb 21, 2011 at 9:28 PM, Mark Nottingham m...@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
Re: [XHR2] Feedback on sec-* headers
On Mon, Feb 21, 2011 at 6:28 PM, Mark Nottingham m...@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 Sec- behavior has only been implemented for a few years at this point. If there was another solution that worked better, we could likely adopt it. I couldn't think of one at the time, but other folks might have more clever ideas. Adam
