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