What's the difference between ContentType and MimeType?
Question:
As far as I know, they are absolute equal. However, browsing some django docs, I’ve
found this piece of code:
HttpResponse.__init__(content='', mimetype=None, status=200, content_type='text/html')
which surprise me the two getting along each other. The official docs was able to solve the issue in a practical manner:
content_type is an alias for mimetype.
Historically, this parameter was only
called mimetype, but since this is
actually the value included in the
HTTP Content-Type header, it can also
include the character set encoding,
which makes it more than just a MIME
type specification. If mimetype is
specified (not None), that value is
used. Otherwise, content_type is used.
If neither is given, the
DEFAULT_CONTENT_TYPE setting is used.
However, I don’t find it elucidating enough. Why we use 2 different naming for (almost the same) thing? Is "Content-Type" just a name used in browser requests, and with very little use outside it?
What’s the main difference between the each one, and when is right to call something mimetype as opposed to content-type ? Am I being petty and a grammar nazi?
Answers:
Why we use 2 different naming for (almost the same) thing?
Backwards compatibility, based on your quote from the documentation.
Why we use 2 different naming for
(almost the same) thing? Is
“Content-Type” just a name used in
browser requests, and with very little
use outside it?
What’s the main difference between the
each one, and when is right to call
something mimetype as opposed to
content-type ? Am i being pitty and
grammar nazi?
The reason isn’t only backward compatibility, and I’m afraid the usually excellent Django documentation is a bit hand-wavy about it. MIME (it’s really worth reading at least the Wikipedia entry) has its origin in extending internet mail, and specifically SMTP. From there, the MIME and MIME-inspired extension design has found its way into a lot of other protocols (such as HTTP here), and is still being used when new kinds of metadata or data need to be transmitted in an existing protocol. There are dozens of RFCs that discuss MIME used for a plethora of purposes.
Specifically, Content-Type: is one among several MIME headers. “Mimetype” does indeed sound obsolete, but a reference to MIME itself isn’t. Call that part backward-compatibility, if you will.
[BTW, this is purely a terminology problem which has nothing whatsoever to do with grammar. Filing every usage question under “grammar” is a pet peeve of mine. Grrrr.]
If you want to know the details see ticket 3526.
Quote:
Added content_type as an alias for
mimetype to the HttpResponse
constructor. It’s a slightly more
accurate name. Based on a patch from
Simon Willison. Fully backwards
compatible.
I’ve always viewed contentType to be a superset of mimeType. The only difference being the optional character set encoding. If the contentType does not include an optional character set encoding then it is identical to a mimeType. Otherwise, the mimeType is the data prior to the character set encoding sequence.
E.G. text/html; charset=UTF-8
text/html is the mimeType
; is the additional parameters indicator
charset=UTF-8 is the character set encoding parameter
E.G. application/msword
application/msword is the mimeType
It cannot have a character set encoding as it describes a well formed octet-stream not comprising characters directly.
As far as I know, they are absolute equal. However, browsing some django docs, I’ve
found this piece of code:
HttpResponse.__init__(content='', mimetype=None, status=200, content_type='text/html')
which surprise me the two getting along each other. The official docs was able to solve the issue in a practical manner:
content_type is an alias for mimetype.
Historically, this parameter was only
called mimetype, but since this is
actually the value included in the
HTTP Content-Type header, it can also
include the character set encoding,
which makes it more than just a MIME
type specification. If mimetype is
specified (not None), that value is
used. Otherwise, content_type is used.
If neither is given, the
DEFAULT_CONTENT_TYPE setting is used.
However, I don’t find it elucidating enough. Why we use 2 different naming for (almost the same) thing? Is "Content-Type" just a name used in browser requests, and with very little use outside it?
What’s the main difference between the each one, and when is right to call something mimetype as opposed to content-type ? Am I being petty and a grammar nazi?
Why we use 2 different naming for (almost the same) thing?
Backwards compatibility, based on your quote from the documentation.
Why we use 2 different naming for
(almost the same) thing? Is
“Content-Type” just a name used in
browser requests, and with very little
use outside it?What’s the main difference between the
each one, and when is right to call
something mimetype as opposed to
content-type ? Am i being pitty and
grammar nazi?
The reason isn’t only backward compatibility, and I’m afraid the usually excellent Django documentation is a bit hand-wavy about it. MIME (it’s really worth reading at least the Wikipedia entry) has its origin in extending internet mail, and specifically SMTP. From there, the MIME and MIME-inspired extension design has found its way into a lot of other protocols (such as HTTP here), and is still being used when new kinds of metadata or data need to be transmitted in an existing protocol. There are dozens of RFCs that discuss MIME used for a plethora of purposes.
Specifically, Content-Type: is one among several MIME headers. “Mimetype” does indeed sound obsolete, but a reference to MIME itself isn’t. Call that part backward-compatibility, if you will.
[BTW, this is purely a terminology problem which has nothing whatsoever to do with grammar. Filing every usage question under “grammar” is a pet peeve of mine. Grrrr.]
If you want to know the details see ticket 3526.
Quote:
Added content_type as an alias for
mimetype to the HttpResponse
constructor. It’s a slightly more
accurate name. Based on a patch from
Simon Willison. Fully backwards
compatible.
I’ve always viewed contentType to be a superset of mimeType. The only difference being the optional character set encoding. If the contentType does not include an optional character set encoding then it is identical to a mimeType. Otherwise, the mimeType is the data prior to the character set encoding sequence.
E.G. text/html; charset=UTF-8
text/html is the mimeType
; is the additional parameters indicator
charset=UTF-8 is the character set encoding parameter
E.G. application/msword
application/msword is the mimeType
It cannot have a character set encoding as it describes a well formed octet-stream not comprising characters directly.