于 2014/7/29 18:48, Anne van Kesteren 写道:
On Thu, Jul 17, 2014 at 2:26 PM, duanyao <duan...@ustc.edu> wrote:
I think rule 5.1 should be applied to both static fetching and XHR 
consistently. Browsers should set Content-Type header to local files' actual 
type for XHR, and interpret
them accordingly. But firefox developers think this would break some existing 
codes that already rely on firefox's behavior
(see https://bugzilla.mozilla.org/show_bug.cgi?id=1037762).

What do you think?
Basically, this comes down to what
http://fetch.spec.whatwg.org/#basic-fetch should do. "For now,
unfortunate as it is, file and ftp URLs are left as an exercise for
the reader."

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"?
My theory to date has been that defining
those things has less benefit than defining other things, such as
parsing URLs or the way fetching works in general.
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.
If someone were to
sort the issues out and get implementations to converge I would
certainly not be opposed to including the result of such work in the
specification.
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.

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.

Regards,
    Duan Yao.


Reply via email to