可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试):
问题:
With Chrome 12.0.742.112, if I redirect with the following headers:
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
Which if followed returns the following header:
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 will not redirect, nor change the previous page, it'll just report the following warning in the console:
Resource interpreted as Document but transferred with MIME type application/zip.
The process works correctly in Firefox, and also works fine in Chrome if I open a new tab and go directly to http://0.0.0.0:3000/files/download.zip. Am I doing something wrong, or is this a bug/quirk of Chrome?
回答1:
回答2:
In your request header, you have sent Content-Type: text/html which means that you'd like to interpret the response as HTML. Now if even server send you PDF files, your browser tries to understand it as HTML. That's the problem. I'm searching to see what the reason could be. :)
回答3:
I experienced this problem when serving up a PDF file (MIME type application/pdf) and solved it by setting the Content-Disposition header, e.g.:
Content-Disposition: attachment; filename=foo.pdf
Hope that helps.
回答4:
I've fixed this…by simply opening a new tab.
Why it wasn't working I'm not entirely sure, but it could have something to do with how Chrome deals with multiple downloads on a page, perhaps it thought they were spam and just ignored them.
回答5:
I could not find anywhere just an explanation of the message by itself. Here is my interpretation.
As far as I understand, Chrome was expecting some material it could possibly display (a document), but it obtained something it could not display (or something it was told not to display).
This is both a question of how the document was declared at the HTML page level in href (see the download attribute in Roy's message) and how it is declared within the server's answer by the means of HTTP headers (in particular Content-Disposition). This is a question of contract, as opposed to hope and expectation.
To continue on Evan's way, I've experienced that:
Content-type: application/pdf Content-disposition: attachment; filename=some.pdf
is just inconsistent with:
Chrome will cry Resource interpreted as document but transferred…
Actually, the attachment disposition just means this: the browser shall not interpret the link, but rather store it somewhere for other―hidden―purposes. Here above, either download is missing beside href, or Content-disposition must be removed from the headers. It depends on whether we want the browser to render the document or not.
Hope this helps.
回答6:
I encountered this same issue today with Chrome Version 30.0.1599.66 with my node.js / express.js application.
The headers are correct, express sets them properly automatically, it works in other browsers as indicated, putting html 5 'download' attribute does not resolve, what did resolve it is going into the chrome advanced settings and checking the box "Ask where to save each file before downloading".
After that there was no "Resource interpreted as document...." error reported as in the title of this issue so it appears that our server code is correct, it's Chrome that is incorrectly reporting that error in the console when it's set to save files to a location automatically.
回答7:
I encountered this when I assigned src="image_url" in an iframe. It seems that iframe interprets it as a document but it is not. That's why it displays a warning.
回答8:
I had this issue in an ASP web site project. Adding a "Content-Length" header caused downloads to start working again in Chrome.
回答9:
This issue was re-appeared at Chrome 61 version. But it seems it is fixed at Chrome 62.
I have a RewriteRule like below
RewriteRule ^/ShowGuide/?$ https:///help.pdf [L,NC,R,QSA]
With Chrome 61, the PDF was not opening, in console it was showing the message
"Resource interpreted as Document but transferred with MIME type application/pdf: "
We tried to add mime type in the rewrite rule as below but it didn't help.
RewriteRule ^/ShowGuide/?$ https:///help.pdf [L,NC,R,QSA, t:application/pdf]
I have updated my Chrome to latest 62 version and it started to showing the PDF again. But the message is still there in the console.
With all other browsers, it was/is working fine.
回答10:
In my case the file name was too long, and got the same error. Once shortened below 200 chars worked fine. (limit might be 250?)
回答11:
I got this error because I was serving from my file system. Once I started with a http server chrome could figure it out.
回答12:
I was experiencing the same trouble with a download manager I created. The problem I was having involved the file name being too long and the extension being clipped off.
Example: File Name : Organizational Protocols and Other Things That are Important.pd
Solution: Increased the MySQL database field to 255 to store the file name, and performed a length check before saving the blob. If the length > 255 trim it down to 250 and add the file extension.
