File API For Review | was Re: Blob URL Origin

The 2 June 2014 Editor’s Draft of the File API solves some bugs and technical issues with Blob URLs. Review is encouraged, with a view towards a LCWD publication:

http://dev.w3.org/2006/webapi/FileAPI/

In particular:

1. It nails down syntax differences between user agents on Blob URLs. 
2. It specifies origin and origin extraction from Blob URL strings.
3. It provides other pieces of plumbing that specifications like URL and Fetch can use.

A few issues remain, but all of these have dependencies:

https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=arun%40mozilla.com&emailassigned_to1=1&emailreporter1=1&emailtype1=exact&list_id=38706

Notably, dependencies on Fetch (for Fetch of Blob URLs), and dependencies on WebIDL (e.g. removing DOMError altogether requires something done for error handling; supplanting FileList with array requires this part nailed down). I’m happy to have provisional specification text in place before WebIDL adopts fixes, but with guidance from the editor(s) of WebIDL.

I expect a CfC to follow about the specification.

— A*


On May 29, 2014, at 5:42 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Thu, May 29, 2014 at 8:38 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Thu, May 22, 2014 at 1:29 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>>> For fetching blob URLs (and prolly filesystem and indexeddb) we
>>> effectively act as if the request's mode was same-origin. Allowing
>>> tainted cross-origin requests would complicate UUID (for the UA) and
>>> memory (for the page) management in a multiprocess environment.
>> 
>> Hmm.. I think that is effectively it yes. I.e. even though <img> says
>> that it wants to permit cross-origin loads, we'd override that if the
>> fetch is for a blob: URL and only permit same-origin loads. Is that
>> what you mean?
> 
> Yes.
> 
> However, I wonder if this at a standards level should come into play
> in the URL parser. After all that creates a structured clone of the
> blob in question. The lookup for the blob ID should probably fail at
> that point meaning it does not really matter when you then try to
> fetch that URL as it will simply not have an associated blob.
> 
> 
> -- 
> http://annevankesteren.nl/
>

Received on Wednesday, 4 June 2014 16:20:17 UTC