Re: revokeObjectURL behavior

On Wed, Nov 17, 2010 at 6:42 AM, Jonas Sicking <> wrote:

> Hi All,
> We have at length discussed what revokeObjectURL should be called, and
> where it should live. However we haven't yet discussed how it should
> behave.
> In particular, there is one edge case that I'm concerned about. Consider:
> myurl = window1.URL.createObjectURL(myblob);
> window2.URL.revokeObjectURL(myurl);
> in this example window1 and window2 are separate, but same origin,
> windows (for example window2 could be an iframe inside window1).
> The question is, should the call to revokeObjectURL succeed, do
> nothing, or throw an exception. One important aspect here is that if
> the two windows are not same origin, and the code in window2 simply
> guesses a url to revoke, then we definitely don't want the revoke to
> succeed. While implementations should take steps to make URLs
> unguessable, it is good to have extra layers of security by not
> allowing different origins to unregister each others URLs.
> Another concern I have is that silently doing nothing is bad for APIs
> that are intended to free resources. It makes it very easy to create
> the situation where a author think they are revoking a URL, but in
> reality are not.
> I think for safety, I'm leaning towards saying that different
> same-origin windows can unregister each others URLs. But if
> revokeObjectURL is called with a string that is not a same-origin URL,
> it does nothing (other than possibly warning in error consoles if the
> UA so desires).

This is what we currently assume. Thanks.

> Let me know what you think.
> / Jonas

Received on Tuesday, 16 November 2010 23:09:31 UTC