Qual é a diferença de ContentType e MimeType

Pelo que eu sei, eles são absolutamente iguais. No entanto, navegando em alguns documentos do django, encontrei este código:

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

o que me surpreende os dois se dando bem. Os documentos oficiais conseguiram resolver o problema de forma prática:

content_type é um alias para mimetype. Historicamente, esse parâmetro era chamado apenas de tipo MIME, mas como esse é realmente o valor incluído no cabeçalho HTTP Content-Type, ele também pode incluir a codificação do conjunto de caracteres, o que o torna mais do que apenas uma especificação de tipo MIME. Se mimetype for especificado (não nenhum), esse valor será usado. Caso contrário, content_type é usado. Se nenhum for fornecido, a configuração DEFAULT_CONTENT_TYPE será usada.

No entanto, não acho isso elucidativo o suficiente. Por que usamos 2 nomes diferentes para (quase a mesma) coisa? "Content-Type" é apenas um nome usado em solicitações de navegador e com muito pouco uso fora dele?

Qual é a principal diferença entre cada um e quando é certo chamar algo mimetypeem vez de content-type? Estou sendo lamentável e nazista da gramática?

Por que usamos 2 nomes diferentes para (quase a mesma) coisa? "Content-Type" é apenas um nome usado em solicitações de navegador e com muito pouco uso fora dele?

Qual é a principal diferença entre cada um e quando é certo chamar algo mimetype ao invés de content-type? Estou sendo lamentável e nazista da gramática?

A razão não é apenas a compatibilidade com versões anteriores, e temo que a documentação normalmente excelente do Django seja um pouco complicada sobre isso. MIME (vale realmente a pena ler pelo menos a entrada da Wikipedia) tem sua origem na extensão do correio da Internet e, especificamente, o SMTP. A partir daí, o design de extensão inspirado em MIME e MIME encontrou seu caminho em muitos outros protocolos (como o HTTP aqui) e ainda está sendo usado quando novos tipos de metadados ou dados precisam ser transmitidos em um protocolo existente. Existem dezenas de RFCs que discutem o MIME usado para uma infinidade de propósitos.

Especificamente, Content-Type:é um entre vários cabeçalhos MIME. "Mimetype" realmente parece obsoleto, mas uma referência ao MIME em si não é. Chame essa parte de compatibilidade com versões anteriores, se quiser.

[BTW, este é puramente um problema de terminologia que não tem nada a ver com gramática. Arquivar todas as questões de uso em "gramática" é uma implicância minha. Grrrr.]

Sempre considerei contentType como um superconjunto de mimeType. A única diferença é a codificação do conjunto de caracteres opcional. Se o contentType não incluir uma codificação de conjunto de caracteres opcional, ele será idêntico a um mimeType. Caso contrário, o mimeType são os dados anteriores à sequência de codificação do conjunto de caracteres.

POR EXEMPLO text/html; charset=UTF-8

text/htmlé o mimeType
;é o indicador de parâmetros adicionais
charset=UTF-8é o parâmetro de codificação do conjunto de caracteres

POR EXEMPLO application/msword

application/mswordé o mimeType.
Ele não pode ter uma codificação de conjunto de caracteres, pois descreve um bem formado que octet-streamnão compreende caracteres diretamente.

Se você quiser saber os detalhes, consulte o ticket 3526 .

Citar:

Adicionado content_type como um alias para mimetype para o construtor HttpResponse. É um nome um pouco mais preciso. Baseado em um patch de Simon Willison. Totalmente compatível com versões anteriores.

Por que usamos 2 nomes diferentes para (quase a mesma) coisa?

Compatibilidade com versões anteriores, com base em sua citação da documentação.