Re: File API: Blob URL origin

On Mon, Jun 30, 2014 at 3:57 PM, Anne van Kesteren <> wrote:

> On Mon, Jun 30, 2014 at 10:48 PM, Arun Ranganathan <>
> 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:
> >
> >
> > 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