At the recent TPAC for Working Groups held in San Jose, Adrian Bateman, Jonas
Sicking and I spent some time taking a look at how to remedy what the spec.
says today about Blob URLs, both from the perspective of default behavior and
in terms of what "correct" autoRevoke behavior should be. This email is to
summarize those discussions.
Blob URLs are used in different parts of the platform today, and are expected
to work on the platform wherever URLs do. This includes CSS, MediaStream and
MediaSource use cases [1], along with use of 'src='.
(Separate discussions about a "v2" of the File API spec, including use of a
Futures-based model in lieu of the event model, took place, but submitting a
LCWD with major interoperability amongst all browsers is a good goal for this
draft.)
Here's a summary of the Blob URL issues:
1. There's the relatively easy question of defaults. While the spec says that
URL.createObjectURL should create a Blob URL which has autoRevoke: true by
default [2], there isn't any implementation that supports this, whether that's
IE's oneTimeOnly behavior (which is related but different), or Firefox's
autoRevoke implementation. Chrome doesn't touch this yet :)
The spec. will roll back the default from "true" to "false". At least this
matches what implementations do; there's been resistance to changing the
default due to shipping applications relying on autoRevoke being false by
default, or at least implementor reluctance [1].
Switching the default to "false" would enable IE, Chrome, andFirefox to have
interoperability with URL.createObjectURL(blobArg), though such a default
places burdens on web developers to couple create* calls with revoke* calls to
not leak Blobs. Jonas proposes a separate method,
URL.createAutoRevokeObjectURL, which creates an autoRevoke URL. I'm lukewarm
on that :-\
2. Regardless of the default, there's the hard question of what to do with Blob
URL revocation. Glenn / zewt points out that this applies, though perhaps less
dramatically, to *manually* revoked Blob URLs, and provides some test cases
[3].
Options are:
2a. To meticulously special-case Blob URLs, per Bug 17765 [4]. This calls for
a synchronous step attached to wherever URLs are used to "peg" Blob URL data at
fetch, so that the chance of a concurrent revocation doesn't cause things to
behave unpredictably. Firefox does a variation of this with keeping channels
open, but solving this bug interoperably is going to be very hard, and has to
be done in different places across the platform. And even within CSS. This is
hard to move forward with.
2b.To adopt an 80-20 rule, and only specify what happens for some cases that
seem common, but expressly disallow other cases. This might be a more muted
version of Bug 17765, especially if it can't be done within fetch [5].
This could mean that the "blob" clause for "basic fetch"[5] only defines some
cases where a synchronous fetch can be run (TBD) but expressly disallows others
where synchronous fetching is not feasible. This would limit the use of Blob
URLs pretty drastically, but might be the only solution. For instance,
asynchronous calls accompanying <embed>, "defer" etc. might have to be
expressly disallowed. It would be great if we do this in fetch [5] :-)
Essentially, this might be to "do what Firefox does" but document what
"dereference" means [6], and be clear about what might break. Most
implementors acknowledge that use of Blob URLs simply won't work in some cases
(e.g. CSS cases, etc.). We should formalize that; it would involve listing
what works explicitly. Anne?
2c. Re-use oneTimeOnly as in IE's behavior for autoRevoke (but call it
autoRevoke). But we jettisoned this for race conditions e.g.
// This is in IE only
img2.src = URL.createObjectURL(fileBlob, {oneTimeOnly: true});
// race now! then fail in IE only
img1.src = img2.src;
will fail in IE with oneTimeOnly. It appears to fail reliably, but again,
"dereference URL" may not be interoperable here. This is probably not what we
should do, but it was worth listing, since it carries the brute force of a
shipping implementation, and shows how some % of the market has actively solved
this problem :)
3. We can lift origin restrictions in v2 on Blob URL; currently, one shipping
implementation (IE) actively relies on origin restrictions, but expressed
willingness to phase this out. Most use cases needing Blob data across origins
can be met without needing Blob URLs to not be origin restricted. Blob URLs
must be unguessable for that to happen, and today, they aren't unguessable in
some implementations.
-- A*
[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19594
[2] http://dev.w3.org/2006/webapi/FileAPI/#creating-revoking
[3] http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0294.html
[4] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765
[5] http://fetch.spec.whatwg.org/#concept-fetch
[6] http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0292.html
