Re: [whatwg] How to determine content-type of file: protocol

于 2014年07月31日 02:02, Anne van Kesteren 写道:
> On Tue, Jul 29, 2014 at 4:26 PM, 段垚 <duanyao@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.

Received on Thursday, 31 July 2014 09:46:48 UTC