W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: [XHR] Some comments on "charset" in the Content-Type header

From: Anne van Kesteren <annevk@opera.com>
Date: Fri, 19 Sep 2008 15:30:44 +0200
To: "Boris Zbarsky" <bzbarsky@mit.edu>, public-webapps <public-webapps@w3.org>
Message-ID: <op.uhqc5iie64w2qv@annevk-t60.oslo.opera.com>

On Fri, 19 Sep 2008 14:20:56 +0200, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> These are comments for item 4 of the definition of send().
> 1) As currently defined, if data is a DOMString and no explicit
>     Content-Type header has been set, then no Content-Type header should
>     be sent.  Is this correct?  That seems a little odd to me, to be
>     honest.

This appears to be addressed as per Last Call comments you among others  
have made (iirc):


> 2) There is no definition of what "set the charset parameter of that
>     header to UTF-8" means.  It turns out that this needs to be done
>     pretty carefully for even minimal web compat.  See
>     <https://bugzilla.mozilla.org/show_bug.cgi?id=413974>.  What we
>     ended up having to implement is something like the following:
>     A) If there is already a charset parameter, replace its value with
>        the new value in the header string.
>     B) Otherwise insert a new charset parameter before all other
>        parameters in the header string.

Hmm, only B is not done currently. I suppose we could change that...

> 3) As currently defined, if data is a Document and a Content-Type has
>     been set by the page, its charset parameter is not supposed to be
>     modified.  This is inconsistent with the DOMString case, and
>     seems to easily allow situations in which the data is encoded
>     using data.inputEncoding but the charset parameter in
>     Content-Type has been set to something else entirely.  Is this
>     really desirable?

This no longer appears to be the case...

> 4) As mentioned in
>     <https://bugzilla.mozilla.org/show_bug.cgi?id=416178#c22> there
>     are apparently hardware firewalls that reject entities with a
>     charset parameter in the Content-Type (weird, yes, I know).  I'm
>     trying to get more information on this, but we might need a way
>     for authors to override this behavior somehow by forcing a charset
>     parameter to not be sent.

We could of course go back to not setting the charset parameter at all  
unless the author already set it using setRequestHeader()...

Anne van Kesteren
Received on Friday, 19 September 2008 13:31:17 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:12 UTC