Ai-je besoin de Content-Type: application / octet-stream pour le téléchargement de fichier?
Le norme HTTP dit:
Si cet en-tête [Content-Disposition: attachment] est utilisé dans une réponse avec le type de contenu application/octet-stream, la suggestion implicite est que l'agent utilisateur ne devrait pas afficher la réponse, mais entrer directement une réponse `save en tant que .. . 'dialogue.
Je lis cela comme
Content-Type: application/octet-stream
Content-Disposition: attachment
Mais j'aurais pensé que Content-Type serait application/pdf, image/png, etc.
Devrais-je avoir Content-Type: application/octet-stream si je veux que les navigateurs téléchargent le fichier?
Non.
Le type de contenu doit être celui que l'on sache, si vous le connaissez. application/octet-stream est défini en tant que "données binaires arbitraires" dans la RFC 2046 et il y a un chevauchement évident de son utilisation pour les entités dont le seul objectif est d'être sauvegardé sur disque, et à partir de là, être en dehors de toute chose " webby ". Ou regarder ça d'une autre direction; la seule chose que l'on puisse faire en toute sécurité avec application/octet-stream est de l'enregistrer dans un fichier et d'espérer que quelqu'un d'autre sache à quoi il sert.
Vous pouvez combiner l'utilisation de Content-Disposition avec d'autres types de contenu, tels que image/png ou même text/html pour indiquer que vous souhaitez enregistrer plutôt que d'afficher. Auparavant, certains navigateurs l'ignoraient dans le cas de text/html mais je pense que c'était il y a longtemps déjà (et je vais bientôt me coucher, donc je ne vais pas commencer tester tout un tas de navigateurs maintenant, peut-être plus tard).
La RFC 2616 mentionne également la possibilité de jetons d’extension, et de nos jours la plupart des navigateurs reconnaissent que inline signifie que vous voulez que l’entité soit affichée si possible (c’est-à-dire que si c’est un type que le navigateur sait afficher, sinon choix en la matière). Ceci est bien sûr le comportement par défaut de toute façon, mais cela signifie que vous pouvez inclure la partie filename de l’en-tête, que les navigateurs utiliseront (peut-être avec quelques ajustements afin que les extensions de fichier correspondent aux normes système locales pour le type de contenu dans question, peut-être pas) comme suggestion si l'utilisateur essaie de sauvegarder.
Par conséquent:
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="picture.png"
Cela signifie "Je ne sais pas ce que c'est. Bon, sauvegardez-le sous un fichier, de préférence nommé picture.png".
Content-Type: image/png
Content-Disposition: attachment; filename="picture.png"
Signifie "Ceci est une image PNG. Veuillez l'enregistrer en tant que fichier, de préférence nommé picture.png".
Content-Type: image/png
Content-Disposition: inline; filename="picture.png"
Signifie "Ceci est une image PNG. Veuillez l'afficher sauf si vous ne savez pas comment afficher les images PNG. Sinon, ou si l'utilisateur choisit de l'enregistrer, nous vous recommandons le nom picture.png pour le fichier dans lequel vous l'enregistrez".
Parmi les navigateurs qui reconnaissent inline certains l'utilisent toujours, d'autres l'utilisent si l'utilisateur a sélectionné "enregistrer le lien sous" mais pas s'il a sélectionné "enregistrer" lors de l'affichage (ou au moins IE était comme ça, ça a peut-être changé il y a quelques années).