Wenn ich zu bestimmten Adressen von PDF-Dateien gehe, lädt Chrome die PDF-Datei herunter, anstatt sie mit dem integrierten PDF-Viewer zu öffnen. Die Seite ist dann leer weiß.

Es gibt kein Problem mit meinen Chrome-Einstellungen: Ich versuche Adressen anderer PDF-Dateien und Chrome verhält sich wie erwartet (ich habe es so eingestellt, dass der integrierte PDF-Viewer von Chrome verwendet wird). Aber jedes Mal, wenn ich die gleiche problematische Adresse versuche, lädt Chrome die PDF-Datei herunter und zeigt dann eine leere Seite an.

Ich benutze Windows 10 und Chrome Version 63.0.3239.84 (Official Build) (64-bit).

Meine spezifische problematische URL ist diesmal hier (ein Google-Suchergebnis).

Grundsätzlich geschieht dies, weil die Website den Browser auffordert, dies zu tun. Gelegentlich liegt es daran, dass der Website-Entwickler entscheidet, dass dieses Verhalten gewünscht wird, z. B. bei Websites zur Dateifreigabe. In anderen Fällen ist dies eine Standardoption für die von ihnen verwendete Software (z. B. Forum- oder Blogging-Software). Manchmal liegt es daran, dass der Site-Entwickler keine Ahnung hat, was er tut.

Content-Disposition

Dies liegt normalerweise daran, dass die Site Content-Dispositionin der Antwort einen Header sendet . Insbesondere kann es entweder inlineoder senden attachment.

inline Wenn nicht anders angegeben, ist dies die Standardeinstellung. Dies bedeutet, dass der Browser die Datei im Browserfenster öffnet, wenn dies möglich ist.

attachment bedeutet, dass Sie die Datei immer herunterladen und niemals versuchen, sie im Browser zu öffnen.

Wenn Sie die Entwicklertools Ihres Browsers öffnen, sehen Sie, dass über einen bestimmten Link die folgenden Antwortheader gesendet werden:

Content-Disposition: attachment; filename="Schubert-Sonata-21-B-flat.pdf"
Content-Type: application/pdf

Dadurch wird der Browser angewiesen,attachment die Datei immer herunterzuladen ( ) und ihr den Standarddateinamen zuzuweisen, Schubert-Sonata-21-B-flat.pdfanstatt sie aus der URL abzuleiten. Außerdem wird dem Browser (korrekt) mitgeteilt, dass es sich um eine application/pdfDatei handelt. Da es sich jedoch um eine Datei handelt, wird attachmentder Browser weiterhin standardmäßig heruntergeladen.

Details zur Inline-Bearbeitung

Wenn a Content-Dispositioninline (oder nicht angegeben) ist, versucht der Browser, die Datei im eingebetteten Standard-Viewer zu öffnen. Dies funktioniert nur, wenn der Browser den Dateityp und das Öffnen dieses Typs kennt.

Typerkennung

Der Dateityp kann vom Server mit einem Content-TypeHeader angegeben werden. Zum Beispiel sind die häufigsten Inline - Typen text/html, application/javascriptund text/cssdie drei Hauptteile einer modernen Website bilden. Sie können auch mehr esoterische Typen wie haben application/pdf.

Eine andere Möglichkeit ist, dass der Server eine Content-Typevon angegeben hat application/octet-stream. Dies ist der allgemeinste Typ, und er gibt dem Browser an, dass es sich bei der Datei nur um beliebige Daten handelt. Zu diesem Zeitpunkt kann der Browser sie nur herunterladen (theoretisch - wir werden darauf zurückkommen).

Wenn ein Content-Typenicht durch den Server angegeben (und manchmal sogar , wenn es ist), kann der Browser durchführen , was bekanntlich Sniffing zu versuchen , die Art zu erraten , indem Sie die Datei und suchen nach Mustern zu lesen.

Typbehandlung

Nach dem Empfang einer Datei mit einer inlineoder einer nicht angegebenen Disposition muss der Browser versuchen, diese nach Möglichkeit im Browser zu öffnen. Zu diesem Zweck wird der Dateityp überprüft. Wenn der Dateityp erkannt wird, wird versucht, ihn zu öffnen. Die meisten Browser öffnen einen beliebigen text/Typ in einem einfachen Text-Viewer, versuchen, ihn text/htmlals Webseite zu rendern , öffnen ihnapplication/json möglicherweise in einem speziellen, syntaktisch hervorgehobenen Viewer usw.

Der Typ application/octet-streamwurde speziell behandelt. Da es sich um den allgemeinsten Typ handeln soll, der einen willkürlichen Strom von Bytes bezeichnet, sollte es keinen Handler geben, der auf alle Dateien dieses "Typs" angewendet werden kann. In Firefox zeigt sich dies beispielsweise darin, dass der Standardhandler für nicht festgelegt werden kann application/octet-stream.

Einige Websites haben auch nicht standardmäßige Typen verwendet. Ich habe application/force-downloadgebraucht gesehen - was als Download endet, weil der Browser nicht erkennt oder weiß, was er sonst mit dem Typ machen soll, aber nicht die spezielle Handhabung genießt, die das application/octet-streammacht.

Um zu sehen, wie mit PDFs umgegangen wird, können wir uns ein wenig mit dem Webprotokoll befassen. In der Vergangenheit hatten Browser keine Ahnung, was ein PDF ist. Sie konnten es also nicht öffnen. Aber wir haben gesehen, dass PDFs in Browsern geöffnet wurden, lange bevor integrierte PDF-Viewer zum Einsatz kamen. Wie funktionierte das?

Früher war es möglich, die Browserfunktionalität mit weitaus mehr Kontrolle zu erweitern, als dies heutzutage mit eingeschränkten Erweiterungen / Addons möglich ist. Diese wurden allgemein als Plugins bezeichnet . In Internet Explorer handelte es sich um ActiveX-Steuerelemente. In Mozilla Firefox und später in Google Chrome handelte es sich um NPAPI-Plugins. Diese Plugins waren in der Lage, alles zu tun, was jedes andere Programm konnte, und konnten sich zusätzlich als Handler für einen bestimmten Dateityp registrieren, der vom Browser sonst möglicherweise nicht erkannt würde. (Im Übrigen stellte dies später ein großes Sicherheitsrisiko dar und die Unterstützung für diese leistungsstarken Plugins wurde nach und nach eingestellt ...)

In den Tagen der Plug-ins würden Sie Adobe Acrobat Reader installieren, der dann ein ActiveX- oder NPAPI-Plug-in installiert, das den application/pdfMIME-Typ registriert und den Browser anweist, diese Typen inline mit dem Plug-in zu öffnen.

Nach einer Reihe von Sicherheits- und Leistungsproblemen, die durch diese Plugins verursacht wurden, entschieden sich die großen Browser-Anbieter natürlich, ihre eigenen PDF-Viewer einzubinden und die Unterstützung für die meisten Plugins einzustellen. Das einzige, was wir noch sehen, ist Adobe Shockwave Flash application/x-shockwave-flash.

Es gibt tatsächlich noch ein paar übrig gebliebene Steuerelemente, z. B. in Firefox ist die Preview in FirefoxOption noch vorhanden:

In der Vergangenheit hätte dies die Auswahl zwischen mehreren Plugins ermöglicht, die diesen Typ registriert haben. Zum Beispiel die Liste der registrierten Typen für Flash:

Diese Tage standen auch im Vordergrund der Medienunterstützung, die mit HTML5 einherging. Es waren nicht nur PDFs - Ihr Browser hatte keine Ahnung, wie er mit einem MP4-Container oder einem H.264-Video umgeht, keine Ahnung, wie eine MP3-Datei usw. wiedergegeben wird oder sogar Windows Media Player oder Websites würden einen in Flash eingebauten Media Player einbetten.

Ich habe eine Erklärung gefunden. Laut einer Antwort, die ich gefunden habe , scheint Chrome ein PDF herunterzuladen, wenn der MIME-Inhaltstyp nicht auf application/pdf"Falscher oder generischer MIME-Typ" festgelegt ist application/octet-stream.

Außerdem : „ Die meisten Web - Server senden unknown-Typ Ressourcen , um die Standard mit application/octet-streamMIME - Typ. Aus Sicherheitsgründen sind die meisten Browser erlauben keine benutzerdefinierte Standardaktion für diese Ressourcen einstellen, wodurch der Benutzer gezwungen , es zu speichern , auf die Festplatte zu benutzen.“

Dies liegt daran, dass der HTTP- Content-DispositionHeader angibt, dass es sich bei der Datei um einen Anhang handelt . Dadurch wird der Browser angewiesen, die Datei herunterzuladen, anstatt sie direkt zu öffnen.

Es gibt ein Chrome-Add-On, das dieses Verhalten außer Kraft setzen kann. Das folgende Bild stammt aus den Firefox-Entwicklertools: