W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: Lazy Blob

From: Michael Nordman <michaeln@google.com>
Date: Thu, 2 Aug 2012 18:43:00 -0700
Message-ID: <CAHpoE=hD-XzSt1uUcq6Z4UrYX8YON6rG86hWCWZEEFWrNws-ww@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Robin Berjon <robin@berjon.com>, WebApps WG <public-webapps@w3.org>, Jungkee Song <jungkee.song@samsung.com>
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
Received on Friday, 3 August 2012 01:43:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:37 UTC