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*
