- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 27 Oct 2010 15:29:45 -0400
- To: Geoffrey Garen <ggaren@apple.com>
- CC: Darin Fisher <darin@chromium.org>, Chris Rogers <crogers@google.com>, Web Applications Working Group WG <public-webapps@w3.org>, Anne van Kesteren <annevk@opera.com>, Eric Uhrhane <ericu@google.com>, michaeln@google.com, Alexey Proskuryakov <ap@webkit.org>, Chris Marrin <cmarrin@apple.com>, jorlow@google.com, jamesr@chromium.org
On 10/27/10 2:56 PM, Geoffrey Garen wrote: > Quietly providing multiple copies of data creates a subtle memory use problem. Yes, agreed. > Explicitly throwing an exception at the site that tries to access the data in the wrong way obviously and immediately points a finger at the problem. Sort of. Except the failure happens at runtime in uncontrolled circumstances and people tend to sprinkle try-and-ignore-exceptions stuff in their web code. > The potential downside to an exception is not subtlety -- it's limited functionality: clients are no longer allowed to ask XHR to be more than one kind of data at once. That's one problem. The other problem is that it's easy for one client to break another without realizing it (possibly without both realizing it, depending on how testing is performed). That's the "subtlety" issue... > The question is, can library authors make their code compatible with this limitation? The issue isn't just libraries, but the interaction of libraries and library consumers and library consumers with each other... But yes, this is the main question. > I don't think it's possible to answer that question until someone fleshes out your assumption that libraries routinely intercept XHRs in transit and read their data. Which libraries do this, when, and why? jquery, offhand, layers API on top of XHR. Again, at this point I'd welcome comments from library authors. I think we're sort of at an impasse pending that in that clearly I'm not able to convince you and I don't think repeating the same thing over and over will convince me either. >> This make it impossible to decide whether to look at the text or the bytes based on the content-type of the response (unless you allow setting the attribute in some early-enough onStateChange callback _and_ libraries expose XHRs in that early a state to consumers); having that ability seems like a desirable feature. > > I'm not convinced that clients loading resources from their own domains somehow won't know the types of those resources. Why are you making the "from their own domains" assumption? > But, if we believe this is a real concern, it seems fine to me to allow responseType to be set some time after open, or even set implicitly by the first access to a certain view of the response. If we do go with the modal behavior, I would be _very_ opposed to the "first view" approach. That just makes the problems that worry me that much worse, since now it's _really_ easy for one consumer to screw over another without really realizing it's doing so, and debugging such a failure is very difficult. At least with the explicit flagging one can look for where such flagging took place.... -Boris
Received on Wednesday, 27 October 2010 19:30:21 UTC