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

revokeObjectURL behavior

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 16 Nov 2010 11:42:25 -0800
Message-ID: <AANLkTin4xDc2UhLhzRJEzPLgBFsQF6W=ntRy4-9-bFni@mail.gmail.com>
To: Webapps WG <public-webapps@w3.org>
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).

Let me know what you think.

/ Jonas
Received on Tuesday, 16 November 2010 19:43:20 GMT

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