W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 7 Nov 2011 09:18:26 -0800
Message-ID: <CA+c2ei_Dav1RvffZ2DsZJqhvWFEspHWq=Uqof3Dm-90h8T+JXg@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: public-webapps@w3.org
On Mon, Nov 7, 2011 at 7:43 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
>> Also, the current spec leads to quite strange results if we end up
>> supporting more text-based formats directly in XHR. For example in
>> Gecko we've added experimental support for parsing into JSON. If we
>> added this to a future version of XHR, this would mean that if a JSON
>> resource was served as a "text/html" Content-Type, we'd simultaneously
>> parse as HTML in order to detect encoding, and JSON in order to return
>> a result to the page.
> responseType == "" being weird that way with XML isn't new. I guess
> the main difference is that mislabeling JSON as text/html might be
> more probable than mislabeling as XML when e.g. PHP default to
> text/html responses.
> One way to address this is to not support new response types with
> responseType == "" and force authors to set responseType to "json" if
> they want to read responseJSON.

Yes, I absolutely think that we should require authors to set
.responseType to "json" in order to parse as JSON. However JSON
parsing is still based on the response text and the spec requires the
response text to depend on HTML parsing any time the content type is
"text/html", no matter what .responseType is.

Hence I'm suggesting we change the spec.

>> There is also the issue of if we should take into account the encoding
>> of the page which started the XHR (we do for navigation at least in
>> Gecko), as well as if we should take user settings into account. I
>> still believe that we'll exclude large parts of the world from
>> transitioning to developing "AJAX" based websites if we drop all of
>> these things, however I have not yet gathered that data.
> I think we shouldn't take the encoding of the invoking page into
> account. We have an excellent opportunity to avoid propagating that
> kind of legacy badness. I think we should take the opportunity to make
> a new feature less crazy.

The contents is already out there. So it wouldn't so much an
"opportunity", but rather a choice to simply not support a large body
of documents that already exist.

/ Jonas
Received on Monday, 7 November 2011 17:19:30 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:36 UTC