Re: [XHR] responseType "json"

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.

Comments, questions, and flames are welcomed!

Thanks,
Jarred

Received on Sunday, 11 December 2011 05:11:25 UTC