Lorsque je vais à certaines adresses de fichiers PDF, Chrome télécharge le PDF au lieu de l'ouvrir à l'aide de la visionneuse PDF intégrée. La page est alors blanche en blanc.

Mes paramètres Chrome ne posent aucun problème: j'essaie les adresses d'autres fichiers PDF et Chrome se comporte comme prévu (je l'ai configuré pour utiliser la visionneuse PDF intégrée de Chrome). Mais à chaque fois que j'essaie d'utiliser la même adresse problématique, Chrome télécharge le PDF, puis affiche une page vierge.

J'utilise Windows 10 et Chrome Version 63.0.3239.84 (Official Build) (64-bit).

Mon URL problématique spécifique cette fois est ici (un résultat de recherche Google).

En gros, cela se produit parce que le site Web indique au navigateur de le faire. Parfois, c'est parce que le développeur du site Web décide qu'il souhaite ce comportement, par exemple sur les sites de partage de fichiers. D'autres fois, c'est parce qu'il s'agit d'une option par défaut pour tous les logiciels qu'ils utilisent (par exemple, les logiciels de forum ou de blogging). Parfois, c'est parce que le développeur du site n'a aucune idée de ce qu'il fait.

Content-Disposition

C'est généralement parce que le site envoie un en- Content-Dispositiontête dans la réponse. Plus précisément, il peut envoyer un inlineou attachment.

inline est la valeur par défaut, sauf indication contraire, et signifie que le navigateur ouvrira le fichier dans la fenêtre du navigateur s'il le peut.

attachment signifie toujours télécharger le fichier, ne jamais tenter de l'ouvrir dans le navigateur.

Si vous ouvrez les outils de développement de votre navigateur, vous verrez que ce lien en particulier envoie les en-têtes de réponse suivants:

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

Cela indique au navigateur de toujours télécharger ( attachment) le fichier et de lui attribuer le nom de fichier par défaut Schubert-Sonata-21-B-flat.pdfplutôt que de l'inférer à partir de l'URL. De plus, il indique (correctement) au navigateur qu'il s'agit d'un application/pdffichier - mais comme il s'agit d'un fichier, le attachmenttéléchargement restera par défaut.

Détails de la manipulation en ligne

Lorsqu'une Content-Dispositionest en ligne (ou non spécifiée), le navigateur essaie d'ouvrir le fichier dans le visualiseur intégré par défaut. Cela ne fonctionne que lorsque le navigateur sait de quel type de fichier il s'agit et qu'il sait comment ouvrir ce type de fichier .

Détection de type

Le type de fichier peut être spécifié par le serveur avec un en- Content-Typetête. Par exemple, les types en ligne les plus courants sont text/html, application/javascriptet text/cssconstituent les trois parties principales d’un site Web moderne. Vous pouvez également avoir plus de types ésotériques comme application/pdf.

Une autre possibilité est que le serveur a spécifié un Content-Typedes application/octet-stream. C'est le type le plus générique, et il indique au navigateur qu'il ne s'agit que de données arbitraires. À ce stade, le navigateur ne peut que télécharger le fichier (en théorie, nous y arriverons).

Quand un Content-Typen'est pas spécifié par le serveur (et parfois même quand c'est le cas), le navigateur peut effectuer ce que l'on appelle un renifleur pour essayer de deviner le type en lisant le fichier et en recherchant des modèles.

Type de manutention

Lors de la réception d'un fichier avec une inlinedisposition ou une disposition non spécifiée, le navigateur doit essayer de l'ouvrir dans son navigateur si possible. Pour ce faire, il examine le type de fichier et, s’il reconnaît le type, essaiera de l’ouvrir. La plupart des navigateurs ouvriront n'importe quel text/type dans une simple visionneuse de texte, essaieront de générer text/htmlun rendu en tant que page Web, pourraient s'ouvrir application/jsondans une visionneuse spéciale mise en surbrillance de la syntaxe , etc.

Le type a application/octet-streamété manipulé spécialement. Puisqu'il est supposé être le type le plus générique, désignant un flux d'octets arbitraire, aucun gestionnaire ne doit s'appliquer à tous les fichiers de ce "type". Par exemple, dans Firefox, cela se traduit par une impossibilité de définir le gestionnaire par défaut pour application/octet-stream.

Certains sites Web ont également utilisé des types non standard. J'ai vu application/force-downloadutilisé - ce qui aboutit à un téléchargement car le navigateur ne reconnaît pas ou ne sait pas quoi faire d'autre avec le type, mais ne bénéficie pas de la manipulation spéciale qui le application/octet-streamfait.

Pour voir comment les fichiers PDF sont gérés, nous pouvons nous plonger un peu dans l'historique Web. Voyez-vous, dans le passé, les navigateurs n’avaient aucune idée du format PDF. Donc, ils ne pouvaient pas l'ouvrir. Mais nous avons vu des PDF s'ouvrir dans les navigateurs bien avant que les visualiseurs de PDF intégrés ne soient une chose, comment cela a-t-il fonctionné?

Auparavant, il était possible d'étendre les fonctionnalités du navigateur avec beaucoup plus de contrôle que ce que vous pouvez faire avec des extensions / addons limités de nos jours. Celles-ci étaient connues sous le nom générique de plugins . Dans Internet Explorer, il s’agissait de contrôles ActiveX; dans Mozilla Firefox et plus tard Google Chrome, il s’agissait de plugins NPAPI. Ces plugins étaient capables de faire tout ce que tout autre programme pouvait faire, et pouvaient également s’inscrire en tant que gestionnaire pour un type de fichier spécifique qui, autrement, pourrait ne pas être reconnu par le navigateur. (Incidemment, cela a ensuite été considéré comme un énorme risque pour la sécurité et le support de ces puissants plugins a été progressivement abandonné ...)

À l'époque des plugins, vous installeriez Adobe Acrobat Reader, qui installerait ensuite un plugin ActiveX ou NPAPI qui enregistrerait le application/pdftype MIME et demanderait au navigateur d'ouvrir ces types en ligne à l'aide du plugin.

Bien sûr, après un certain nombre de problèmes de sécurité et de performances causés par ces plugins, les principaux éditeurs de navigateurs ont décidé d’intégrer leurs propres visualiseurs PDF tout en supprimant progressivement la prise en charge de la plupart des plugins. Le seul que nous voyons encore est Adobe Shockwave Flash, qui le gère application/x-shockwave-flash.

Il reste encore quelques contrôles restants pour cela, par exemple, dans Firefox, l' Preview in Firefoxoption existe toujours:

Dans le passé, cela aurait permis de choisir entre plusieurs plugins ayant enregistré ce type. Par exemple, la liste des types enregistrés pour Flash:

Ces jours étaient aussi avant la prise en charge de nombreux médias fournis avec HTML5. Il ne s’agissait pas que de fichiers PDF: votre navigateur n’aurait aucune idée de la façon de traiter un conteneur MP4 ou une vidéo H.264, ni de savoir comment lire un fichier MP3, etc., etc. Vous verriez des plugins fournis par des lecteurs multimédias tels que VLC ou même Windows Media Player, ou des sites Web intégreraient un lecteur multimédia intégré à Flash.

J'ai trouvé une explication. Selon une réponse que je trouve , il semble que Chrome va télécharger un fichier PDF si le type de contenu MIME est défini pas , application/pdfmais plutôt un « type MIME incorrect ou générique », application/octet-stream.

En outre , "la plupart des serveurs Web envoient des ressources de type inconnu en utilisant le application/octet-streamtype MIME par défaut . Pour des raisons de sécurité, la plupart des navigateurs ne permettent pas de définir une action par défaut personnalisée pour ces ressources, ce qui oblige l'utilisateur à la stocker sur le disque pour l'utiliser."

Cela est dû à l' en- Content-Dispositiontête HTTP spécifiant que le fichier est une pièce jointe . Cela indique au navigateur de télécharger le fichier plutôt que de l'ouvrir directement.

Il existe un module complémentaire Chrome qui peut remplacer ce comportement. L'image suivante provient des outils de développement de Firefox: