[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-*: """ Terminate these steps if header is a case-insensitive match for one of the following headers … or

[XHR2] Feedback on sec-* headers

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 wh

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

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

Re: [XHR2] Feedback on sec-* headers

On Mon, Feb 21, 2011 at 3:53 PM, Mark Nottingham 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 co

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 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

Re: [XHR2] Feedback on sec-* headers

On Mon, Feb 21, 2011 at 5:13 PM, Mark Nottingham wrote: > On 22/02/2011, at 11:39 AM, Adam Barth wrote: >> On Mon, Feb 21, 2011 at 3:53 PM, Mark Nottingham wrote: >>> Probably best to follow up here. >>> >>> Yes, of course it can define the specific headers it can or cannot send. >>> >>> The prob

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

Re: [XHR2] Feedback on sec-* headers

On Mon, Feb 21, 2011 at 9:28 PM, Mark Nottingham 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

Re: [XHR2] Feedback on sec-* headers

On Mon, Feb 21, 2011 at 6:28 PM, Mark Nottingham 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

Re: [XHR2] Feedback on sec-* headers

On Tue, 22 Feb 2011 03:28:00 +0100, Mark Nottingham 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

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 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 regis

Re: [XHR2] Feedback on sec-* headers

On Tue, 22 Feb 2011 14:19:58 +0100, Julian Reschke 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 reph

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 l

Re: [XHR2] Feedback on sec-* headers

On Tue, 22 Feb 2011 20:19:33 +0100, Richard L. Barnes 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

Re: [XHR2] Feedback on sec-* headers

On Thu, 24 Feb 2011 14:43:47 +0100, Richard L. Barnes 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

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 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

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 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