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

Hi,

My first question is about a rule in MIME Sniffing specification (http://mimesniff.spec.whatwg.org):

   5.1 Interpreting the resource metadata
   ...
   If the resource is retrieved directly from the file system, set supplied-type to the MIME type
   provided by the file system. 

As far as I know, no main-stream file systems record MIME type for files. Does the spec actually want to say "provided by the operating system" or 
"provided by the file name extension"?

My second question is: does above rule apply equally to both fetching static resources (top level, iframe, img, etc) and XMLHttpRequest?

It seems all browsers try to figure out actual type for local static resources, so that .htm and .xhtml files are rendered as HTML and XHTML respectively, 
so far so good.

But when it comes to XHR, things are different. 

Firefox(31) set Content-Type header to 'application/xml' for local files of any type; and if setting xhr.responseType = 'document', response is parsed as XML; 
also if setting xhr.responseType = 'blob', blob.type is always 'application/xml'. This is significantly diverse from static fetching behavior.

Chromium(34) set Content-Type header to null for local files of any type; but if setting xhr.responseType = 'document', response is parsed according to its actual type, 
i.e. .htm as HTML and .xhtml as XHTML; and if setting xhr.responseType = 'blob', blob.type is the file's actual type, i.e. 'text/html' for .htm and 'application/xhtml+xml'
for .xhtml. This is similar to static fetching behavior, however Content-Type header is missing.

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?

Regards,
    Duan Yao.

Received on Thursday, 17 July 2014 12:27:28 UTC