Type de fichier inconnu MIME?

140

Dois-je spécifier un type MIME si le fichier téléchargé n'a pas d'extension? En d'autres termes, existe-t-il un type MIME général par défaut?

mime mime-types default-value Shimmy Weitzhandler
la source

Réponses:

184

Vous pouvez utiliser application/octet-streampour les types inconnus.

RFC 2046 stipule dans la section 4.5.1:

Le sous-type "flux d'octets" est utilisé pour indiquer qu'un corps contient des données binaires arbitraires.

Bombe
la source

En fait, selon les RFC, vous ne devez envoyer aucune information de type avec des données inconnues. La RFC-2046 définit uniquement les types connus mais la RFC-7231 vous indique comment gérer les types inconnus.

Sampo Sarrala - codidact.org

@SampoSarrala J'ai lu la RFC-7231 un peu différemment: "Si un champ d'en-tête Content-Type n'est pas présent, le destinataire PEUT soit assumer un type de média" application / octet-stream "([RFC2046], Section 4.5.1) ou examinez les données pour déterminer leur type. " J'interprète cela comme nous devrions envoyer NO Content-Type ou nous sommes sûrs d'envoyer une application / octet-stream par défaut si nous ne voulons pas que les clients jouent à des jeux de devinettes avec examen du contenu.

Jpnh

@Jpnh Oui, c'est vrai. L'en-tête Content-Type ne doit pas être présent lorsqu'il est inconnu. On pourrait aussi envoyer application / octet-stream qui dit essentiellement au client que " vous ne voulez pas l'afficher tout de suite, mais continuez et enregistrez ces octets dans un fichier à la place ". Cela fait que les clients Web proposent de sauvegarder le fichier. Option 1 == Je ne sais rien de ce fichier. Option 2 == Le contenu du fichier ne peut pas être décrit à l'aide de mime ou il ne doit être enregistré que sur le disque. Dans la pratique, l'une ou l'autre option serait correcte. J'aurais dû choisir une meilleure formulation pour éviter toute confusion.

Sampo Sarrala - codidact.org

Les «données binaires arbitraires» ne sont pas «inconnues». En utilisant application / octet-stream, vous indiquez au navigateur que le type de contenu est connu, qu'il ne s'agit ni de texte ni d'image, mais de données binaires arbitraires et qu'il doit par conséquent être téléchargé dans un fichier et éventuellement exécuté. En plus de se tromper, il s'agit d'une faille de sécurité, surtout si l'on considère les gestionnaires de téléchargement modernes à peine visibles. La bonne réponse est l'absence d'en-tête de type contenu. Si vous ne savez pas de quel type de fichier il s'agit, le navigateur peut le connaître alors laissez-le deviner, surtout quand il connaît le contexte d'utilisation (image, document, script, ...)

FF_Dev

@FF_Dev Je suis sûr que c'est insensé. «Données binaires arbitraires» n'implique pas «exécutable»; il n'y a aucune raison qu'un navigateur (ou un gestionnaire de téléchargement) suppose qu'un application/octet-streamfichier est exécutable. Et même si un navigateur est en cours de téléchargement en connaissance de cause d' un fichier exécutable, il ne « peut - être exécuter » sans l'utilisateur demandant; le simple téléchargement d'un exécutable n'implique pas que je veux qu'il soit exécuté maintenant. S'il existe vraiment un navigateur qui peut exécuter application/octet-streamautomatiquement les fichiers lors du téléchargement, dites-nous lequel et comment reproduire le comportement. En ce moment, je ne te crois pas.

Mark Amery

Ressources RFC:

Nous devrions utiliser RFC-7231 (HTTP / 1.1 Semantics and Content) comme référence au lieu de RFC-2046 (Media Types) car la question portait clairement sur HTTP Content-Type.

De plus, la RFC-2046 ne définit pas clairement les types inconnus, contrairement à la RFC-7231.

Réponse courte:

N'envoyez pas de type MIME pour les données inconnues.
Pour être plus clair: n'utilisez pas du tout l'en-tête Content-Type.

Références:

Protocole de transfert hypertexte RFC-7231 (HTTP / 1.1): sémantique et contenu
3.1.1.5. Type de contenu

Un expéditeur qui génère un message contenant un corps de charge utile DEVRAIT
générer un champ d'en-tête Content-Type dans ce message à moins que le
type de support prévu de la représentation incluse ne soit inconnu de l'
expéditeur.

Cette section vous dit clairement de l'omettre si vous ne le savez pas avec certitude. Cela indique également que le receveur peut supposer que le type est application / octet-stream, mais le fait est que cela peut aussi être autre chose.

Qu'est-ce qui est différent alors?

RFC-2046
4.5.1. Sous-type de flux d'octets

L'action recommandée pour une implémentation qui reçoit une
entité "application / octet-stream" est simplement de proposer de placer les données
dans un fichier, avec tout Content-Transfer-Encoding annulé, ou peut-être de l'
utiliser comme entrée à un utilisateur spécifié processus.

Et, comme déjà indiqué ci-dessus:

RFC-7231
3.1.1.5. Type de contenu

Si un champ d'en-tête Content-Type n'est pas présent, le destinataire PEUT soit supposer un type de support de "application / octet-stream"
([RFC2046], paragraphe 4.5.1) ou examiner les données pour déterminer son type.

Conclusion:

Si vous le définissez comme "application / octet-stream", alors vous dites que vous savez que c'est "application / octet-stream".

Si vous ne le définissez pas, vous dites que vous ne savez pas ce que c'est et laissez la décision au récepteur et le récepteur pourrait alors vérifier si cela marche comme un canard et ...

Sampo Sarrala - codidact.org
la source

Cette réponse mérite un vote positif car elle est la seule dans la vérité. De plus, en utilisant "application / octet-stream" par défaut, la plupart des navigateurs déclenchent le téléchargement, ce qui est une faille de sécurité compte tenu des gestionnaires de téléchargement modernes presque invisibles.

FF_Dev

C'est correct pour HTTP, mais la question concerne MIME en général, pas HTTP. Dans le courrier électronique, par exemple, les règles sont complètement différentes. Voir aussi la discussion sur la proposition en double stackoverflow.com/questions/12539058/…

tripleee

J'ai donné une hausse pour la même raison, mais je suis d'accord avec FF_Dev. Sauf si l'intention est d'être "application / octet-stream" et de déclencher un téléchargement, il y a un besoin pour "application / unknown". Ce serait bien si les navigateurs n'essayaient pas de télécharger le fichier si le "Content-Disposition" n'était pas défini, mais il y a trop de sites Web téléchargeant des fichiers au hasard sans définir leur nom de fichier à utiliser. Surtout les banques.

justdan23

Je préfère application/unknown, mais le résultat sera sûrement le même queapplication/octet-stream

Lada
la source

Existe-t-il un standard qui permet d'utiliser application / unknown au lieu d'application / octet-stream?

Hendrik Brummermann

Merci! application / unknown fonctionne très bien, octet-stream entraîne une erreur dans Chrome sur mon exemple de fichier png!

fnkr

Pourquoi servir un fichier .png comme application/octet-streamou application/unknown? Il y a une raison pour laquelle ils ont inventé image/png.

Aidiakapi

@ jenson-button-event Cela n'a rien à voir avec la réinvention de la roue. Le type MIME spécifie votre intention. Si vous savez que ce que vous envoyez est censé être une image png, transmettez cette information. Si les octets représentent accidentellement un jpeg, votre application peut vous avertir que ce n'est pas un png valide et que vous avez un bogue ailleurs. De plus, toutes les applications ne sont pas aussi robustes et tolérantes aux pannes qu'un navigateur. Ils sont conçus pour corriger les erreurs du programmeur, mais c'est loin d'être leur seul objectif. Un navigateur n'est pas la seule application utilisant des types MIME.

Aidiakapi

Quelle est votre référence? le type inconnu ne fournit aucune information concernant le contenu ou l'état du fichier, ou même s'il est binaire ou basé sur du texte, il est trop obscur pour le code de production, peut convenir pour un petit projet, car si un fichier de type MIME n'a pas gestionnaire dans le système d'exploitation, il s'agit essentiellement d'un fichier binaire téléchargeable et le type inconnu est un handle connu dans le système d'exploitation Windows, auquel vous pouvez attribuer une action (par exemple ouvrir des fichiers inconnus avec le bloc-notes). Bien qu'une mauvaise pratique, vous pouvez utiliser le type inconnu combiné avec ceci pour ignorer toute exécution: /