3.7 Media Types
HTTP uses Internet Media Types in the Content-Type (section 14.18)
and Accept (section 14.1) header fields in order to provide open and
extensible data typing and type negotiation.
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
Parameters may follow the type/subtype in the form of attribute/value
pairs.
Fielding, et. al. Standards Track [Page 25]
RFC 2068 HTTP/1.1 January 1997
parameter = attribute "=" value
attribute = token
value = token | quoted-string
The type, subtype, and parameter attribute names are case-
insensitive. Parameter values may or may not be case-sensitive,
depending on the semantics of the parameter name. Linear white space
(LWS) MUST NOT be used between the type and subtype, nor between an
attribute and its value. User agents that recognize the media-type
MUST process (or arrange to be processed by any external applications
used to process that type/subtype by the user agent) the parameters
for that MIME type as described by that type/subtype definition to
the and inform the user of any problems discovered.
Note: some older HTTP applications do not recognize media type
parameters. When sending data to older HTTP applications,
implementations should only use media type parameters when they are
required by that type/subtype definition.
Media-type values are registered with the Internet Assigned Number
Authority (IANA). The media type registration process is outlined in
RFC 2048 [17]. Use of non-registered media types is discouraged.
3.7.1 Canonicalization and Text Defaults
Internet media types are registered with a canonical form. In
general, an entity-body transferred via HTTP messages MUST be
represented in the appropriate canonical form prior to its
transmission; the exception is "text" types, as defined in the next
paragraph.
When in canonical form, media subtypes of the "text" type use CRLF as
the text line break. HTTP relaxes this requirement and allows the
transport of text media with plain CR or LF alone representing a line
break when it is done consistently for an entire entity-body. HTTP
applications MUST accept CRLF, bare CR, and bare LF as being
representative of a line break in text media received via HTTP. In
addition, if the text is represented in a character set that does not
use octets 13 and 10 for CR and LF respectively, as is the case for
some multi-byte character sets, HTTP allows the use of whatever octet
sequences are defined by that character set to represent the
equivalent of CR and LF for line breaks. This flexibility regarding
line breaks applies only to text media in the entity-body; a bare CR
or LF MUST NOT be substituted for CRLF within any of the HTTP control
structures (such as header fields and multipart boundaries).
If an entity-body is encoded with a Content-Encoding, the underlying
data MUST be in a form defined above prior to being encoded.
Fielding, et. al. Standards Track [Page 26]
RFC 2068 HTTP/1.1 January 1997
The "charset" parameter is used with some media types to define the
character set (section 3.4) of the data. When no explicit charset
parameter is provided by the sender, media subtypes of the "text"
type are defined to have a default charset value of "ISO-8859-1" when
received via HTTP. Data in character sets other than "ISO-8859-1" or
its subsets MUST be labeled with an appropriate charset value.
Some HTTP/1.0 software has interpreted a Content-Type header without
charset parameter incorrectly to mean "recipient should guess."
Senders wishing to defeat this behavior MAY include a charset
parameter even when the charset is ISO-8859-1 and SHOULD do so when
it is known that it will not confuse the recipient.
Unfortunately, some older HTTP/1.0 clients did not deal properly with
an explicit charset parameter. HTTP/1.1 recipients MUST respect the
charset label provided by the sender; and those user agents that have
a provision to "guess" a charset MUST use the charset from the
content-type field if they support that charset, rather than the
recipient's preference, when initially displaying a document.