При создании 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");
Я также попытался добавить следующие заголовки после поиска в Stack Overflow, но безрезультатно:
header("Content-Transfer-Encoding: binary"); header('Accept-Ranges: bytes');
Есть ли недостающие заголовки, которые требуется Chrome? У кого-нибудь есть опыт получения динамически созданных PDF-файлов для отображения в Chrome?
EDIT: Один из моих более важных вопросов – это то, что может привести к тому, что это нормально работает в Chrome, но не будет работать в среде сервера.
Спасибо заранее за любую помощь.
Попробуй это
<?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-скрипта в браузер.
Я хочу поблагодарить всех за их ответы.
Оказывается, это не было связано с заголовками. После попытки изменить / удалить заголовки различными способами (обнаружение кодировки, попытка с использованием длины контента и т. Д.) Мы решили перекопать в более глубокие журналы httpd, чтобы узнать, разрешено ли что-то по-другому для Chrome.
Оказывается, mod_sec на нашем сервере mod_sec запрос (только из Chrome по какой-то причине) в качестве попытки атаки на файл и возвращал запрещенный ответ 403. Chrome показал это как ERR_INVALID_RESPONSE а не 403.
Имя хоста CDN присутствовало в запросе (у нас была достаточная проверка на конечной точке, чтобы убедиться, что файл действительно разрешенный ресурс), а вместо этого строит URL-адрес на сервере.
В моем случае мне пришлось добавить эти 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();