于 2014年07月31日 02:02, Anne van Kesteren 写道:
On Tue, Jul 29, 2014 at 4:26 PM, 段垚 <duan...@ustc.edu> wrote:
于 2014/7/29 18:48, Anne van Kesteren 写道:
There's an enormous amount of tricky things to define around file
URLs, this being one of them.
Are there some resources on those "tricky things"?
No, not really. But it's a short list:
1) Parsing
2) Mapping a parsed file URL to an OS-specific filesystem
(case-sensitivity, case folding, ...)
3) Turning the resource into something that looks like a HTTP response
1 is for the URL Standard and would ideally be agnostic of OS. 2 and 3
would be for the Fetch Standard, if we were to define the details. I'm
hoping to get 1 done at least.
I feel that case handling is somewhat out-of-scope, because it is
OS-dependent, and even http urls may break
when migrating between OSs with different case sensitiveness.
What are the tricky parts of 3? I'm aware of content-type and status code.
I agree that file protocol is less important than http. However packaged web
applications (PhoneGap app, Chrome app, Firefox OS app, Window 8 HTML app,
etc) are increasing their popularity, and they are using file: protocol or
similar things to access their local assets. So I think it's worthwhile to
work on file
protocol to reduce porting issues of packaged web applications.
Well, "or similar" is important. Because those things are not really
similar at all but instead something that's actually portable across
systems and something we can reasonably standardize.
I don't think url schemes used by packaged web apps are much more
portable than file: for now.
Actually, they usually have very similar behaviors with file: on
corresponding browsers.
For example, Firefox OS app use app: scheme, and XHR treat any file as
XML; Chrome app
use chrome-extension: scheme, and XHR deduce mime type from file
extension, while Content-Type
header is missing.
Also some of these schemes are designed to be private and may not be
standardize.
In contrast, file: scheme has been standardized to some extend. If we
could fully standardize file:
first, schemes like app: and chrome-extension: would probably mimic its
behaviors.
