Re: [CORS] Charset in content type

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