This is an umbrella bug for adding support for getting the response as a blob. Two new additions for the XHR interface in support of this. This is not entirely solidified yet, still pending some discussion on the public lists. boolean attribute asBlob; // Prepares the XHR to make the response available as a blob object. // Defaults to false, must be set after calling open() and // prior to calling send(). Gets reset upon subsequent calls to open(). // Throws INVALID_STATE_ERR if set at an invalid time. Maybe read at // anytime without exception. Blob attribute responseBlob; // Returns a blob the contains the response body. // Only valid to access when asBlob is true and when the request is in // a terminal state. Throws INVALID_STATE_ERR if accessed at an // invalid time. When asBlob is true, the other response accessors (responseText, resonseXML, responseBody) throw INVALID_STATE_ERR if accessed. We're making this "modal" for the benefit of the browser vendors, to make it easier for them to know how to handle the response data as it comes in. With a priori knowlege that the data need never be made available thru the responseText attribute, life is a little easier for them/us. Also see http://code.google.com/p/chromium/issues/detail?id=52486
Script bindings are being taken care of in... https://bugs.webkit.org/show_bug.cgi?id=44133
Created attachment 65629 [details] n/a ChangeLog comments
Comment on attachment 65629 [details] n/a ooops... attached patch to the wrong bug
Any updates on this? I'm volunteering... The spec has changed and responseBlob/asBlob are no longer applicable.
(In reply to comment #4) > Any updates on this? I'm volunteering... > The spec has changed and responseBlob/asBlob are no longer applicable. Hi Jarred, I've been dragging my feet on this for two reasons. 1) The "arraybuffer" type can be used to satisfy many cases "blob" would also work well for. And constructing a Blob given an ArrayBuffer is pretty straightforward if you really want/need a blob. 2) Our (chromium's) preferred strategy of implementing this requires some contentious 'layering violations'. In the "blob" case, the data need never be present in a renderer process in order to return a Blob. For that to work, the ResourceHandle (platform layer) logically needs to produce a Blob (webcore layer), hence the layering violation. Getting to a workable solution that achieves the goal outlined in #2 is not so straightforward, and given #1, the motivation just hasn't been there to do it. Having the API be functional would certainly be nice, and there is a relatively self contained approach to getting it working for XHR by using a BlobBuilder from within XHR (similar to how m_binaryResponseBuilder is used for the "arraybuffer" case). I've been hesitant to do that because its inferior to #2, and honestly am concerned that it's presence could be used as a reason to reject later efforts to actually realize #2. So long as we (chrome) can come back latter an actually realize #2 for our port, doing an impl for the general case would probably be a good thing. At least then the API would be functional. Anyway... that's the update... what did you have in mind?
Understood completely. (In reply to comment #5) > Anyway... that's the update... what did you have in mind? I was just curious if this was still in the back of someone's mind. I understand the layering issue and the optimal case for a Blob to be able to be a handle to an out-of-memory resource that can have its data streamed on demand. I'm impartial to providing the working API in the interim, or not. But I'd like to think the optimal case wouldn't be forgotten nor argued just because we have something that works already in place.
There is no responseBlob property now, as response one took over it. Anyway, the feature is obviously implemented, and tracking it with a meta bug is not useful.