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-Disposition
tête dans la réponse. Plus précisément, il peut envoyer un inline
ou 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.pdf
plutôt que de l'inférer à partir de l'URL. De plus, il indique (correctement) au navigateur qu'il s'agit d'un application/pdf
fichier - mais comme il s'agit d'un fichier, le attachment
téléchargement restera par défaut.
Détails de la manipulation en ligne
Lorsqu'une Content-Disposition
est 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-Type
tête. Par exemple, les types en ligne les plus courants sont text/html
, application/javascript
et text/css
constituent 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-Type
des 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-Type
n'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 inline
disposition 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/html
un rendu en tant que page Web, pourraient s'ouvrir application/json
dans 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-download
utilisé - 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-stream
fait.
Un peu d'histoire
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/pdf
type 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 Firefox
option 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.
Content-Type: application/octet-stream
mais c'est beaucoup moins courant de nos jours.