¿Cuál es la diferencia de ContentType y MimeType?

Hasta donde yo sé, son absolutamente iguales. Sin embargo, al navegar por algunos documentos de django, encontré este fragmento de código:

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

lo que me sorprende que los dos se lleven bien. Los documentos oficiales pudieron resolver el problema de manera práctica:

content_type es un alias de mimetype. Históricamente, este parámetro solo se llamaba mimetype, pero dado que en realidad es el valor incluido en el encabezado HTTP Content-Type, también puede incluir la codificación del juego de caracteres, lo que lo convierte en algo más que una especificación de tipo MIME. Si se especifica mimetype (no None), se usa ese valor. De lo contrario, se utiliza content_type. Si no se proporciona ninguno, se utiliza la configuración DEFAULT_CONTENT_TYPE.

Sin embargo, no lo encuentro lo suficientemente esclarecedor. ¿Por qué usamos 2 nombres diferentes para (casi lo mismo) algo? ¿Es "Content-Type" solo un nombre que se usa en las solicitudes del navegador y con muy poco uso fuera de él?

¿Cuál es la principal diferencia entre cada uno y cuándo es correcto llamar a algo mimetypeen lugar de content-type? ¿Estoy siendo lamentable y gramaticalmente nazi?

¿Por qué usamos 2 nombres diferentes para (casi lo mismo) algo? ¿Es "Content-Type" solo un nombre que se usa en las solicitudes del navegador y con muy poco uso fuera de él?

¿Cuál es la principal diferencia entre cada uno y cuándo es correcto llamar a algo tipo mime en lugar de tipo de contenido? ¿Estoy siendo lamentable y gramaticalmente nazi?

La razón no es solo la compatibilidad con versiones anteriores, y me temo que la excelente documentación de Django es un poco complicada al respecto. MIME (realmente vale la pena leer al menos la entrada de Wikipedia) tiene su origen en la extensión del correo de Internet, y específicamente SMTP. A partir de ahí, el diseño de extensión inspirado en MIME y MIME se ha abierto camino en muchos otros protocolos (como HTTP aquí), y todavía se utiliza cuando es necesario transmitir nuevos tipos de metadatos o datos en un protocolo existente. Hay docenas de RFC que analizan el uso de MIME para una gran cantidad de propósitos.

Específicamente, Content-Type:es uno entre varios encabezados MIME. "Mimetype" de hecho suena obsoleto, pero una referencia a MIME en sí no lo es. Llame a esa parte compatibilidad con versiones anteriores, si lo desea.

[Por cierto, esto es puramente un problema de terminología que no tiene nada que ver con la gramática. Archivar todas las preguntas de uso en "gramática" es un motivo de preocupación para mí. Grrrr.]

Siempre he visto contentType como un superconjunto de mimeType. La única diferencia es la codificación del juego de caracteres opcional. Si contentType no incluye una codificación de juego de caracteres opcional, entonces es idéntico a mimeType. De lo contrario, mimeType son los datos anteriores a la secuencia de codificación del juego de caracteres.

P.EJ text/html; charset=UTF-8

text/htmles mimeType
;es el indicador de parámetros adicionales
charset=UTF-8es el parámetro de codificación del juego de caracteres

P.EJ application/msword

application/mswordes mimeType
No puede tener una codificación de juego de caracteres, ya que describe un bien formado que octet-streamno comprende caracteres directamente.

Si desea conocer los detalles consulte el ticket 3526 .

Citar:

Se agregó content_type como un alias para mimetype al constructor HttpResponse. Es un nombre un poco más preciso. Basado en un parche de Simon Willison. Totalmente compatible con versiones anteriores.

¿Por qué usamos 2 nombres diferentes para (casi lo mismo) algo?

Compatibilidad con versiones anteriores, basada en su cotización de la documentación.