W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

[CORS] Charset in content type

From: Alexey Proskuryakov <ap@webkit.org>
Date: Mon, 16 Mar 2009 14:07:22 +0300
Message-Id: <169ABB72-1BEE-4A77-991C-DF29D22A067B@webkit.org>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:30 GMT