Lifetime of Blob URL

On Monday, June 28, 2010 2:47 PM, Arun Ranganathan wrote:
> On 6/23/10 9:50 AM, Jian Li wrote: 
> I think encoding the security origin in the URL allows the UAs to do
> the security origin check in place, without routing through other
> authority to get the origin information that might cause the check
> taking long time to finish.
>
> If we worry about showing the double schemes in the URL, we can
> transform the origin encoded in the URL by using base64 or other
> escaping algorithm.
>
> Jian: the current URL scheme: http://dev.w3.org/2006/webapi/FileAPI/#url
> allows you to do that, without obliging other UAs to do that.  Some
> UAs may elect to use "smart caching" to accomplish the same kinds of
> things, without tagging the URL with origin information.  Others may
> see benefit in origin-tagging.
>
> I've reconsidered trying to architect a scheme that allows all use-case
> scenarios for blob: URIs.

Hi Arun, I think the updated URL section reflects a good compromise. We
might want to call out explicitly that "opaque string" should not include
recognisable metadata to avoid scripts from trying to parse the URL. User
Agents that wish to include data such as origin should do so by encoding
it in an opaque manner.

I have one other concern about the lifetime of the blob URL [1]. The spec
currently says that blob: URLs should have the lifetime of the Document.
I think this is too long. An AJAX style web application may never navigate
the document and this means that every blob for which a URL is created
must be kept around in some form for the lifetime of the application.

In our discussions on this topic at Microsoft we've assumed that the
lifetime for a blob URL will be the same as the lifetime of the blob
itself. This does create something of a race condition. If I have a blob
representing an image where I set the src of an <img> element and then
let the blob go out of scope might it be collected before the <img> loads
the resource? We think we'll have to include some mechanism to ensure that
the blob and URL doesn't get collected before pending network requests
have been made.

This does impose an additional burden on the web developer: if they later
want to copy the source URL from one <img> to another then this will only
work if they also kept the blob in scope somewhere.

What do you think?

Cheers,

Adrian.

[1] http://dev.w3.org/2006/webapi/FileAPI/#lifeTime

Received on Monday, 12 July 2010 05:07:25 UTC