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

Re: [XHR] responseType "json"

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Sun, 11 Dec 2011 02:08:17 -0800
Message-ID: <CAAWBYDBVSvAWzeg87hhaCkjg6cqK+zrtew9gajt0RPn7ThwOJQ@mail.gmail.com>
To: Jarred Nicholls <jarred@sencha.com>
Cc: public-webapps@w3.org
On Sat, Dec 10, 2011 at 9:10 PM, Jarred Nicholls <jarred@sencha.com> wrote:
> I'd like to bring up an issue with the spec with regards to responseText +
> the new "json" responseType.  Currently it is written that responseText
> should throw an exception if the responseType is not "" or "text".  I would
> argue that responseText should also return the plain text when the type is
> "json".
> Take the scenario of debugging an application, or an application that has a
> Error Reporting feature; If XHR.response returns "null", meaning the JSON
> payload was not successfully parsed and/or was invalid, there is no means to
> retrieve the plain text that caused the error.  "null" is rather useless at
> that point.  See my WebKit bug for more
> context: https://bugs.webkit.org/show_bug.cgi?id=73648
> For legacy reasons, responseText and responseXML continue to work together
> despite the responseType that is set.  In other words, a responseType of
> "text" still allows access to responseXML, and responseType of "document"
> still allows access to responseText.  And it makes sense that this is so; if
> a strong-typed Document from responseXML is unable to be created,
> responseText is the fallback to get the payload and either debug it, submit
> it as an error report, etc.  I would argue that "json" responseType would be
> more valuable if it behaved the same.  Unlike the binary types (ArrayBuffer,
> Blob), "json" and "document" are backed by a plain text payload and
> therefore responseText has value in being accessible.
> If all we can get on a bad JSON response is "null", I think there is little
> incentive for anyone to use the "json" type when they can use "text" and
> JSON.parse it themselves.

What's the problem with simply setting responseType to 'text' when debugging?

A nice benefit of *not* presenting the text by default is that the
browser can throw the text away immediately, rather than keeping
around the payload in both forms and paying for it twice in memory
(especially since the text form will, I believe, generally be larger
than the JSON form).

Received on Sunday, 11 December 2011 10:09:06 UTC

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