W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

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

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 30 Sep 2011 18:05:41 +0000 (UTC)
To: Anne van Kesteren <annevk@opera.com>
cc: public-webapps@w3.org, Henri Sivonen <hsivonen@iki.fi>
Message-ID: <Pine.LNX.4.64.1109301802140.29849@ps20323.dreamhostps.com>
On Fri, 30 Sep 2011, Anne van Kesteren wrote:
> FWIW, I am waiting for 
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=14284 to be fixed in HTML 
> before making changes to XMLHttpRequest.

So... the prescanning is generally considered optional (the only benefit 
really is that it avoids reloads in bad cases), and indeed implementations 
are somewhat encouraged to abort it early if the server only sent a few 
bytes (because that will shorten the time until something is displayed). 
Also, it has a number of false-positives, e.g. it doesn't ignore the 
contents of <script> elements.

Do we really want to put it into the critical path in this way?

I agree that the reloading alternative is even worse. What about just 
relying on the Content-Type charset="" and defaulting to UTF-8 if it isn't 
there, and not doing any in-page stuff?

How is the encoding determined for, e.g., text/plain or text/css files 
brought down through XHR and viewed through responseText?

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 30 September 2011 18:09:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:24 UTC