2009/3/20 Anne van Kesteren ann...@opera.com:
On Fri, 20 Mar 2009 18:59:52 +0100, Giovanni Campagna
scampa.giova...@gmail.com wrote:
You may just enforce validity of known or possibly unsafe headers
(Content-Type being the most important)
I don't think that is the right place.
Ok, just say
On Sat, 21 Mar 2009 14:13:33 +0100, Giovanni Campagna
scampa.giova...@gmail.com wrote:
2009/3/20 Anne van Kesteren ann...@opera.com:
I don't think that is the right place.
Ok, just say that implementation *must* pass the appropriate header
name and value to the network layer, which in turn
2009/3/21 Anne van Kesteren ann...@opera.com:
On Sat, 21 Mar 2009 14:13:33 +0100, Giovanni Campagna
scampa.giova...@gmail.com wrote:
2009/3/20 Anne van Kesteren ann...@opera.com:
I don't think that is the right place.
Ok, just say that implementation *must* pass the appropriate header
2009/3/19 Anne van Kesteren ann...@opera.com:
On Thu, 19 Mar 2009 20:37:50 +0100, Giovanni Campagna
scampa.giova...@gmail.com wrote:
Actually both of them are invalid per RFC2616 and thus should raise
SYNTAX_ERR.
I do not want to enforce validity in the XMLHttpRequest API. That seems
On Fri, 20 Mar 2009 18:59:52 +0100, Giovanni Campagna
scampa.giova...@gmail.com wrote:
You may just enforce validity of known or possibly unsafe headers
(Content-Type being the most important)
I don't think that is the right place.
Or actually, they don't per current spec, but I think they
On Tue, Mar 17, 2009 at 6:40 AM, Anne van Kesteren ann...@opera.com wrote:
On Mon, 16 Mar 2009 11:12:01 -, Anne van Kesteren ann...@opera.com
wrote:
On Mon, 16 Mar 2009 12:07:22 +0100, Alexey Proskuryakov a...@webkit.org
wrote:
I think that the algorithm can only compare MIME types, not
2009/3/19 Jonas Sicking jo...@sicking.cc:
[...]
Two things that I think we need to watch out for:
1. Someone doing
xhr.setRequestHeader(Content-Type, text/plain; application/xml);
2. Someone doing
xhr.setRequestHeader(Content-Type, text/plain;
somewierdthing=application/xml);
On Mon, 16 Mar 2009 11:12:01 -, Anne van Kesteren ann...@opera.com
wrote:
On Mon, 16 Mar 2009 12:07:22 +0100, Alexey Proskuryakov a...@webkit.org
wrote:
I think that the algorithm can only compare MIME types, not the full
Content-Type string.
I guess that makes sense.
I made this
Per the current CORS spec draft, a request can only be a simple
request if, among other conditions:
Custom request headers does not contain a header field name that is
an ASCII case-insensitive match for Content-Type or it does contain it
and the corresponding header field value is an
On Mon, 16 Mar 2009 12:07:22 +0100, Alexey Proskuryakov a...@webkit.org
wrote:
Per the current CORS spec draft, a request can only be a simple request
if, among other conditions:
Custom request headers does not contain a header field name that is an
ASCII case-insensitive match for
It strikes me that there are actually two issues here:
1. What constitutes a simple request for the purposes in CORS? As far
as that's concerned, I suspect that Alexey has it right.
2. Who should set charset parameter for XMLHttpRequest? The code
invoking it or the underlying engine?
16.03.2009, в 14:12, Anne van Kesteren написал(а):
An unrelated question about the same sentence is why the header
field value is matched case insensitively. My understanding is that
this rule was meant to prevent exposing unsuspecting servers to
requests that couldn't be made with
On Mon, 16 Mar 2009 12:29:34 +0100, Alexey Proskuryakov a...@webkit.org
wrote:
The difference is that when one does form enctype=TEXT/Plain, the
MIME type on the wire is text/plain, but with setRequestHeader, it's
TEXT/Plain. So, server-side code that does case-sensitive comparisons
13 matches
Mail list logo
