Результаты генерации PDF в ERR_INVALID_RESPONSE в Chrome

При создании PDF в браузере программным способом (через PHP) отображаемый PDF отлично отображается как в Firefox, так и в Safari, но Chrome возвращает ERR_INVALID_RESPONSE. Это действительный PDF - его можно открыть локально с помощью Adobe Reader/Preview после сохранения из рабочих браузеров, и даже открыть в Chrome после сохранения PDF из другого браузера.

Файл PDF читается через file_get_contents(), получает текущую метку времени и затем передается в браузер. Обходной путь может включать сохранение файла во временную область и перенаправление пользователя (по крайней мере, для Chrome), но это не идеально.

Я исследовал это и смог найти только сообщения об ошибках, начиная с 2008 года.

У меня есть подозрение, что это ошибка заголовка. После того, как PDF сгенерирован, в браузер отправляются следующие заголовки (снова хорошо работает в FF, Safari и IE):

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

Я также попытался добавить следующие заголовки после поиска в переполнении стека, но безрезультатно:

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

Есть ли недостающие заголовки, которые требуются в Chrome? У кого-нибудь есть опыт работы с динамически генерируемыми PDF файлами для отображения в Chrome?

РЕДАКТИРОВАТЬ: Один из моих наиболее важных вопросов заключается в том, что может быть причиной того, что это работает нормально локально в Chrome, но не будет работать в серверной среде.

Ответ 1

Я хочу поблагодарить всех за их ответы.

Оказывается, это не было связано с заголовками. После попытки изменения/удаления заголовков различными способами (обнаружение кодировки, попытка с использованием длины контента и т.д.) Мы решили вникнуть в более глубокие журналы httpd, чтобы узнать, не разрешено ли что-либо по-другому для Chrome.

Оказывается, что mod_sec на нашем сервере помещал запрос (только из Chrome по какой-либо причине) в качестве попытки атаки на файл, и возвращал 403 запрещенный ответ. Chrome показал это как ERR_INVALID_RESPONSE, а не 403.

В запросе присутствовало имя хоста CDN (у нас была достаточная проверка на конечной точке, чтобы убедиться, что файл действительно разрешенный ресурс), а вместо этого строит URL-адрес на сервере.

Ответ 2

В моем случае я должен был добавить эти 2 параметра в заголовки, потому что wordpress отправил 404-код, поскольку он не распознал URL-адрес моей php-функции:

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

как указано в этом ответе на wordpress.stackexchange.

Это заставляет заголовки заменять (2-й параметр true) код состояния 404, сгенерированный wordpress, поскольку он не распознает настраиваемый URL-адрес и устанавливает 200 OK (третий параметр 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();

Ответ 3

Попробуйте это

<?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 scriptотправлено в браузер.

Ответ 4

Я хочу поблагодарить всех за ответы.

Оказывается, это не было связано с заголовками. После попыток изменить/удалить заголовки различными способами (обнаружение кодирования, попытка с длиной содержимого и без нее и т.д.) Мы решили покопаться в более глубоких журналах httpd, чтобы увидеть, что-то по-другому решается для Chrome.

Оказывается, что mod_sec на нашем сервере помечал запрос (по какой-то причине только из Chrome) как попытку атаки с использованием инъекции файла и возвращал запрещенный ответ 403. Chrome отображал это как ERR_INVALID_RESPONSE, а не 403.

Имя хоста CDN присутствовало в запросе (у нас было достаточно проверки в конечной точке, чтобы убедиться, что файл действительно был разрешенным ресурсом), и вместо этого мы вместо этого строили URL на сервере.

Ответ 5

Gostaria de fazer parte do suporte uber ест, procuro fazer o melhor возможный, para poder realisar várias entregas com uber, com qualidade.

Ответ 6

Получаю этот ответ, когда я пытаюсь ответить или переслать письма от Blackberry Hub

Любые идеи, пожалуйста!

Веб-страница недоступна Веб-страница с данными: text/html; charset = utf-8; charset = utf-8; base64, не может быть загружен, потому что:

нетто :: ERR_INVALID_RESPONSE