Re: [XHR] responseType "json"

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.


>
> 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>