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

Re: HTTP status code equivalents for file:// operations - compat with xhr

From: Michael A. Puls II <shadow2531@gmail.com>
Date: Tue, 18 Aug 2009 14:54:36 -0400
To: arun@mozilla.com
Cc: public-webapps@w3.org
Message-ID: <op.uyvf5aed1ejg13@sandra-svwliu01>
On Tue, 18 Aug 2009 14:38:07 -0400, Arun Ranganathan <arun@mozilla.com>  
wrote:

> Michael,
>
> I'd like to distinguish between file:// and filedata: which is what the  
> current FileAPI proposes. While file:// behavior is undefined and pretty  
> vague across user agents, filedata: is spec'd to be used within web  
> applications, has a lifetime, an origin policy, and does return a subset  
> of HTTP status codes (which are not 405 if requested with GET).  I'd say  
> that file:// is convenient for user agents to surface local files for  
> users, but filedata: could be used within web applications.  In  
> particular:
>
>>
>> 2. For file:// access, simulate the appropriate HTTP status code for  
>> the result so that this.status and this.statusText can be used properly.
>>
>> 3. Don't have open() throw for "file not found" and use 404 for  
>> this.status instead.
>>
>> 4. If file:// access isn't implemented (like in IE), don't have open()  
>> throw. Instead, make this.status be 501.
>>
>> 5. If the request URI result in too long of a path, use status code 414.
>>
>> 6. If the request URI points to a certain type of file the *browser*  
>> doesn't want to allow access to (maybe an .exe), use status code 415.
>>
>> 7. If a method besides "GET" is used for open(), don't throw and use  
>> status code 405.
>>
> These behaviors match what filedata: might do (but not exactly as you  
> say so above).
> http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html#filedataurl-if
>
> There are a few conditions that are not properly specified currently in  
> the editor's draft, but I'd like to remedy that soon :-)
>
> I think that the use cases you have for file:// being a first class  
> citizen of web (in terms of use across all request mechanisms) could be  
> applied to filedata: instead.

Thanks.

Using filedata: and the FileAPI instead of file: with xhr, seems like it'd  
work. However, how do you get a fileData object without <input  
type="file">?

Would you have to shoehorn it like the following?

function getLocalFileData(fileURI) {
     var input = document.createElement("input");
     input.type = "file"
     input.value = fileURI; // (relative or absolute) to local file
     return input.fileList.files[0];
}

-- 
Michael
Received on Tuesday, 18 August 2009 18:55:21 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT