On Fri, 19 Sep 2008 14:20:56 +0200, Boris Zbarsky <[EMAIL PROTECTED]> 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):
http://dev.w3.org/2006/webapi/XMLHttpRequest/#send
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
<http://annevankesteren.nl/>
<http://www.opera.com/>
