媒体类型

HTTP在Content-Type（3.1.1.5节）和Accept（5.3.2节）头字段中使用网络媒体类型（RFC2046）以提供开放和可扩展的数据类型和类型协商。媒体类型定义了数据格式和如何根据它接受到的数据内容进行处理的各种处理模型。

  1.     media-type = type "/" subtype *( OWS ";" OWS parameter )
  2.     type       = token
  3.     subtype    = token

type/subtype可以以名称=值对的形式跟随参数。

  1.   parameter      = token "=" ( token / quoted-string )

type, subtype, parameter的名称标识符不区分大小写。参数值可能是也可能不是区分大小写的，这取决于参数名的语义。一个参数的存在或者缺失对于一个媒体类型的处理可能是意义重大的，这取决于它在媒体类型注册表中的定义。

与令牌生产器匹配的参数值可以作为令牌或带引号的字符串传送。带引号和不带引号的值是相等的。例如，下面的几个例子是完全等价的，但是从一致性考虑第一个更好：

  1.     text/html;charset=utf-8
  2.     text/html;charset=UTF-8
  3.     Text/HTML;Charset="utf-8"
  4.     text/html; charset="utf-8"

网络媒体类型应该通过BCP13定义的程序以IANA进行注册。

注意：不同于其他头字段的构造，媒体类型参数在等号两边不允许空白（甚至是“坏”空白）

字符集

HTTP使用字符集的名称来识别或协商文本表示形式（RFC6365）的字符编码方案。字符集通过不区分大小写的令牌来识别。

  1.    charset = token

字符集的名称应该通过RFC2978定义的程序注册到IANA“字符集合”注册表中。

规范化和文本默认值

网络媒体类型以规范形式注册以保证不同本地编码格式的系统之间的互操作性。被选择或者通过HTTP被转移的表示应该是规范的形式，出于多用途邮件扩展（MIME，RFC2045）相同的多个原因。然而，电子邮件部署的性能特征（即对对等体的存储和转发消息）与HTTP和Web（基于服务器的信息服务）通用的性能特征明显不同。此外，MIME为了兼容老的邮件转移协议的限制没有用于HTTP（查看附录A）。

MIME的规范形式要求“text”类型的媒体子类型使用CRLF作为文本行中断。HTTP允许使用简单的CR或LF单独传输文本媒体来表示换行符，这种换行符对整个表示是一致的。文本媒体中的行中断由CRLF，CR或LF组成，HTTP发送者可以生成中断，接收者必须能够解析中断。此外，HTTP中的文本媒体不限于分别使用CR和LF的八位字节13和10的字符集。关于换行符的这种灵活性仅适用于已被分配“text”媒体类型的表示内的文本;它不适用于“multipart”类型或者负载体外的HTTP元素（例如，头字段）。

如果一个表示是用内容编码进行编码的，那么底层的数据在编码之前应该是上面定义的一种形式。

多部分类型

MIME提供了一些“multipart”类型，在一个消息里封装一个或多个表示。所有的多部分类型共享一种通用语法，如RFC2046中5.1.1节定义的那样，并且包含了一个边界参数作为媒体类型值的一部分。消息体本身就是一个协议元素；发送者必须只生成CRLF作为两个实体部分之间的行中断。

HTTP消息帧不使用多部分边界作为消息体长度的指示符，虽然它可能被生成或处理负载的实现使用。例如，如[RFC2388]中所述，“multipart / form-data”类型通常用于在请求中携带表单数据，而“multipart / byteranges”类型由本规范定义，用于某些206（部分内容）响应（RFC7233）。

Content-Type

“Content-Type”头字段指明相关表示的媒体类型：消息有效载荷中包含的表示或消息语义确定的选定表示。所指示的媒体类型在解码了由内容编码指示的任何内容编码之后，在所接收的消息语义的范围内定义数据格式以及数据如何由接收者处理。

  1.      Content-Type = media-type

媒体类型被定义在3.1.1.1。字段的一个例子是

  1.   Content-Type: text/html; charset=ISO-8859-4

生成包含负载体的消息的发送者应该在那个消息中生成一个Content-Type头字段，除非封闭表示的预期媒体类型对发送者是未知的。如果没有Content-Type出现，接收者可能假设媒体类型为“application/octet-stream”（RFC2046，4.5.1节）或者检测数据以确定它的类型。

实践中，资源所有者并没有总是适当地配置他们的源服务器来对给定的表示提供正确的Content-Type，这样一些客户端会检测要给负载的内容并且重写为特定类型。这样做的客户有可能得出不正确的结论，这可能会暴露额外的安全风险（例如“特权升级”）。此外，通过检测数据格式不可能确定发送者的意图：许多数据格式匹配仅在处理语义上不同的多种媒体类型。鼓励实施者在使用时禁止这种“内容嗅探”。