Qual è la differenza di ContentType e MimeType

Per quanto ne so, sono assolutamente uguali. Tuttavia, sfogliando alcuni documenti di django, ho trovato questo pezzo di codice:

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

il che mi sorprende i due che vanno d'accordo. I documenti ufficiali sono stati in grado di risolvere il problema in modo pratico:

content_type è un alias per mimetype. Storicamente, questo parametro era chiamato solo mimetype, ma poiché questo è effettivamente il valore incluso nell'intestazione HTTP Content-Type, può anche includere la codifica del set di caratteri, che lo rende più di una semplice specifica del tipo MIME. Se viene specificato mimetype (non None), viene utilizzato quel valore. In caso contrario, viene utilizzato content_type. Se nessuno dei due viene fornito, viene utilizzata l'impostazione DEFAULT_CONTENT_TYPE.

Tuttavia, non lo trovo abbastanza delucidante. Perché usiamo 2 nomi diversi per (quasi la stessa) cosa? "Content-Type" è solo un nome utilizzato nelle richieste del browser e con pochissimo utilizzo al di fuori di esso?

Qual è la principale differenza tra ciascuno e quando è giusto chiamare qualcosa mimetypeinvece di content-type? Mi sto comportando da nazista e dalla grammatica?

Perché usiamo 2 nomi diversi per (quasi la stessa) cosa? "Content-Type" è solo un nome utilizzato nelle richieste del browser e con pochissimo utilizzo al di fuori di esso?

Qual è la differenza principale tra ognuno e quando è giusto chiamare qualcosa tipo mimetipo anziché tipo di contenuto? Sono un povero nazista e grammaticale?

Il motivo non è solo la retrocompatibilità, e temo che la documentazione di Django, solitamente eccellente, sia un po 'agitata al riguardo. MIME (vale davvero la pena leggere almeno la voce di Wikipedia) ha la sua origine nell'estensione della posta Internet, e in particolare SMTP. Da lì, il design delle estensioni ispirato a MIME e MIME ha trovato la sua strada in molti altri protocolli (come HTTP qui) e viene ancora utilizzato quando nuovi tipi di metadati o dati devono essere trasmessi in un protocollo esistente. Ci sono dozzine di RFC che discutono l'uso di MIME per una pletora di scopi.

In particolare, Content-Type:è una delle numerose intestazioni MIME. "Mimetype" sembra effettivamente obsoleto, ma un riferimento a MIME stesso non lo è. Chiama quella parte retrocompatibilità, se vuoi.

[BTW, questo è puramente un problema terminologico che non ha assolutamente nulla a che fare con la grammatica. Archiviare ogni domanda di utilizzo sotto "grammatica" è un mio problema. Grrrr.]

Ho sempre considerato contentType come un superset di mimeType. L'unica differenza è la codifica del set di caratteri opzionale. Se contentType non include una codifica del set di caratteri opzionale, è identico a un mimeType. Altrimenti, mimeType è i dati prima della sequenza di codifica del set di caratteri.

PER ESEMPIO text/html; charset=UTF-8

text/htmlè il mimeType
;è l'indicatore dei parametri aggiuntivi
charset=UTF-8è il parametro di codifica del set di caratteri

PER ESEMPIO application/msword

application/mswordis the mimeType
Non può avere una codifica del set di caratteri poiché descrive un formato ben formato che octet-streamnon comprende direttamente i caratteri.

Se vuoi conoscere i dettagli vedi ticket 3526 .

Citazione:

Aggiunto content_type come alias per mimetype al costruttore HttpResponse. È un nome leggermente più preciso. Basato su una patch di Simon Willison. Completamente retrocompatibile.

Perché usiamo 2 nomi diversi per (quasi la stessa) cosa?

Compatibilità con le versioni precedenti, in base alla tua citazione dalla documentazione.