Re: [XHR2] responseText for text/html before the encoding has stabilized

On Fri, Sep 30, 2011 at 5:40 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
> On Fri, Sep 30, 2011 at 3:35 PM, Anne van Kesteren <annevk@opera.com> wrote:
>> On Fri, 30 Sep 2011 14:29:32 +0200, Henri Sivonen <hsivonen@iki.fi> wrote:
>>>
>>> On Fri, Sep 30, 2011 at 3:04 PM, Anne van Kesteren <annevk@opera.com>
>>> wrote:
>>>>
>>>> I do not see why "text" and "moz-chunked-text" have to be the same.
>>>> Surely we do not want XML encoding detection to kick in for chunks.
>>>
>>> Does "text" and default need to be the same for responseText for
>>> text/html and XML types? It seems annoying to have to run the <meta>
>>> prescan or to run the XML declaration detection without running a full
>>> parse in the "text" mode.
>>
>> Unless we disable responseText and responseXML when responseType is not the
>> empty string I am not sure that makes sense.
>
> responseType is a newish feature. If it's OK for responseType ==
> "chunked-text" to use encoding determination rules that differ from
> responseType == "" or responseType == "document", why should
> responseType == "text" have to be consistent with responseType == ""
> instead of being consistent with responseType == "chunked-text"?

I agree. In fact, I think it's much more important that
responseType=="chunked-text" is consistent with responseType=="text",
than for responseType=="text" to be consistent with responseType=="".

Unless responseType=="" or responseType=="document" I don't think we
should do *any* HTML or XML parsing. Even the minimal amount needed to
do charset detection.

For responseType=="text" we currently *only* look at http headers and
if nothing is found we fall back to using UTF8. Though arguably we
should also check for a BOM, but don't currently.

This is how Gecko has behaved since we implemented responseType=="text".

/ Jonas

Received on Friday, 30 September 2011 17:06:03 UTC