PDF生成结果在Chrome中的ERR_INVALID_RESPONSE中

时间:2016-01-04 20:27:56

标签: php google-chrome pdf

当以编程方式(通过PHP)在浏览器中生成PDF时,渲染的PDF在Firefox和Safari中都可以正常显示,但Chrome会返回ERR_INVALID_RESPONSE。它是一个有效的PDF - 可以在工作浏览器中保存后使用Adobe Reader / Preview在本地打开,一旦从其他浏览器保存PDF,甚至可以在Chrome中打开。

正在通过file_get_contents()读取PDF文件,获得当前时间戳,然后传递给浏览器。解决方法是将文件保存到临时位置并重定向用户(至少对于Chrome),但这并不理想。

我研究了它,但却找不到bug reports dating from 2008

我有一个标题错误。生成PDF后,以下标题将发送到浏览器(再次在FF,Safari和IE中正常工作):

    header('Content-type:application/pdf');
    header("HTTP/1.1 200 OK");

我也尝试在Stack Overflow上搜索后添加以下标题,但无济于事:

    header("Content-Transfer-Encoding: binary");
    header('Accept-Ranges: bytes');

Chrome是否缺少标题?有没有人有动态生成的PDF在Chrome中显示的经验?

编辑:我的一个更突出的问题是什么可能导致它在Chrome中本地正常工作,但不适用于服务器环境。

提前感谢您的帮助。

4 个答案:

答案 0 :(得分:8)

在我的情况下,我必须将这两个参数添加到标题,因为wordpress正在发送404代码,因为它无法识别我的php函数的url:

header("Content-type: application/pdf",true,200);

如此answer on wordpress.stackexchange中所述。

这会强制标题替换(第2个参数true)由wordpress生成的404状态代码,因为它无法识别自定义网址,并设置200 OK(第3个参数200)。

所以它结束了这样的事情:

$pdf_name = "test.pdf";
$pdf_file = "/absolute/path/to/my/pdfs/on/my/server/{$pdf_name}";
header('Content-type: application/pdf',true,200);
header("Content-Disposition: attachment; filename={$pdf_name}");
header('Cache-Control: public');
readfile($pdf_file);
exit();

答案 1 :(得分:5)

试试这个

<?php
$filename = 'Physical Path to PDf file.pdf';
$content = file_get_contents($filename);

header("Content-type:application/pdf");

// It will be called downloaded.pdf
header("Content-Disposition:inline;filename='".basename($filename)."'");   
header('Content-Length: '.strlen( $content ));

// The PDF source is in original.pdf
readfile($filename);
?>

<html>
<body>
...
...
...
  

确保在输出PHP脚本之前调用上面的标题代码   发送到浏览器。

答案 2 :(得分:5)

我要感谢大家的回答。

事实证明这与标题无关。尝试以各种方式更改/删除标题(检测编码,尝试使用和不使用内容长度等)后,我们决定深入研究更深入的httpd日志,看看Chrome是否有任何不同的解析方式。

事实证明,我们服务器上的mod_sec标记了请求(仅出于某种原因来自Chrome)作为尝试进行文件注入攻击并返回403禁止响应。 Chrome将其显示为ERR_INVALID_RESPONSE而不是403。

请求中存在CDN的主机名(我们在端点上进行了充分的检查以确保该文件确实是一个允许的资源),而是在服务器上构建URL。

答案 3 :(得分:0)

我要感谢大家的回答。

事实证明,这与标题无关。在尝试以各种方式更改/删除标头(检测编码,尝试使用和不使用内容长度等)之后,我们决定深入研究httpd日志,以了解Chrome的解析方式是否有所不同。

事实证明,我们服务器上的mod_sec正在将请求(出于某种原因仅来自Chrome)标记为试图进行文件注入攻击,并返回了403禁止响应。 Chrome将其显示为ERR_INVALID_RESPONSE,而不是403。

请求中包含CDN的主机名(我们在端点进行了大量检查以确保文件确实是允许的资源),而是在服务器上构建URL。