W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: revokeObjectURL behavior

From: Jian Li <jianli@chromium.org>
Date: Wed, 17 Nov 2010 10:09:00 +1100
Message-ID: <AANLkTi=qaxwGUkQNvUtVdC-mzOCXEJt8V-4L8QqxVk1x@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Webapps WG <public-webapps@w3.org>
On Wed, Nov 17, 2010 at 6: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).
>

This is what we currently assume. Thanks.

>
> Let me know what you think.
>
> / Jonas
>
>
Received on Tuesday, 16 November 2010 23:09:31 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:42 GMT