Re: revokeObjectURL behavior

On Tue, Nov 16, 2010 at 11:42 AM, Jonas Sicking <jonas@sicking.cc> 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).

Given the per-window semantics of these URLs, it seems a odd that a
URL coined in one window is revocable via another window.  Is there a
use-case in mind that would rely on being able to revoke thru any of
the origin's windows?

The other obvious choice is that a window only knows how to revoke a
URL that it has explicitly coined which I think has clearer semantics.
These semantics, along with silent error handling, match what is
implemented in webcore right now (albeit with the methods bound to the
window object for now).

Jian... you said... "This is what we currently assume."
Do you have changes in the works to alter the current semantics/impl
in webcore? If so, what's motivating that change?

>
> Let me know what you think.
>
> / Jonas
>
>

Received on Thursday, 18 November 2010 22:05:24 UTC