Re: [CORS] Charset in content type

It strikes me that there are actually two issues here:

1. What constitutes a simple request for the purposes in CORS?  As far  
as that's concerned, I suspect that Alexey has it right.

2. Who should set charset parameter for XMLHttpRequest?  The code  
invoking it or the underlying engine?  I'm having a hunch here that  
having the JavaScript code setting that parameter is going to be a  
source of gratuitous interoperability problems.  Is that covered in  
the XHR spec already, has it been considered at all, .....?

Excuse my ignorance,
--
Thomas Roessler, W3C  <tlr@w3.org>







On 16 Mar 2009, at 12:12, Anne van Kesteren wrote:

> 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:23:09 UTC