Вопрос по pdf, internet-explorer-8, 64bit, internet-explorer, https – Не удается отобразить PDF из HTTPS в IE 8 (в 64-битной Vista)

43

У меня есть собственный HTTPS-сервер, который обслуживает простые файлы (он встроен в мое приложение). Он прекрасно работает - использовал его вечно.

Недавно добавлена поддержка SSL - Chrome, FireFox и IE нравятся и загружают страницы просто отлично.

Проблема, которую я нахожу, заключается в том, что я пытаюсь загрузить файл PDF через соединение HTTPS. По некоторым причинам, PDF никогда не отображается в IE 8 (64-разрядная на 64-разрядной Vista). Он отлично работает в Chrome. И он отлично работает в IE 8 при использовании простого HTTP - только сбой при использовании HTTPS.

ПРИМЕЧАНИЕ. Когда упоминается IE 8, он представляет собой 32-битный IE 8 в 64-битной Vista, хотя 64-битный IE 8 имеет такое же поведение.

Это заставляет меня думать, что это какая-то проблема IE 8 / HTTPS / PDF / 64-битной ОС, но я не уверен.

DebugBar для IE 8 показывает, что запрос и ответ прошли точно так, как ожидалось - ошибок нет вообще. IE 8 не показывает никаких ошибок или чего-либо еще - чисто белый экран (или страницу, которая отображалась до того, как я пытался загрузить PDF). Очищен кеш / куки / и т.д.

Есть ли известные проблемы с IE / PDF / HTTPS?

Возможно, эта ошибка IE (5,5,5,6,7 и 8) описана здесь:support.microsoft.com/kb/323308 x0n
Acrobat / Reader доступен только в виде 32-разрядного приложения. Я считаю, что Adobe также создает 32-битные плагины для браузеров, поэтому нет возможности просматривать PDF-файлы в 64-битном браузере ... по крайней мере, с помощью Acrobat / Reader. Mark Storer

Ваш Ответ

8   ответов
10
response.setHeader("Cache-Control","private");

Это не требует изменения настроек в браузере.

0

чтобы поиграть с заголовками, чтобы это сработало):

            if (System.Web.HttpContext.Current.Request.Browser.Browser == "InternetExplorer"
                && System.Web.HttpContext.Current.Request.Browser.Version == "8.0")
            {
                System.Web.HttpContext.Current.Response.Clear();
                System.Web.HttpContext.Current.Response.ClearContent();
                System.Web.HttpContext.Current.Response.ClearHeaders();
                System.Web.HttpContext.Current.Response.ContentType = "application/octet-stream";

                System.Web.HttpContext.Current.Response.AppendHeader("Pragma", "public");
                System.Web.HttpContext.Current.Response.AppendHeader("Cache-Control", "private, max-age=60");
                System.Web.HttpContext.Current.Response.AppendHeader("Content-Transfer-Encoding", "binary");

                System.Web.HttpContext.Current.Response.AddHeader("content-disposition", "attachment; filename=" + document.Filename);
                System.Web.HttpContext.Current.Response.AddHeader("content-length", document.Data.LongLength.ToString());

                System.Web.HttpContext.Current.Response.BinaryWrite(document.Data);
            }

Надеюсь, что это помогает кому-то

4

поток PDF в новое окно, вместо этого я получил пустую html-страницу (она работала в FireFox и, если это не было через https). После долгих поисков и проб разных вариантов заголовков ответов, решение для меня было установить:

Response.AppendHeader("Accept-Ranges", "none");

Это загружает весь PDF-файл перед его открытием, что менее удобно для пользователя, если это очень большой PDF-файл. Но в моем случае большинство PDF-файлов было всего несколько страниц. Надеюсь, это поможет кому-то.

Просто хочу сказать, что у меня возникла такая же проблема после введения SSL в приложениях, работающих на сервере Tomcat (J2EE), то есть документы PDF не отображаются в IE7. Ни одно из решений по управлению кэшем не сработало, но это сработало, то есть «httpResponse.addHeader (« Accept-Ranges »,« none »);». +1 от меня.
3

но я собираюсь предоставить соответствующее решение. Надеемся, что вы сможете извлечь из него то, что вам нужно, и разработчики, если вы считаете, что ваш вопрос относится к .NET, тоже могут найти в этом смысл.

Вот способ, который я использовал ранее для рендеринга PDF-файлов в браузере через HTTPS без ** кэширования.

    private void RenderPdfToResponse(byte[] documentBytes) {
        Response.BufferOutput = true;
        Response.ClearContent();
        Response.ClearHeaders();
        Response.AddHeader("Cache-control", "no-store");
        Response.ContentType = "application/pdf";
        Response.AddHeader("Content-Length", documentBytes.Length.ToString());
        Response.BinaryWrite(documentBytes);
        Response.Flush();
        HttpContext.Current.ApplicationInstance.CompleteRequest();
    }

** Eстьpseudo-cache это происходит, достаточно долго, чтобы Adobe Reader мог загрузить файл PDF. Я искал ссылку, описывающую то, о чем я говорю, ислучайная ветка форума лучшее, что я мог сделать:

IE stores the PDF in allocated 'volatile' memory and places a pointer in %system% Temp. This is the only place the file is stored. The pointer is deleted and allocated memory is freed as soon as Adobe Reader is closed.

Я не могу ручаться за техническую точность этого, но она отражает то, что я наблюдал, используя описанный выше метод. Фактически, я думаю, что этот файл исчезает в тот момент, когда он завершает загрузку в Adobe Reader (в браузере).

0

у меня была такая же проблема при загрузке PDF-файлов с Schwab.com. Совет & quot; отключить Не сохранять зашифрованные страницы на диск во вкладке «Дополнительно» диалогового окна «Свойства обозревателя»:http://support.microsoft.com/kb/812935& Quot; работал на меня.

0

с обоими. В большинстве случаев используется 32-битная версия, так как не многие плагины пока поддерживают 64-битные.

Я проверю, есть ли разница между ними. Если он работает в IE 8 32-разрядной на Vista 64, то это может быть проблема с 64-разрядной версией Browser Helper Object (BHO).

Кроме того, проверьте, чтобы (через наличие в диспетчере задач "32" после имени процесса), работали ли другие браузеры в 32-битном режиме.

Еще одна вещь, которую я проверю, чтобы проверить, является ли HTTPS причиной того, что IE8 по какой-то причине не кэширует PDF-файл (трафик HTTPS обычно не кэшируется). Я бегуProcMon чтобы увидеть, замечаете ли вы файл PDF, записываемый в файловую систему. Там могут быть настройки политики, которые вам может потребоваться изменить. Я не уверен, есть ли альтернативный способ сказать, что у вас есть PDF, который не должен быть записан на диск, но все же может быть отображен.

Какие заголовки контроля кэша вы отправляете? Попробуйте отправить Cache-Control: private, а не какую-либо директиву, запрещающую кэширование.
Может быть потенциальная проблема с сохранением файла. Я обновил свой ответ.
Хорошо, позвони Джеффу. Это на самом деле 32-битный IE в 64-битной Vista (некоторые страницы содержат флэш-память, и пока нет 64-битного флэш-проигрывателя). Буду редактировать вопрос ... DougN
Что такое MIME-тип / & quot; Тип-контента & quot; вы отправляете для PDF?
Хммм. В IE я не отмечал & quot; Не сохранять зашифрованные страницы на диск & quot ;. Похоже, что файлы .jpg, .gif, .js и .css сохраняются, но не .PDF или .html. Очень странно ... (хотя в ЭТОМ случае это правильно, кажется, трудно поверить, что IE мог догадаться, что изображение не будет содержать личную информацию) DougN
10

только попросив пользователя изменить свои настройки безопасности, чтобы отключитьDo not save encrypted pages to disk на вкладке «Дополнительно» диалогового окна «Свойства обозревателя»: http://support.microsoft.com/kb/812935

...then с немедленной паникой я начал смотреть на код (ASP.NET, использующий VB). Я использовал fiddler и обнаружил, что даже когда я не определял заголовок элемента управления кэшем, мне казалось, что Framework автоматически указывает no-store для меня. Ключ к решению проблемы был на самом деле вэтот вопрос PHP, Установив заголовок элемента управления кэшированиемmax-age=1 файл будет кэшироваться в течение 1 секунды, достаточно долго, чтобы Adobe Reader мог взять его с диска и загрузить в память. Я обновил наш код, чтобы сгенерировать PDF следующим образом:

Response.ClearContent()
Response.ClearHeaders()
Response.AddHeader("cache-control", "max-age=1")
Response.ContentType = "application/pdf"
Response.AddHeader("content-disposition", "attachment; filename=whatever.pdf")
Response.AddHeader("content-length", mem_stream.Length.ToString)
Response.BinaryWrite(mem_stream.ToArray())
Response.Flush()
Response.End()                                

Update: Я думал, что это работает, но я думаю, что говорил слишком рано. Я создалновый вопрос чтобы решить эту проблему.

Спасибо Eamon, я продолжал пытаться и в конечном итоге найти программное решение!
Это отлично сработало для меня .... Большое спасибо, я пробовал множество разных способов, которые люди предлагали в Интернете, и ни один из них не работал до сих пор, так что спасибо :)
Я сталкивался с этой проблемой раньше; это определенно связано с кэшированием; IE выиграл "t" кеш " загрузка в системный временный файл и, таким образом, Adobe не может открыть его оттуда.
Не знаю, было ли это уже решено или нет, но, учитывая информацию здесь, я загрузил PDF прямо в окно MSIE. После этого загрузили его должным образом, изменив параметры обозревателя MSIE / Параметры безопасности, Зона Интернета - параметры пользовательского уровня, & quot; Автоматическое уведомление о загрузке файлов & quot; включить.
39

Спасибо всем, кто предложил & quot; Не сохранять зашифрованные страницы на диск & quot ;.

Я последовал совету EricLaw и установил:

Cache-Control: private 

Я также обнаружил, что у меня былоPragma: no-cache, который я удалил.

Работает как шарм сейчас :)

Заголовок установлен Pragma "без кеша" был виновником здесь - удаление этого заставило IE8 снова отобразить PDF. Спасибо команде Internet Explorer за 2 потраченных впустую часа.
& quot; Контроль кэша: частный & quot; работал на меня, старый добрый ТАК!
У меня работает только при добавленииResponse.ClearHeaders(); первый (Windows 2003 / IIS 6.0).

Похожие вопросы