Re: Lazy Blob

The URLObject proposal is a pretty slick way of cooking up a request in
contextA for later (and all manner of) retrieval in contextB.


On Thu, Aug 2, 2012 at 4:23 PM, Glenn Maynard <glenn@zewt.org> wrote:

> I'd suggest the following.
>
> - Introduce an interface URLObject (bikeshedding can come later), with no
> methods.  This object is supported by structured clone.
> - Add XMLHttpRequest.getURLObject(optional data), which returns a new
> URLObject.  This can only be called while XMLHttpRequest is in the OPENED
> state.  The returned URLObject represents the resource that would have been
> fetched if xhr.send() had been called.  No XHR callbacks are performed, and
> no network activity takes place.  The "data" argument acts like send(data),
> to specify the request entity body that will be sent.
> - Adjust URL.createObjectURL to take (Blob or URLObject), which returns a
> URL that works the same way as Blob URLs.
>
> Example:
>
>
> var xhr = new XMLHttpRequest();
> xhr.open("GET", "resource.jpg");
> var urlObject = xhr.getURLObject();
> var newURL = URL.getObjectURL(urlObject);
> img.src = newURL;
>
> Some benefits:
>
> - We inherit XHR's ability to manipulate the request (eg.
> setRequestHeader), and all the security considerations that have gone into
> it.
> - The result is very much like Blob: you can transfer it around where you
> want it (workers or other pages), create object URLs, and then use those
> URLs with every other API (including Web Sockets, incidentally), since
> they're just like blob URLs.
> - It avoids a huge pitfall of "getBlobFromURL", by not implementing a
> whole new mechanism for specifying a request.  We already have XHR.
> - It avoids the pitfalls of returning a Blob: we don't make any network
> request at all at creation time to learn the size (avoiding spamming
> hundreds of HEAD requests), and it won't run into problems with servers
> with broken HEAD, transfer encodings, and so on.
>
> Any fetches performed as a result of this would be done under the origin
> of the page that created it, even if you transfer a URLObject somewhere
> else.  This seems safe, since the caller can do nothing with it except
> trigger a fetch as-is, but it would need careful security review (as would
> any API like this).  Passing one of these URLs back to XHR would need extra
> consideration (eg. should you be able to specify more headers?).
>
> (Note that I've spent some time thinking about this because I think it's
> technically interesting, but I haven't looked over the use cases closely
> enough to say whether I think it'd be worthwhile or not.)
>
> --
> Glenn Maynard
>
>