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
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
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
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
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
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
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
[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
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
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
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
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
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
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.
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
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;
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
17 matches
Mail list logo
