HTTP/1.1 协议 4-7

4 HTTP 消息

4.1 消息类型

HTTP消息由客户端到服务端的请求和服务端到客户端的响应组成。

HTTP-message = Request | Response ; HTTP/1.1 messages

请求和响应信息使用RFC 822 [9]中的通用消息格式来传输实体（消息有效载荷）。两种消息都有一个开始行、零或多个报头域（也被成为报头headers）、一个指定报头域结束的空行以及一个可能的消息主体。

generic-message = start-line

*(message-header CRLF)

CRLF

[ message-body ]

start-line = Request-Line | Status-Line

为了保持鲁棒性，服务段在获取请求行（Request-Line）时应该（SHOULD）忽略接收到的空行，换句话说，如果服务正在信息开始时读取协议流，那么它应该忽略最先接收到的CRLF。一些有缺陷的HTTP/1.0客户端实现会在POST请求之后产生额外的CRLF。需要重复一下，BNF所明确禁止的是，HTTP/1.1绝对不能（MUST NOT）在请求的前后有额外的CRLF。

 

4.2消息报头（ Message Headers）

HTTP报头域包括e general-header (section 4.5), request-header (section 5.3), response-header

(section 6.2)和entity-header (section 7.1)等域，都遵循RFC 822 [9]3.1章所给出的通用格式。每个报头域有一个名字和一个紧随其后的“:”以及域值组成。域名字不区分大小写。域值可以（MAY）以任意数目的LWS开头，不过最好是一个SP。报头域可以通过在行开头追加至少一个SP或者HT的方式来扩展成多行。应用程序在生成HTTP结构时应该遵从那些熟知的或者指定的“通用形式”，因为可能已经有许多实现可能无法处理超出通用形式的结构。

message-header = field-name ":" [ field-value ]

field-name = token

field-value = *( field-content | LWS )

field-content = <the OCTETs making up the field-value

and consisting of either *TEXT or combinations

of token, separators, and quoted-string>

field-content 不包括开头和结尾LWS：出现在域值非空格字符前后的空白。这些开头或结尾的LWS可以在不改变域值语义的前提下删除。任何出现在field-content之间的LWS可以在解释区值或转向消息流前替换为一个SP。不同域名的报头域的次序并不重要。但是，最好首先发送通用报头域，其次发送请求报头域或者响应报头域，最后发送实体报头域。

只有对应报头域的全部域值被定义为一个逗号分隔的列表时，相同域名的多个消息报头域肯能会出现在一个消息里[例如 #(values)]。必须可能把多个报头域合并成“field-name: field-valu”对而不改变语义，通过向第一个field-value追加后续的值，这些值由一个“,”来间隔。

由于需要解释组合的域值，所接收的同一域名的报头域的次序是重要的，同样的原因代理不能更改消息投递时域值的顺序。

4.3 消息体（Message Body）

HTTP信息的消息体（如果有）是用来传送请求或响应的实体主体。消息体与实体主体的唯一区别在于是否进行传输编码，编码由传输编码（Transfer-Encoding）域来指定（14.41章）。.

message-body = entity-body

| <entity-body encoded as per Transfer-Encoding>

传输编码必须（MUST）用来指定一些传输编码来由应用程序来确保消息安全与恰当的传输。传输编码是消息而不是实体的属性，因此它可以(MAY)被请求／响应链里的应用增加或者删除。。（但是，3.6章对何时使用什么样的传输编码做出了限制）。

消息里是否有消息体的规则对请求和响应是不同的。

请求的消息头里的Content-Length或者Transfer-Encoding报头域决定了在请求里是否存在消息体。如果文档规定了请求方法不能发送实体主体，那么请求中就不能有消息体。服务端应该对所有消息读取和传递消息体；如果请求方法中不包括对实体主体的定义，处理请求时应该忽略消息体。

对响应消息而言，消息是否有消息体取决于请求方法和响应状态嘛（ 6.1.1 章）。HEAD请求方法的响应不能有消息体，尽管会有实体报头域来表明已经处理过了。所有1xx（报告），204（无内容）和304（无修改）响应不能包含消息体。其他的所有响应需要包含消息体，不过可以是零长度的。

4.4 消息长度（Message Length）

消息的传输长度是指消息体出现在消息里的长度；换句话说是消息经过传输编码后的长度。如果消息包括消息体，那么主体的长度是由以下条件中的一个决定的（顺序优先）

1.         不包含消息体的响应消息（若1xx，204和304响应以及对HEAD请求的响应）通常在报头域后的第一个空行停止读取，进而忽略出现在消息里的实体报头域。

2.         如果存在传输编码报头（14.41章）域并且报头值不为“identity”，传输长度由传输编码“chunked