- From: Anne van Kesteren <annevk@opera.com>
- Date: Mon, 16 Mar 2009 12:12:01 +0100
- To: "Alexey Proskuryakov" <ap@webkit.org>, public-webapps <public-webapps@w3.org>
On Mon, 16 Mar 2009 12:07:22 +0100, Alexey Proskuryakov <ap@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/
Received on Monday, 16 March 2009 11:12:48 UTC