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: Arun Ranganathan <arun@mozilla.com>
Date: Tue, 18 Aug 2009 11:38:07 -0700
Message-ID: <4A8AF50F.3040902@mozilla.com>
To: "Michael A. Puls II" <shadow2531@gmail.com>
CC: public-webapps@w3.org

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).

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.

-- A*
Received on Tuesday, 18 August 2009 18:38:51 UTC

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