- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Fri, 19 Sep 2008 08:20:56 -0400
- 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 honest. 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. -Boris
Received on Friday, 19 September 2008 12:21:41 UTC