W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: New FileAPI Draft | was Re: FileAPI feedback

From: Arun Ranganathan <arun@mozilla.com>
Date: Mon, 17 Aug 2009 17:12:50 -0700
Message-ID: <4A89F202.9050403@mozilla.com>
To: "Nikunj R. Mehta" <nikunj.mehta@oracle.com>
CC: Gregg Tavares <gman@google.com>, Dmitry Titov <dimich@chromium.org>, Web Applications Working Group WG <public-webapps@w3.org>
Nikunj R. Mehta wrote:
> On Aug 12, 2009, at 7:29 AM, Arun Ranganathan wrote:
>> Gregg Tavares wrote:
>>> How about this?
>>> Why make a new API for getting the contents of a file (local or 
>>> otherwise)
>>> when we already have one which is XHR?
>>> What if FileList was just array of File objects where each File 
>>> object is
>>> just a URL in the format
>>> "filedata: uuid, filename"
>>> Then you can use that URL anywhere in HTML a URL is valid. script, img,
>>> audio, video, css, AND XHR
>>> That would mean you wouldn't be adding a new API to get the contents 
>>> of a
>>> file. If you want the contents just use XHR and use the URL from the 
>>> File in
>>> the FileList.
>>> You could add a few more functions to XHR like request.getAsDataURL(),
>>> request.getAsTextInEncodiing(), etc. if need be if they are neede
>> Today, it's possible to use XHR from "privileged web content" in 
>> Firefox to access file:// URLs; the drawback is that these don't 
>> return HTTP responses, and of course there are security considerations.
> As stated, the XHR algorithm for open() [1] allows relative references 
> and resolves them relative to the document base URI. Does that mean 
> that if the document was loaded using file: uri, then the XHR could be 
> used for loading a file?
Currently, this behavior is not standard, and there are interoperability 
issues across user agents.  Michael Puls II did ran some tests some time 
ago and posted these on this listserv:


> As a separate question, it would be necessary for proper operation of 
> XHR to always provide content-type and content-length headers when 
> providing a response entity body. Does Firefox provide these headers 
> when the XHR object is used to retrieve local file: representations?
Again, this isn't standard behavior, and Firefox doesn't provide these 
headers over file:// 

Separately, I disagree with Anne about restrictions on XHR, but don't 
wish to preempt that discussion till filedata: is better defined. 

-- A*
Received on Tuesday, 18 August 2009 00:13:40 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:18 UTC