Re: Lazy Blob

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