- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 30 Sep 2011 10:05:06 -0700
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: public-webapps@w3.org
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