Re: New FileAPI Draft | was Re: FileAPI feedback

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