On Mon, Jun 30, 2014 at 3:57 PM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Mon, Jun 30, 2014 at 10:48 PM, Arun Ranganathan <arun@mozilla.com> > wrote: > > They are! That is, at the time the method URL.createObjectURL(blob) is > > called on blob, that method adds an entry to the Blob URL Store: > > http://dev.w3.org/2006/webapi/FileAPI/#add-an-entry > > > > I’ve only defined identifier extraction for use with adding an entry. Is > > that wrong? > > It seems like you could define identifier creation, use that, use the > return value to add an entry, and then return "blob:" + the return > value. Creating a URL first and then parsing it again to extract > something seems needlessly complicated. > Why would the identifier not just be the blob URL itself? The spec currently makes the identifier just the scheme data, which seems much more complex than it needs to be. revokeObjectURL should simply be "Remove the entry from the Blob URL Store for URL." If we want to allow revoking URLs that have a fragment attached it'd still need to strip it off; Firefox does this, but Chrome doesn't. Also, both Chrome and Firefox treat the entire URL as case-sensitive, eg. "Blob:..." won't revoke the URL, or uppercasing the hostname portion in Chrome. Using the whole URL as the identifier makes this easy to do. "Subsequent attempts to dereference url must return a network error" should be removed. That should already be the consequence of unregistering the URL, so this is a redundant requirement. -- Glenn Maynard
Received on Monday, 30 June 2014 23:13:59 UTC