W3C home > Mailing lists > Public > public-webapi@w3.org > August 2007

Re: [XHR2] overrideMimeType

From: Alexey Proskuryakov <ap-carbon@rambler.ru>
Date: Wed, 01 Aug 2007 12:01:43 +0400
To: Jonas Sicking <jonas@sicking.cc>
CC: Maciej Stachowiak <mjs@apple.com>, Web APIs WG <public-webapi@w3.org>
Message-ID: <C2D626A7.3A7F6%ap-carbon@rambler.ru>

On 7/31/07 2:48 AM, "Jonas Sicking" <jonas@sicking.cc> wrote:

>>> Yep. Though it still seems weird to me that responseText would change
>>> when .overrideMimeType is changed. How do you guys deal with this situation?
>>   Currently, we only honor MIME type (not charset) change after the response
>> bytes start to arrive, and only if responseXML hasn't been accessed yet.
> So setting overrideMimeType does different things before and after the
> load starts? That doesn't seem very ideal either.

  I'd say that this behavior is reasonable, as long as the implementation
doesn't need to keep the original response bytes. I don't expect it to be a
practical compatibility concern if we start to honor the charset in
overrideMimeType after the load, assuming XHR2 will require implementations
to keep a copy of raw response bytes. Yes, responseText and responseXML may
change, but the user's code explicitly asks for that.

  Another quirk is that we don't let overrideMimeType drop existing charset.
E.g. if the HTTP response indicated "text/plain; charset=koi8-r", and
overrideMimeType was called with "application/xml" parameter (before or
after sending the request), the response will still be decoded as KOI8-R. I
suggest that this behavior is specified in XHR2.

- WBR, Alexey Proskuryakov
Received on Wednesday, 1 August 2007 08:02:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:57 UTC