资源解释为文档，但使用MIMEtypes的应用程序/ zip传输
使用Chrome 12.0.742.112，如果我使用以下标题redirect：
HTTP/1.1 302 Found Location: http://0.0.0.0:3000/files/download.zip Content-Type: text/html; charset=utf-8 Cache-Control: no-cache X-Ua-Compatible: IE=Edge X-Runtime: 0.157964 Content-Length: 0 Server: WEBrick/1.3.1 (Ruby/1.9.2/2011-02-18) Date: Tue, 05 Jul 2011 18:42:25 GMT Connection: Keep-Alive 如果遵循则返回以下标题：
HTTP/1.1 200 OK Last-Modified: Tue, 05 Jul 2011 18:18:30 GMT Content-Type: application/zip Content-Length: 150014 Server: WEBrick/1.3.1 (Ruby/1.9.2/2011-02-18) Date: Tue, 05 Jul 2011 18:44:47 GMT Connection: Keep-Alive
Chrome将不会redirect，也不会更改上一页，只会在控制台中报告以下警告：
资源解释为文档，但使用MIMEtypes的应用程序/ zip传输。
该过程在Firefox中正常工作，如果我打开一个新标签并直接转到http://0.0.0.0:3000/files/download.zip在Chrome中也能正常工作。 我做错了什么，或者这是一个错误/奇怪的铬？
您可以在<a>标签中指定HTML5 下载属性。
<a href="http://example.com/archive.zip" download>Export</a>
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#attr-download
在您的请求标题中，您已经发送了Content-Type: text/html ，这意味着您想将响应解释为HTML。 现在，即使服务器发送给你PDF文件，你的浏览器试图把它理解为HTML。 那就是问题所在。 我正在寻找可能的原因。 🙂
在提供PDF文件（MIMEtypes的应用程序/ pdf）时遇到了这个问题，并通过设置Content-Disposition头来解决这个问题，例如：
Content-Disposition: attachment; filename=foo.pdf
希望有所帮助。
我已经解决了这个问题…只需打开一个新标签。
为什么它不起作用我不完全确定，但这可能与Chrome如何处理页面上多次下载有关，也许它认为它们是垃圾邮件，而忽略它们。
我无法find任何地方只是自己的消息的解释 。 这是我的解释：
据我所知，Chrome期待着他可能展示的一些资料（一份文件 ），但是却获得了他不能做的事情，或者被告知不要这样做。
这既是如何在href的HTML页面声明文档的问题（请参阅Roy的消息中的下载属性）以及如何通过HTTP标头（特别是Content-Disposition ）在服务器的答案中声明文档。 这是一个合同问题，而不是希望和期望。
继续在埃文的路上，我体验到：
Content-type: application/pdf Content-disposition: attachment; filename=some.pdf
只是不一致而已
<a href='some.pdf'>
铬将哭资源解释为文件，但转移…。
实际上， 附件configuration就是这样的：浏览器不能解释这个链接，而是把它存储在某个其他的目的地。 在上面，在href旁边缺less下载 ，或者Content-disposition必须从头文件中删除。 这取决于我们是否希望浏览器呈现文档。
希望这可以帮助。
我今天在Chrome版本30.0.1599.66和我的node.js / express.js应用程序中遇到了同样的问题。
标题是正确的，快速设置他们正确的自动，它在其他浏览器中的工作如下所示，把HTML 5的'下载'属性不解决，是什么解决了它进入铬高级设置，并检查框“询问在哪里保存每个文件在下载之前“。
之后，没有“资源解释为文档….”的错误报告在这个问题的标题，所以看起来我们的服务器代码是正确的，它是不正确地报告控制台中的错误，当它被设置为保存文件自动到一个位置。
当我在iframe中分配src =“image_url”时遇到了这个问题。 似乎iframe将其解释为文档，但事实并非如此。 这就是为什么它显示一个警告。
我在一个ASP网站项目中遇到了这个问题。 添加“Content-Length”标题会导致下载在Chrome中重新开始工作。
这个问题在Chrome 61版本中重新出现。 但它似乎固定在Chrome 62。
我有一个像下面的RewriteRule
RewriteRule ^/ShowGuide/?$ https://<website>/help.pdf [L,NC,R,QSA]
使用Chrome 61，PDF不能打开，在控制台显示消息
"Resource interpreted as Document but transferred with MIME type application/pdf: "
我们尝试在下面的重写规则中添加mimetypes，但没有帮助。
RewriteRule ^/ShowGuide/?$ https://<website>/help.pdf [L,NC,R,QSA, t:application/pdf]
我已经将我的Chrome更新到最新的62版本，并开始再次显示PDF。 但消息仍然在控制台中。
与所有其他浏览器，它是/工作正常。
在我的情况下，文件名太长，并得到相同的错误。 一旦缩短到200字以下，工作正常。 （限制可能是250？）
我得到这个错误，因为我从我的文件系统服务。 一旦我开始使用http服务器chrome可以搞清楚。
我遇到了与我创build的下载pipe理器相同的麻烦。 我遇到的问题是文件名太长，扩展名被剪掉。
示例：文件名称：组织协议和其他重要.pd
<?php header("Content-Disposition: attachment; filename=$File_Name"); ?>
解决scheme：将MySQL数据库字段增加到255以存储文件名，并在保存blob之前执行长度检查。 如果长度大于255，则将其调整为250，然后添加文件扩展名。
