Chrome和Firefox不会在iframe中显示大多数PDF文档 [英] Chrome and Firefox are not displaying most PDF documents in an iframe
问题描述
window.frames ['docview']。location = url;
来做到这一点。在大多数情况下,iframe视图保持空白如果之前显示的内容清除)。如果我采用相同的URL并在新的标签页或窗口中打开它,它会呈现罚款。在我的iframe中呈现失败时,我看到以下消息Chrome控制台:
资源解释为Document,但是以MIME类型application / pdf传输。
Firefox在其错误控制台或FireBug控制台中不提供任何类型的消息。 / p>
我无法控制PDF文件的来源,所以我无法更改它们的标题信息。
奇怪,有些文件的加载是正确的。
查看Chrome中的网络请求,对于无法加载的文档,我会看到(例如):
$ b
请求URL:http://es.csiro.au/pubs/paradis_mdm03.pdf
请求方法:GET
状态码:200 OK
请求头文件
Accept:text / html,application / xhtml + xml,application / xml; q = 0.9,* / *; q = 0.8
Accept-字符集:ISO-8859-1,utf-8; q = 0.7,*; q = 0.3
接受编码:gzip,deflate,sdch
接受语言:en-US,en; q = 0.8
连接:keep-alive
主机:es.csiro.au
参考:http://query.fxpal.net:8080 / querium / ui / query?searcherId = 2& compact =真安培; SIDX =秩&安培; topicId = 2及queryId = 1&安培; lastEventId = 1490893682130103&安培;高亮= undefined
用户代理:Mozilla / 5.0(Windows NT 6.1; WOW64)AppleWebKit / 535.1(KHTML,像Gecko)Chrome / 13.0.782.220 Safari / 535.1
响应标题
接受范围:字节
连接:保持活动
Content-Length:71764
Content-Type:application / pdf
日期:2011年9月6日星期二04:59:26 GMT
ETag:1f48c8-11854-43e4ee482ef40
Keep-Alive:timeout = 15,max = 100
上次修改时间:Wed,07 Nov 2007 04:07:49 GMT
服务器:Apache / 2.0.55(Ubuntu)PHP / 5.1.2 mod_ssl / 2.0.55 OpenSSL / 0.9.8a
从单独的选项卡打开渲染),我得到以下内容:
请求URL:http://es.csiro.au/pubs/paradis_mdm03.pdf
请求方法:GET
状态码:304未修改
请求标题
接受:text / html,application / xhtml + xml,application / xml; q = 0.9,* / *; q = 0.8
Accept-Charset:ISO-8859-1,utf-8; q = 0.7,*; q = 0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en; q = 0.8
Cache-Control:max-age = 0
连接:keep-aliv e
主机:es.csiro.au
If-Modified-Since:星期三,07十一月2007 04:07:49 GMT
If-None-Match:1f48c8-11854-43e4ee482ef40
范围:bytes = 0-71763
User-Agent:Mozilla / 5.0(Windows NT 6.1; WOW64)AppleWebKit / 535.1(KHTML,如Gecko)Chrome / 13.0.782.220 Safari / 535.1
响应头文件
连接:保持活动
日期:2011年9月6日:07:15 GMT
ETag:1f48c8-11854-43e4ee482ef40
Keep-Alive:timeout = 15,max = 100
服务器:Apache / 2.0.55(Ubuntu)PHP / 5.1 .2 mod_ssl / 2.0.55 OpenSSL / 0.9.8a
有一点很奇怪,但也许服务器是聪明的或有一些有趣的与缓存交互。谁知道。
任何帮助将不胜感激。
基因
编辑:2011年9月6日
当我删除标记时,
< meta http-equiv =content-typecontent =text / html; charset = UTF-8>来自< head>
元素的
我的HTML页面,许多(但不是全部)的PDF开始正确渲染。这是标题中另一个元标记的明显副本:
< meta http-equiv =Content-Typecontent =text / html; charset = UTF-8/>
这是否有助于揭示潜在问题?不要将iframe的 src
属性设置为PDF,而是将其设置为包装HTML文件,其中包含一个简单的div:
<!DOCTYPE html>
< html style =height:100%;>
< head>
< / head>
< body style =height:100%;>
< div id =divContentsstyle =height:100%;>< / div>
< / body>
< / html>
在javascript中, div
的内容是设置为对象
元素。不幸的是,在IE浏览器,Firefox和Chrome浏览器上都需要稍微不同的版本才能可靠地工作:
$ b
var embed ='< object type =application / pdfwidth =100 %height =100%';
if(msie){
embed + ='>< param name =srcvalue ='+ pdf +'/>';
}
else if(chrome){
embed + ='src ='+ pdf +'>';
}
else {
embed + ='data ='+ pdf +'>';
}
嵌入+ ='< / object>';
$(#divContents)。html(embed);
UPDATED
<我终于找到了Chrome中失败的真正原因:它是 Accept-Ranges:bytes
字段,没有它,当<$ c $使用c> data 属性。
- 所以如果你的服务器能够支持
Accept-Ranges
字段,你应该确保它返回给客户端。在这种情况下,您可以使用 pdfobject 库在框架或div中显示PDF。 - 如果不是,您可以使用上面的代码在框架或div中显示PDF。
I am running Windows 7, 64 bit. I have recently updated my OS to install the latest updates. Since then, most PDF documents have stopped rendering in my program. My program wants to display PDF documents in a separate iFrame. I do this by getting the URL of the PDF document and setting
window.frames['docview'].location = url;
In most cases, the iframe view remains blank (or clears if something was shown there previously). If I take that same URL and open it in a new tab or window, it renders fine.When it fails to render in my iframe, I see the following message in the Chrome console:
Resource interpreted as Document but transferred with MIME type application/pdf.
Firefox does not offer a message of any kind in its error console, or on the FireBug console.
I have no control over the source of the PDF files, so I cannot change their header information.
Oddly, some files do load correctly.
Looking at the network requests in Chrome, for a document that fails to load I see (for example):
Request URL:http://es.csiro.au/pubs/paradis_mdm03.pdf Request Method:GET Status Code:200 OK Request Headers Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3 Accept-Encoding:gzip,deflate,sdch Accept-Language:en-US,en;q=0.8 Connection:keep-alive Host:es.csiro.au Referer:http://querium.fxpal.net:8080/querium/ui/query?searcherId=2&compact=true&sidx=rank&topicId=2&queryId=1&lastEventId=1490893682130103&highlight=undefined User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1 Response Headers Accept-Ranges:bytes Connection:Keep-Alive Content-Length:71764 Content-Type:application/pdf Date:Tue, 06 Sep 2011 04:59:26 GMT ETag:"1f48c8-11854-43e4ee482ef40" Keep-Alive:timeout=15, max=100 Last-Modified:Wed, 07 Nov 2007 04:07:49 GMT Server:Apache/2.0.55 (Ubuntu) PHP/5.1.2 mod_ssl/2.0.55 OpenSSL/0.9.8a
When opened from a separate tab (where the document does render), I get the following:
Request URL:http://es.csiro.au/pubs/paradis_mdm03.pdf Request Method:GET Status Code:304 Not Modified Request Headers Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3 Accept-Encoding:gzip,deflate,sdch Accept-Language:en-US,en;q=0.8 Cache-Control:max-age=0 Connection:keep-alive Host:es.csiro.au If-Modified-Since:Wed, 07 Nov 2007 04:07:49 GMT If-None-Match:"1f48c8-11854-43e4ee482ef40" Range:bytes=0-71763 User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1 Response Headers Connection:Keep-Alive Date:Tue, 06 Sep 2011 05:07:15 GMT ETag:"1f48c8-11854-43e4ee482ef40" Keep-Alive:timeout=15, max=100 Server:Apache/2.0.55 (Ubuntu) PHP/5.1.2 mod_ssl/2.0.55 OpenSSL/0.9.8a
One odd things is the difference in status, but maybe the server is being smart or there is some funny interaction with the cache. Who knows.
Any help would be greatly appreciated.
Gene
EDITED: 9/6/2011
When I removed the tag
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
from the
<head>
element of my HTML page, many (but not all) of the PDFs started rendering properly. This was an apparent duplicate of another meta tag in the header:<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
Does this help shed any light on the potential problem?
解决方案Instead of setting the
src
attribute of the iframe to the PDF, set it to a wrapper HTML-file, which contains a simple div:<!DOCTYPE html> <html style="height:100%;"> <head> </head> <body style="height:100%;"> <div id="divContents" style="height:100%;"></div> </body> </html>
In javascript the contents of the
div
is set to anobject
element. Unfortunately slightly different versions are needed to work reliable on all browsers (tested on IE, Firefox and Chrome):(I simplified the retrieval of the divContents element and the browser detection)
var embed = '<object type="application/pdf" width="100%" height="100%"'; if (msie) { embed += '><param name="src" value="' + pdf + '"/>'; } else if (chrome) { embed += ' src="' + pdf + '">'; } else { embed += ' data="' + pdf + '">'; } embed += '</object>'; $("#divContents").html(embed);
UPDATED
I've finally found the actual cause of the failure in Chrome: It's the
Accept-Ranges:bytes
field, without it Chrome will not work when thedata
attribute is used.- So if your server is capable of supporting the
Accept-Ranges
field, you should make sure it is returned to the client. In that case you can use the pdfobject library to display the PDF in a frame or div. - If not, you can use the code above to display the PDF in a frame or div.
这篇关于Chrome和Firefox不会在iframe中显示大多数PDF文档的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!
- So if your server is capable of supporting the