Re: Lifetime of Blob URL

On Sun, Jul 11, 2010 at 10:05 PM, Adrian Bateman <adrianba@microsoft.com>wrote:

> 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.
>

Specifying the format of contents of the url is simply an
overspecification. Saying "User Agents that wish to include data such as
origin should do so by encoding it in an opaque manner." is ambiguious. As
soon as anyone publishes the format (which would be trivial to do given
chromium's open source), the format would no longer be opaque.



> 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.


Making the blob url identical to the lifetime of the blob itself would
expose when garbage collection takes place and in general could lead to easy
to make mistakes in which the developer had something that work mostly but
not always -- your situation below is just one of them.

Check out the Jian Li's alternate proposal (see his response to "Re: [File
API] Recent Updates To Specification + Co-Editor" on July 1, I think) that
addresses this in a way that addresses your concerns and the gc issue as
well.



> 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
>
>
>