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

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.

-- A*

Received on Tuesday, 18 August 2009 18:38:51 UTC