Quelle est la différence entre ContentType et MimeType

Autant que je sache, ils sont absolument égaux. Cependant, en parcourant certains documents django, j'ai trouvé ce morceau de code:

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

ce qui me surprend que les deux s'entendent. La documentation officielle a pu résoudre le problème de manière pratique:

content_type est un alias pour mimetype. Historiquement, ce paramètre s'appelait uniquement 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 en fait plus qu'une simple spécification de type MIME. Si le type MIME est spécifié (et non None), cette valeur est utilisée. Sinon, content_type est utilisé. Si ni l'un ni l'autre n'est indiqué, le paramètre DEFAULT_CONTENT_TYPE est utilisé.

Cependant, je ne trouve pas cela suffisamment élucidant. Pourquoi utilisons-nous 2 noms différents pour (presque la même) chose? "Content-Type" est-il juste un nom utilisé dans les requêtes du navigateur, et avec très peu d'utilité en dehors?

Quelle est la principale différence entre chacun et quand est-il juste d'appeler quelque chose mimetypepar opposition à content-type? Suis-je pitoyable et nazi de grammaire?

Pourquoi utilisons-nous 2 noms différents pour (presque la même) chose? "Content-Type" est-il juste un nom utilisé dans les requêtes du navigateur, et avec très peu d'utilité en dehors?

Quelle est la principale différence entre chacun d'eux et quand est-il juste 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 rétrocompatibilité, et j'ai bien peur que la documentation Django habituellement excellente soit un peu vague à ce sujet. MIME (il vaut vraiment la peine de lire au moins l'entrée de Wikipédia) a son origine dans l'extension du courrier Internet, et plus particulièrement du SMTP. À partir de là, la conception d'extension inspirée de MIME et MIME a trouvé son chemin dans de nombreux autres protocoles (comme 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 de MIME utilisé pour une multitude d'objectifs.

Plus précisément, Content-Type:est l'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 rétrocompatibilité, si vous voulez.

[BTW, c'est purement un problème de terminologie qui n'a absolument rien à voir avec la grammaire. Déposer toutes les questions d'utilisation sous «grammaire» est une bête noire de ma part. Grrrr.]

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

PAR EXEMPLE text/html; charset=UTF-8

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

PAR EXEMPLE application/msword

application/mswordest le mimeType
Il ne peut pas avoir un encodage de jeu de caractères car il décrit un bien formé octet-streamne comprenant pas directement de caractères.

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

Citation:

Content_type ajouté comme alias pour mimetype au constructeur HttpResponse. C'est un nom un peu plus précis. Basé sur un patch de Simon Willison. Entièrement rétrocompatible.

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

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