Вопрос по 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?

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

Ваш Ответ

8   ответов
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);
            }

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

39

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

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

Cache-Control: private 

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

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

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

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

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

4

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

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

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

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

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

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