Nie można wyświetlić pliku PDF z HTTPS w IE 8 (w 64-bitowym systemie Vista)

Question

Posiadam własny serwer HTTPS, który obsługuje proste pliki (jest osadzony w mojej aplikacji). Działa wspaniale - używa go na zawsze.

Niedawno dodana obsługa SSL - Chrome, FireFox i IE - wszystko to polubiłem i ładowałem strony.

Problem, który napotykam, to próba załadowania pliku PDF przez połączenie HTTPS. Z jakiegoś powodu plik PDF nigdy nie wyświetla się w IE 8 (64-bitowy w 64-bitowym systemie Vista). Działa dobrze w Chrome. Działa to dobrze w IE 8 przy użyciu zwykłego protokołu HTTP - tylko przy użyciu HTTPS nie działa.

UWAGA: Kiedy wspomniano o IE 8, jest to 32-bitowy IE 8 na 64-bitowym Vista, chociaż 64-bitowy IE 8 ma to samo zachowanie.

To sprawia, że ​​myślę, że jest to jakiś problem z IE 8/HTTPS/PDF/64-bitowym systemem operacyjnym, ale nie jestem pewien.

DebugBar dla IE 8 pokazuje, że żądanie i odpowiedź poszły dokładnie zgodnie z oczekiwaniami - bez błędów. IE 8 nie pokazuje żadnych błędów ani niczego - czystego białego ekranu (lub strony wyświetlanej przed próbą załadowania pliku PDF). Oczyszczone pamięci podręczne/pliki cookie/itp.

Czy są jakieś znane problemy z IE/PDF/HTTPS?

Answer 1

Myślałem, że wrócę i dam ostateczną odpowiedź.

Dziękuję wszystkim, którzy zasugerowali "Nie zapisuj zaszyfrowanych stron na dysku".

Śledziłem porady EricLaw i ustawić:

Cache-Control: private 

Ja również okazało się, że miałem Pragma: no-cache, które usunąłem.

działa jak czar teraz :)

Answer 2

Czy używasz 32-bitowej lub 64-bitowej wersji IE w Vista 64? Pochodzi z obu. Najczęściej używana jest wersja 32-bitowa, ponieważ niewiele wtyczek obsługuje jeszcze 64-bitową wersję.

Chciałbym sprawdzić, czy istnieje różnica między tymi dwoma. Jeśli działa w IE 8 32 bit w systemie Vista 64, może to być problem z 64-bitową wersją Brower Helper Object (BHO).

Sprawdź także (za pomocą Menedżera zadań obecność "* 32" po nazwie procesu), jeśli inne przeglądarki działają w trybie 32-bitowym.

Inną rzeczą, którą sprawdziłbym, czy jest HTTPS, powoduje, że IE8 nie buforuje pliku PDF z jakiegoś powodu (ruch HTTPS zwykle nie jest buforowany). Uruchomiłbym procmon, aby sprawdzić, czy zauważysz zapisywanie pliku PDF w systemie plików. Może istnieć ustawienie zasad, które możesz potrzebować zmienić. Nie jestem pewien, czy istnieje alternatywny sposób powiedzenia, że ​​masz plik PDF, który nie powinien być zapisywany na dysku, ale nadal może być wyświetlany.

Answer 3

Nie widzę żadnego odniesienia do .NET w twoim pytaniu, ale zamierzam dostarczyć powiązane rozwiązanie. Mam nadzieję, że możesz pobrać z niego to, czego potrzebujesz, a programiści przyjmujący twoje pytanie dotyczy .NET może również znaleźć w tym wartość.

Oto metoda, którą wcześniej stosowałem do renderowania plików PDF w przeglądarce, przez HTTPS, bez ** buforowania.

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(); 
    } 

** Jest pseudo-cache który występuje tylko na tyle długo, Adobe Reader do załadowania pliku PDF. Szukałem odniesienia opisujący, co mówię, a random forum thread to najlepsze co mogłem zrobić:

IE przechowuje PDF w przydzielonej pamięci „lotnego” i umieszcza wskaźnik w% System% Temp . To jest jedyne miejsce przechowywania pliku. Wskaźnik został usunięty i przydzielono mu pamięć , gdy tylko Adobe zostanie zamknięty.

Nie mogę ręczyć za dokładność techniczną tego, ale odzwierciedla to, co zaobserwowałem, korzystając z powyższej metody. W rzeczywistości, myślę, że plik zniknie z chwilą, gdy skończy się ładowanie w programie Adobe Reader (w przeglądarce).

Answer 4

wpadłem na ten sam problem, a może tylko dostać go do pracy, zadając użytkownikowi modyfikować swoje ustawienia zabezpieczeń, aby wyłączyć Nie zapisuj zaszyfrowanych stron na dysku w zakładce Zaawansowane w oknie dialogowym Opcje internetowe: http://support.microsoft.com/kb/812935

... następnie z natychmiastową paniką, zacząłem patrzeć na kod (ASP.NET przy użyciu VB). Użyłem skrzypka i odkryłem, że nawet gdy nie określałem nagłówka kontrolki pamięci podręcznej, wydawało mi się, że Framework automatycznie określił dla mnie opcję "nie-sklepu". Kluczem do rozwiązania problemu był numer this PHP question. Po ustawieniu nagłówka kontrolki pamięci podręcznej na max-age = 1 plik będzie buforowany przez 1 sekundę, wystarczająco długo, aby program Adobe Reader mógł go pobrać z dysku i załadować do pamięci. I uaktualniony nasz kod do generowania PDF następująco:

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: myślałem, że to działa, ale myślę, że mówił zbyt szybko. Stworzyłem new question, aby rozwiązać ten problem.

Answer 5

Jako użytkownik miałem ten sam problem, ładując pliki pdf z Schwab.com. Porada "Wyłącz zapisywanie zaszyfrowanych stron na dysku w zakładce Zaawansowane okna dialogowego Opcje internetowe: http://support.microsoft.com/kb/812935" dla mnie.

Answer 6

miałem podobny problem z IE8 i HTTPS. Kiedy próbowałem przesłać plik PDF do nowego okna, zamiast tego otrzymałem pustą stronę HTML (działało w FireFox i jeśli nie było przez https). Po wielu poszukiwania i próbuje różnych odmian nagłówków odpowiedzi, rozwiązanie było dla mnie, aby ustawić:

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

ten pobiera cały pdf zanim otworzy który jest mniej przyjazne dla użytkownika, jeśli jest to bardzo duży pdf. Ale w moim przypadku większość plików pdf to tylko kilka stron. Mam nadzieję, że to pomaga komuś.

Answer 7

response.setHeader("Cache-Control","private"); 

załatwił nam sprawę w IE8 i IE9.

To nie wymagało zmiany ustawień w przeglądarce.

Answer 8

Moje rozwiązanie (zajęło nam dni od zabawy z nagłówkami aby uzyskać to do pracy):

  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); 
      } 

nadzieję, że pomoże komuś