Re: [XHR] responseType "json"

On Sun, Dec 11, 2011 at 9:08 AM, Jarred Nicholls <jarred@sencha.com> wrote:

> On Sun, Dec 11, 2011 at 5:08 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:
>
>> 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?
>>
>
> This does not satisfy the use cases of error reporting w/ contextual data
> nor the use case of debugging a runtime error in a production environment.
>

Given that most user agents send the payload to the console, the debugging
scenario is satisfied; so I renege on that.  Error reporting is still a
valid use case, albeit a rare requirement.


>
>
>>
>> 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).
>>
>
> Yes I agree, and it's what everyone w/ WebKit wants to try and accomplish.
>  A good compromise would be to only throw it away (and thus restrict
> responseText access) upon the first successful parse when accessing
> .response.
>
>
>>
>> ~TJ
>>
>
>
>
> --
> ................................................................
>
> *Sencha*
> Jarred Nicholls, Senior Software Architect
> @jarrednicholls
> <http://twitter.com/jarrednicholls>
>
>


-- 
................................................................

*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
<http://twitter.com/jarrednicholls>