如果DetectContentType的缓冲区大小要改变，是否可以为其设置一个导出的常量？目前我使用它时只是硬编码发送512字节。

此外，我需要实施本地更改 whatwg/mimesniff#27 和 whatwg/mimesniff#28 ,但我一直在等待上游明确他们的位置。不确定是否有必要实施已经明确的内容(例如，实施 application/vnd.ms-fontobject 和 application/font-woff )。

@odeke-em - 我只是想确认一下这是否在你的关注范围内？或者我可以花一些时间来处理这个问题并创建一个CL。

感谢agnivade的ping,请继续，这是你的。只需确保内容来自mimesniff.spec.whatwg.org,这是我们用于内容类型嗅探的资源。

太好了，谢谢。

https://golang.org/cl/101375提到了这个问题：net/http: sniffing mp3 content without ID3

只想提到mimesniff.spec.whatwg.org中的算法有轻微错误，这就是为什么我在我的CL中无法使其正常工作。正如这个问题所确认的那样 - whatwg/mimesniff#70 。

感谢@agnivade解决了这个问题！whatwg/mimesniff规范尚未修复，我认为在这个周期内不会发生，所以或许将此推迟到Unplanned,我也会分配给你。

这里存在一个更深层次的问题。WHATWG的MIME嗅探规范是专门为浏览器设计的，而且仅限于浏览器。实际上，在介绍部分已经解释过了；我想我不是唯一一个在第一次阅读规范时没有注意到这一点的人。关键句子在最后一段：
本文档描述了一个内容嗅探算法，该算法仔细平衡了用户代理的兼容性需求与现有Web内容施加的安全约束。
因此，例如，当DetectContentType类将包含“GIF87a is over 30 years old”的文本文件分类为"image/gif"时，它正在正确地实现MIME规范。问题在于，WHATWG的算法不适用于浏览器处理安全下载文件的狭窄范围内。唉。