这是一个占位符错误,提醒我查看更新http.DetectContentType嗅探机制,以适应whatwg/mimesniff中的新增内容,即在没有ID3标签的情况下可以嗅探MP3。
这将需要将最大缓冲区大小从512更改为1445,并审查https://mimesniff.spec.whatwg.org/#signature-for-mp3-without-id3中描述的算法。我在看到这条推文https://twitter.com/mimesniff/status/888665270025420800后注意到了这个问题,它指向了PR whatwg/mimesniff#4。
可以在Go1.10版本开放时讨论这个问题。
9条答案
按热度按时间q43xntqr1#
如果DetectContentType的缓冲区大小要改变,是否可以为其设置一个导出的常量?目前我使用它时只是硬编码发送512字节。
ny6fqffe2#
此外,我需要实施本地更改 whatwg/mimesniff#27 和 whatwg/mimesniff#28 ,但我一直在等待上游明确他们的位置。不确定是否有必要实施已经明确的内容(例如,实施
application/vnd.ms-fontobject
和application/font-woff
)。6jjcrrmo3#
@odeke-em - 我只是想确认一下这是否在你的关注范围内?或者我可以花一些时间来处理这个问题并创建一个CL。
9jyewag04#
感谢agnivade的ping,请继续,这是你的。只需确保内容来自mimesniff.spec.whatwg.org,这是我们用于内容类型嗅探的资源。
bakd9h0s5#
太好了,谢谢。
qlzsbp2j6#
https://golang.org/cl/101375提到了这个问题:
net/http: sniffing mp3 content without ID3
tvmytwxo7#
只想提到mimesniff.spec.whatwg.org中的算法有轻微错误,这就是为什么我在我的CL中无法使其正常工作。正如这个问题所确认的那样 - whatwg/mimesniff#70 。
pdkcd3nj8#
感谢@agnivade解决了这个问题!whatwg/mimesniff规范尚未修复,我认为在这个周期内不会发生,所以或许将此推迟到Unplanned,我也会分配给你。
1l5u6lss9#
这里存在一个更深层次的问题。WHATWG的MIME嗅探规范是专门为浏览器设计的,而且仅限于浏览器。实际上,在介绍部分已经解释过了;我想我不是唯一一个在第一次阅读规范时没有注意到这一点的人。关键句子在最后一段:
本文档描述了一个内容嗅探算法,该算法仔细平衡了用户代理的兼容性需求与现有Web内容施加的安全约束。
因此,例如,当DetectContentType类将包含“GIF87a is over 30 years old”的文本文件分类为"image/gif"时,它正在正确地实现MIME规范。问题在于,WHATWG的算法不适用于浏览器处理安全下载文件的狭窄范围内。唉。