Quelle est la différence entre ContentType et MimeType

Pour autant que je sache, ils sont absolument égaux. Cependant, en parcourant certains django docs, j’ai trouvé ce morceau de code:

HttpResponse.__init__(content='', mimetype=None, status=200, content_type='text/html')

ce qui me surprend les deux s’entendent. Les documents officiels ont pu résoudre le problème de manière pratique:

content_type est un alias pour mimetype. Historiquement, ce paramètre était uniquement appelé mimetype, mais comme il s’agit en fait de la valeur incluse dans l’en-tête HTTP Content-Type, il peut également inclure le codage du jeu de caractères, ce qui le rend plus qu’une simple spécification de type MIME. Si mimetype est spécifié (pas None), cette valeur est utilisée. Sinon, content_type est utilisé. Si aucun n’est donné, le paramètre DEFAULT_CONTENT_TYPE est utilisé.

Cependant, je ne trouve pas assez élucidant. Pourquoi nous utilisons 2 noms différents pour (presque la même) chose? Est-ce que “Content-Type” est juste un nom utilisé dans les requêtes du navigateur, et avec très peu d’utilisation à l’extérieur?

Quelle est la principale différence entre chacun, et quand est-il correct d’appeler quelque chose de mimetype par opposition à content-type de content-type ? Suis-je pitoyable et nazi?

Pourquoi nous utilisons 2 noms différents pour (presque la même) chose? Est-ce que “Content-Type” est juste un nom utilisé dans les requêtes du navigateur, et avec très peu d’utilisation à l’extérieur?

Quelle est la principale différence entre chacun, et quand est-il correct d’appeler quelque chose de type MIME par opposition à type de contenu? Suis-je pitoyable et nazi de grammaire?

La raison n’est pas seulement la compatibilité ascendante, et je crains que l’excellente documentation de Django ne soit un peu floue à ce sujet. MIME (cela vaut vraiment la peine de lire au moins l’entrée de Wikipedia) a pour origine l’extension de la messagerie Internet, et plus particulièrement du protocole SMTP. À partir de là, la conception d’extension inspirée par MIME et MIME a trouvé sa place dans de nombreux autres protocoles (tels que HTTP ici) et est toujours utilisée lorsque de nouveaux types de métadonnées ou de données doivent être transmis dans un protocole existant. Il existe des dizaines de RFC qui traitent du MIME utilisé à des fins multiples.

Spécifiquement, Content-Type: est un parmi plusieurs en-têtes MIME. “Mimetype” semble en effet obsolète, mais une référence à MIME lui-même ne l’est pas. Appelez cette partie en arrière, si vous voulez.

[BTW, c’est purement un problème de terminologie qui n’a rien à voir avec la grammaire. Le classement de chaque question d’utilisation sous “grammaire” est une bête noire. Grrrr.]

J’ai toujours considéré contentType comme un sur-ensemble de mimeType. La seule différence est le codage facultatif du jeu de caractères. Si le contentType n’inclut pas un encodage de jeu de caractères optionnel, il est identique à un type mime. Sinon, le mimeType correspond aux données antérieures à la séquence de codage du jeu de caractères.

EG text/html; charset=UTF-8 text/html; charset=UTF-8

text/html est le mimeType
; est l’indicateur de parameters supplémentaires
charset=UTF-8 est le paramètre de codage du jeu de caractères

EG application/msword

application/msword est le mimeType
Il ne peut pas avoir un codage de jeu de caractères car il décrit un octet-stream bien formé ne comprenant pas directement de caractères.

Si vous voulez connaître les détails, voir ticket 3526 .

Citation:

Ajout de content_type comme alias pour mimetype au constructeur HttpResponse. C’est un nom légèrement plus précis. Basé sur un patch de Simon Willison. Entièrement compatible avec les versions antérieures.

Pourquoi nous utilisons 2 noms différents pour (presque la même) chose?

Compatibilité descendante, basée sur votre devis de la documentation.