Re: [XHR2] Overriding the MIME type in XHR2 after the request has started

On Tue, Apr 19, 2011 at 2:18 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
> Adding [XHR2] to the subject to comply with the instructions. Sorry
> about the noise.
>
> On Tue, 2011-04-19 at 12:04 +0300, Henri Sivonen wrote:
>> In reference to
>> http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#dom-xmlhttprequest-overridemimetype
>>
>> It seems to me that XHR2 allows overrideMimeType() to be called at any
>> time so that it affects the calls to the responseXML getter the
>> overrideMimeType() call. And the subsequent overrideMimeType() calls can
>> make the responseXML getter return different things later.
>>
>> This is bad, because it requires synchronous parsing when the
>> responseXML getter is called. OTOH, if overrideMimeType() calls were
>> honored only before the send() method has been called, parsing to DOM
>> could be implemented progressively (potentially off-the-main-thread) as
>> the resource representation downloads and the responseXML getter could
>> return this eagerly-parsed Document and always return the same document
>> on subsequent calls.
>>
>> Are there compelling use cases for allowing overrideMimeType() after
>> send() has been called? I assume that typically one would use
>> overrideMimeType() when knowing ahead of time that the config of the
>> server responding to XHR is bogus.

There also seems to be a lot of details that needs to be defined if
overrideMimeType is allowed to be called at any point.

For example, are implementations expected to support changing charset
at any point? If so, that means that implementations have to keep
around the raw byte stream. This in addition to the
responseText/responseXML duplication that is already needed.

I had hoped that with .response/.responseType we would be moving
towards making XHR objects more lightweight rather than less so.

Could we at least limit overrideMimeType calls to only be allowed when
setting .responseType is allowed?

/ Jonas

Received on Tuesday, 19 April 2011 12:52:48 UTC