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

> Firefox developers said they won't change their implementation of XHR with
> file: before the spec explicitly define the behavior,
> so it looks like a chicken-egg problem to me.

I guess.

> Also I'd like to know some general principles of introducing new URL schemes
> (like file:) into web standards:
> (1) Should new URLs mimic http's behaviors as much as possible? Such as
> status codes, content-type, etc.
> (2) Should XHR and static resource fetching behave consistently with new
> URLs?
> As a web developer, my personal answers are all yes.



Reply via email to