- From: Anne van Kesteren <annevk@opera.com>
- Date: Wed, 28 Mar 2012 12:26:34 +0200
- To: "Jonas Sicking" <jonas@sicking.cc>
- Cc: "Glenn Maynard" <glenn@zewt.org>, "public-webapps WG" <public-webapps@w3.org>
On Wed, 28 Mar 2012 10:51:59 +0200, Jonas Sicking <jonas@sicking.cc> wrote: > On Wed, Mar 28, 2012 at 2:17 AM, Anne van Kesteren <annevk@opera.com> > wrote: >> What does dereferencing mean exactly? > > It means "initiating the load" or some such. Implementation-wise for > blob URLs it would likely mean going through the blob-url hash table > to find the underlying Blob object and start a read from it. So if the > URL is removed from the hash using revokeObjectURL this wouldn't > affect the load. Likewise for the FileSystem API it would mean that a > read from the blob has started and so any writes need to be queued > until after the read is finished. > >> xhr.open() resolves URLs currently and then xhr.send() will fetch the >> URL. > > Yup, this is the stuff that needs to be defined. In Gecko we actually > "dereference" the URL in xhr.open which means that the caller can call > revokeObjectURL after the call to xhr.open but before xhr.send. But > it's certainly possible to change this so that the URL is dereferenced > in xhr.send instead. Given that the start of the fetch algorithm http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#fetch is synchronous maybe dereferencing can be defined as part of that. The change to XMLHttpRequest that would be needed then is to invoke fetch before returning from send(). Not sure how well that would work for other contexts such as <img> and 'background-image' though. -- Anne van Kesteren http://annevankesteren.nl/
Received on Wednesday, 28 March 2012 10:27:09 UTC