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

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Fri, 19 Sep 2008 08:20:56 -0400
Message-ID: <48D39928.8080709@mit.edu>
To: public-webapps <public-webapps@w3.org>

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
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.
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?
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.

Received on Friday, 19 September 2008 12:21:41 UTC

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