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

Re: [CORS] Charset in content type

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 19 Mar 2009 11:41:28 -0700
Message-ID: <63df84f0903191141m9ad0f8bkce7ad76cb0efd58@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: Alexey Proskuryakov <ap@webkit.org>, public-webapps <public-webapps@w3.org>
On Tue, Mar 17, 2009 at 6:40 AM, Anne van Kesteren <annevk@opera.com> wrote:
> On Mon, 16 Mar 2009 11:12:01 -0000, Anne van Kesteren <annevk@opera.com>
> wrote:
>>
>> On Mon, 16 Mar 2009 12:07:22 +0100, Alexey Proskuryakov <ap@webkit.org>
>> wrote:
>>>
>>> I think that the algorithm can only compare MIME types, not the full
>>> Content-Type string.
>>
>> I guess that makes sense.
>
> I made this change now (defined in the "simple header" definition), but I
> left the ASCII case-insensitive comparison for now. If we really want
> normalization we should do that for XMLHttpRequest in general I think.

Two things that I think we need to watch out for:

1. Someone doing
    xhr.setRequestHeader("Content-Type", "text/plain; application/xml");

2. Someone doing
    xhr.setRequestHeader("Content-Type", "text/plain;
somewierdthing=application/xml");

Especially the first might be tricky since we don't know which
mimetype the server will use. I was going to make our implementation
require that there is only one "empty" parameter, and optionally a
charset.

As for where the normalization is done, I don't really care. But since
every spec using CORS will have to do the same normalization it seems
like doing that in the CORS spec makes more sense.

/ Jonas
Received on Thursday, 19 March 2009 18:42:04 GMT

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