- From: Alexey Proskuryakov <ap@webkit.org>
- Date: Mon, 16 Mar 2009 14:07:22 +0300
- To: public-webapps <public-webapps@w3.org>
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. 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. - WBR, Alexey Proskuryakov
Received on Monday, 16 March 2009 11:08:01 UTC