前言
所以 IE 会做Mime-Type sniffing。那部分是旧消息。
关于如何对抗它的建议往往是“提供内容类型的 IE 信任”（即任何不是文本/纯文本或应用程序/八位字节流的内容）或“在文件开头添加无关数据”这绝对是你所服务的类型'。
现在，我正在开发一个应用程序，它必须允许消息附件（如在电子邮件中），偶尔内联显示（再次如在电子邮件中），并且我们想要关闭 XSS 向量。IE 的 mime 嗅探（在未修补的 IE6 中，我必须支持，例如 IE6/Win2000）是这些向量之一 -text/plain具有 html 内容的文件将作为 html 触发。在这一点上，重新编码不是一个选项，更改用户提供的附件只有在绝对不怀疑文件的恶意性时才会发生 - 并且有人可能希望将 HTML 作为文本发送。
现在，微软的 MSDN 文章暗示这种情况可能比宣传的更容易解决：
如果 Internet Explorer 知道指定的 Content-Type并且没有 Content-Disposition数据，Internet Explorer 将执行“MIME 嗅探”， [...]
伟大的！
除了我没有 IE 也没有当前的方法来可靠地安装它（我意识到这对于 web 开发人员来说是一个相当可悲的状态，我希望尽快解决这个问题）而且这是我似乎不太明白的灰色理论以一种或另一种方式得到确认。当地消息人士称，这行是胡说八道——IE 会模仿Content-Disposition: inline / 的任何内容，并且对于<default>-Type的口味不够具体。
但是 x-* （RFC 中的 'extension-token'）呢？
尝试用谷歌搜索浏览器如何处理Content-Disposition:<extension-token>并没有产生任何结果（尽管我可能只是做错了，但我最近对谷歌的理解严重下滑）。我发现了一个看起来很有希望的问题，但结果证明是线程作者一方的误解，这意味着思路实际上从未在那里得到解决。
问题）
如果您明确传递Content-Disposition: inline，IE 真的会嗅探吗？
如果是这样：这里有人知道浏览器如何处理Content-Disposition:<extension-token>吗？
如果他们以对我的目的有益的方式这样做，假设它与默认值同义（实际上是“内联”，尽管我听说它没有在任何地方定义？），它是否足够具体到 IE不去Mime 嗅探？或者我真的是在考虑追求这条道路而自取其辱？