En fait, cela se produit parce que le site Web demande au navigateur de le faire. Parfois, c'est parce que le développeur du site Web décide qu'il veut ce comportement, comme c'est le cas sur les sites de partage de fichiers. D'autres fois, c'est parce que c'est une option par défaut du logiciel qu'ils utilisent (par exemple, un forum ou un logiciel de blog). 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 Content-Disposition dans la réponse. Plus précisément, il peut envoyer soit inline o attachment .

inline est la valeur par défaut si elle n'est pas spécifiée, et signifie que le navigateur ouvrira le fichier dans la fenêtre du navigateur s'il le peut.

attachment signifie qu'il faut toujours télécharger le fichier, ne jamais essayer de l'ouvrir dans le navigateur.

Si vous ouvrez les outils de développement de votre navigateur, vous verrez que ce lien 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 donner le nom de fichier par défaut de Schubert-Sonata-21-B-flat.pdf plutôt que de le déduire de l'URL. De plus, il indique au navigateur (correctement) qu'il s'agit d'un fichier application/pdf mais comme il s'agit d'un fichier attachment le navigateur continuera à proposer le téléchargement par défaut.

Détails de la manipulation en ligne

Lorsqu'un Content-Disposition est en ligne (ou non spécifié), le navigateur essaiera d'ouvrir le fichier dans le visualiseur intégré par défaut. Cela ne fonctionne que si le navigateur sait de quel type de fichier il s'agit, y le navigateur sait comment ouvrir ce type.

Détection de type

Le type de fichier peut être spécifié par le serveur à l'aide de l'option Content-Type en-tête. Par exemple, les types d'en-tête les plus courants sont les suivants text/html , application/javascript y text/css qui constituent les trois parties principales d'un site web moderne. Vous pouvez également avoir des types plus ésotériques comme application/pdf .

Une autre possibilité est que le serveur ait spécifié un Content-Type de application/octet-stream . Il s'agit du type le plus générique, qui indique au navigateur que le fichier n'est qu'une donnée arbitraire. À ce stade, la seule chose que le navigateur peut faire est de le télécharger (en théorie - nous y reviendrons).

Lorsqu'un Content-Type n'est pas spécifié par le serveur (et parfois même lorsqu'il l'est), le navigateur peut effectuer ce qui est connu sous le nom de reniflant pour essayer de deviner le type en lisant le fichier et en recherchant des motifs.

Manipulation de type

Lors de la réception d'un fichier avec un inline ou une disposition non spécifiée, le navigateur doit essayer de l'ouvrir dans le navigateur si possible. Pour ce faire, il examine le type de fichier et, s'il le reconnaît, il essaie de l'ouvrir. La plupart des navigateurs ouvrent tout text/ dans un simple visualisateur de texte, essaiera de rendre text/html comme une page web, pourrait ouvrir application/json dans une visionneuse spéciale avec syntaxe mise en évidence etc.

Le type application/octet-stream a été traité de manière spéciale. Puisque c'est censé être le type le plus générique, désignant un flux arbitraire d'octets, il n'est pas censé y avoir de gestionnaire qui puisse s'appliquer à tous les fichiers de ce "type". Par exemple, dans Firefox, cela se manifeste par l'impossibilité de définir le gestionnaire par défaut para application/octet-stream .

Certains sites web ont également utilisé des types non standard. J'ai vu application/force-download utilisé - qui finit par être téléchargé parce que le navigateur ne reconnaît pas ou ne sait pas quoi faire d'autre avec le type, mais ne bénéficie pas du traitement spécial que les application/octet-stream fait.

Une petite leçon d'histoire

Pour voir comment les PDF sont traités, nous pouvons nous plonger un peu dans l'histoire du web. Vous voyez, dans le passé, les navigateurs n'avaient aucune idée de ce qu'était un PDF. Ils ne pouvaient donc pas l'ouvrir. Mais nous avons vu des PDF être ouverts dans des navigateurs bien avant que les visionneuses de PDF intégrées ne soient une chose, alors comment cela a-t-il fonctionné ?

Il était autrefois possible d'étendre les fonctionnalités du navigateur avec beaucoup plus de contrôle que ce que l'on peut faire aujourd'hui avec des extensions/addons limités. Ces extensions é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 n'importe quel autre programme pouvait faire, et pouvaient en outre s'enregistrer en tant que gestionnaire d'un type de fichier spécifique qui pourrait autrement ne pas être reconnu par le navigateur. (Par ailleurs, on a constaté par la suite que cela représentait un énorme risque pour la sécurité et le support de ces puissants plugins a été progressivement abandonné...)

À l'époque des plugins, il suffisait d'installer Adobe Acrobat Reader, qui installait ensuite un plugin ActiveX ou NPAPI pour enregistrer l'interface utilisateur. application/pdf type MIME et indiquer au navigateur d'ouvrir ces types en ligne en utilisant le plugin.

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

En fait, il reste encore quelques contrôles pour cela, par exemple, dans Firefox, la fonction Preview in Firefox existe toujours :

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

Cette époque était également antérieure à la prise en charge de nombreux médias par le HTML5. Il n'y avait pas que les PDF - votre navigateur n'avait aucune idée de la façon de gérer un conteneur MP4 ou une vidéo H.264, aucune idée de la façon de lire un fichier MP3, etc. On voyait des plugins fournis par des lecteurs multimédias comme VLC ou même Windows Media Player, ou bien les sites Web intégraient un lecteur multimédia construit en Flash.