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 Content-Type or it does contain it and
the corresponding header field value is an ASCII case-insensitive match
for application/x-www-form-urlencoded, multipart/form-data, or
text/plain."
This forbids having a charset in Content-Type (e.g. text/plain;
charset=UTF-8). I doubt that this limitation is necessary, and it
prevents sending an XMLHttpRequest without preflight in this case.
Firefox seems to always append a charset to content type, even if
setContentHeader was used to specify the header explicitly, so simple
requests are effectively limited to GET and HEAD as a result. WebKit
currently does not do that, but will be similarly affected if a content
type with charset is specified via setRequestHeader.
I think that the algorithm can only compare MIME types, not the full
Content-Type string.
I guess that makes sense.
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 existing mechanisms such as form submission, and
I'd be quite surprised if any major browser used anything but lower case
here.
Media types are ASCII case-insensitive. E.g. if someone does
setRequestHeader("Content-type", "TEXT/Plain")
that should just work.
--
Anne van Kesteren
http://annevankesteren.nl/
