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

Re: [XHR] responseType "json"

From: Jarred Nicholls <jarred@webkit.org>
Date: Sat, 10 Dec 2011 12:42:53 -0500
Message-ID: <CANufG2PbjFmhaVh4TjmBKS9kBegMW_cjs0SChXrwE9_oMt2CGQ@mail.gmail.com>
To: public-webapps@w3.org
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

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:

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.

Comments, questions, and flames are welcomed!

Received on Monday, 12 December 2011 11:28:39 UTC

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