[Bug 17765] APIs need to take a reference to blob data underlying object URLs

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765

--- Comment #10 from Glenn Maynard <glenn@zewt.org> 2012-07-13 20:54:21 UTC ---
(In reply to comment #9)
> Right, but I don't want to tie the data to the API, just the URL. Otherwise all
> the APIs will have to special case blob URLs and that just seems unclean. So
> rewriting revoked blob URLs to about:invalid so the API can still fetch the
> blob URL as-is seems better.

If the blob URL is revoked at the time the resolve happens, then it can just do
nothing, as if it's not a blob URL at all.  The fetch would follow the same
failure path it does now.

Are we thinking of this the same way?  I'm not saying this should cause the
resolved URL to be different, just that the data would be attached as a
property.  For example, in JS-like terms (not quite, since you can't actually
put properties on strings):

function resolveURL(url)
{
    // ... perform other resolve steps
    var blob = getBlobFromURL(url);
    if(blob)
        url.blobData = blob.underlyingData;
    return url;
}

It still returns the same resolved URL, but (conceptually) the associated blob
data is attached to the URL string like a property, which fetch can check for
and use.  (There may be a clearer way to conceptualize this.)  The algorithm
resolving the URL wouldn't have to know anything about this (except possibly
for releasing the url.blobData reference).

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 13 July 2012 20:54:23 UTC