This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://trac.tools.ietf.org/wg/websec/trac/query?component=mime-sniff and http://tools.ietf.org/wg/websec/minutes?item=minutes82.html http://tools.ietf.org/agenda/82/slides/websec-2.pdf
(In reply to comment #0) > http://trac.tools.ietf.org/wg/websec/trac/query?component=mime-sniff > > http://tools.ietf.org/agenda/82/slides/websec-2.pdf I'll get to these after I complete the rewrite. > and http://tools.ietf.org/wg/websec/minutes?item=minutes82.html Is there any actionable information here?
(In reply to comment #1) > (In reply to comment #0) > > http://trac.tools.ietf.org/wg/websec/trac/query?component=mime-sniff > > > > http://tools.ietf.org/agenda/82/slides/websec-2.pdf > > I'll get to these after I complete the rewrite. To expedite this process, it would be helpful if the issues that remain relevant after the rewrite are filed individually here in this Bugzilla component and marked as blocking this bug. Many of them were filed over a year ago, and it's not clear how (or whether) they relate to the current state of the document.
Based on a quick review on 11/5/2012 I think most all of the comments raised are still relevant. FTP and file systems do not supply content-types, and sniffing uses file extensions.
(In reply to comment #3) > Based on a quick review on 11/5/2012 I think most all of the comments raised > are still relevant. A lot of them seem rather speculative to me, so I'd appreciate it if they were refiled here with more detailed descriptions about what the issue is and what current behavior is. > FTP and file systems do not supply content-types, and sniffing uses file > extensions. As currently written, the spec does not describe how media type is determined by the file system or protocols that are not HTTP. That behavior is left undefined or defined by other documents. A previous draft of the spec went so far as to say that no file sniffing should be done at all for protocols such as FTP. The spec also makes clear that file extensions are not to be used for resources retrieved via HTTP. I'm not really sure what behavior you're desiring here for non-HTTP resources.
I fixed Ticket #20: https://github.com/whatwg/mimesniff/commit/75c2afdefe39b01a00f133a4125d58bd46f88d79
Regarding Ticket #21: XML types are already assumed to be tagged correctly. Sniffing XML types is very limited. However, other polyglot types are not handled properly at this point. ZIP is probably the most egregious, since ZIP-based types will all explicitly be sniffed as ZIP; perhaps ZIP should be handled similarly to XML. Examples such as TIFF vs. DNG are not mentioned at all, so their sniffing is undefined.
Filed bug 19989 for the ZIP issue. The following IETF websec issues are either handled by the current draft of the mimesniff document or are wontfix: #15, #17, #18, #19, #16. Please mark them as appropriate in the websec tracker and file any related outstanding concerns here in Bugzilla. Please also make note in the respective websec tracker issues of the bugs on file here on Bugzilla for some of the remaining issues, and of the issues that have already been fixed. I await Hixie and Anne's thoughts regarding issue #22. Also, it is not clear to me what to do with issue #24; I'm not sure how related the mimesniff spec is to Widget Packaging and XML Configuration at this point.
Regarding #24, you can probably ignore that. There have not been any interoperability issues reported ... so, if it ain't broke, you know... However, the app:// URI scheme does rely heavily on this specification to work out the content type of things inside zip packages: http://appuri.sysapps.org/ We should make sure the specs stay aligned.
https://github.com/whatwg/mimesniff/issues/99