4.HTTP消息

4．1消息类型

HTTP消息由客户端发到服务器端的request和相反方向的response组成。

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

Request(sec5)和response(sec6)消息使用RFC822[9]的通用消息格式来传递实体(message的有效负荷)。由一个开始行，0或多个头区(头部)，一个空行(在CRLF前什么也没有)来指示头区结束，和一个可能的body。

generic-message = start-line

*(message-header CRLF)

CRLF

[ message-body ]

start-line = Request-Line | Status-Line

为了保持健壮性，服务器应该在Request-Line被期待的地方忽略任何空行。换句话说，如果服务器在消息的开始读协议流，首先接收了一个CRLF，它应该忽略crlf。

某些臭虫很多的HTTP/1。0client实现产生额外的CRLF在一个POSTrequest后。重申一下在BNF处的禁令，一个HTTP/1。1client绝对不能在一个request的前后加CRLF。

4．2消息头

HTTP头区，包含general-header (section 4.5), request-header (section 5.3), response-header

(section 6.2),和entity-header (section 7.1) fields，遵从通用的格式定义(sec3.1RFC822[9])。每一个头区由一个名字跟着一个：和一个区值组成。区名是大小写不敏感的。区值可以一任何数目的LWS开头，虽然一个SP最好。头区可以扩展成多行，当然需要使用最少一个SP或HT来作为多出行的引导。应用应该遵从都知道的或被指明的通用形式来产生HTTP结构，因为可能出现某些应用无法接受超出通用形式的东西。

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

field-name = token

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

field-content =

and consisting of either *TEXT or combinations

of token, separators, and quoted-string>

field-content并没有包含任何打头的或结尾的LWS：出现在非空格字符前或后。而这样出现的LWS可以在不改变区值语义的情况下被删除掉。任何出现在field-content之间的LWS可以在解释区值或转向消息流前以SP取代之。

不同区名的头区出现顺序不相同也没有关系。但是，最好首先发送通用头区，然后是request或response头区，以entity-header头区结束。

在一个消息中可以出现多头区对应同一个区名，只要对那个头区的头区值是可以用逗号分隔的列表。必须可能把多个头区合并成“name:value”对而不改变语义。顺序是重要的，因为解释需要顺序，而且因此一个proxy绝对不能改变顺序。

4．3消息体

HTTP消息的消息体被用来携带跟随request和response的实体。消息体只在一个传输编码被使用时才和实体不同。

message-body = entity-body

|

当要保证消息被安全和合适传输时需要传输编码，Transfer-Encoding就是用来指示传输编码的。这是消息的一个属性，而不是实体的，因此可以在request/response链中被增加或删除。(但是，sec3.6增加了什么时候可以用这个属性)。

什么情况下确定消息中有一个消息体在request和response不同的。

Request是当包含Content-Length或Transfer-Encoding头区时有消息体。如果一个request的方法定义中不允许一个消息体包含在消息中发送，那么就绝对不能。一个server应该读或传递一个消息中的消息体，而如果request中的方法定义中没有指示消息体，那就应该忽略过去。

对于response，有无则依赖于request的方法和response的状态码(sec6.1.1)。所有对应HEADrequest方法的肯定没有，即使实体头区的存在可能让人相信它存在。所有的1xx,204和304也肯定没有。所有其它的一定有，即使它可能是0长度。

4．4消息长度

消息长度是指在传输编码使用后消息体的长度。当一个消息体被包含在一个消息中时，体长由下面决定(按优先级的顺序)：

1．任何肯定不包含一个消息体的response消息总是在第一个空行处终结，而无论出现在消息中的实体的头区。

2．如果一个Transfer-Encoding头区(sec14.41)被给出而且只有”identity”，那么传输长度是使用“chunked”传输编码，直到连接被关闭消息被终结。

3．如果一个Content-Length头区(sec14.13)被给出，那么它既代表了实体长度也代表了传输长度。如果这两个长度不相等肯定不会有Content-Length。如果一个消息既存在Transfer-Encoding又存在Content-Length，后者被忽略。

4．如果消息使用“multipart/byteranges”做媒体类型，并且transfer-length也没被给出，那么这个自定界的媒体类型定义了传输长度。这个类型如果接收者无法解析它那肯定不能被使用；在一个request中，如果包含一个Range头和若干byte-range说明那个client能够解析multipart/ranges。一个rang头可能被一个不理解multipart/byteranges的proxy传递，在这种情况下，server必须使用1，3，5提供的方法定界。

5．到server关闭一个连接(关闭连接不能被用来指示一个request的结束，因为那样将导致server无法发送一个response。)

为了和HTTP/1。0应用兼容，包含一个消息体的。1请求肯定包含一个有效的Content-Length

除非知道server是HTTP/1。1兼容。如果一个request包含一个消息体而没有

Content-Length，那么server如果不能决定消息的长度应该回以400，或411如果它坚持接收一个有效Content-Length。

所有接收实体的HTTP/1。1应用必须接收“chunked”传输编码(sec3.6)，因此允许使用这个机制决定消息长度。

消息绝对不能同时包含Content-Length头区和一个非identity传输编码。如果一定包含，那么Content-Length被忽略。

如果一个Content-Length真被给出了，那它一定对应消息体的字节个数。HTTP/1。1user agent必须告诉用户如果一个无效长度被接受和看到。

4．5通用头区

有一些头区在request和response中通用，但是不能用于被传输的实体。这些头区只用于被传递的消息。

general-header = Cache-Control ; Section 14.9

| Connection ; Section 14.10

| Date ; Section 14.18

| Pragma ; Section 14.32

| Trailer ; Section 14.40

| Transfer-Encoding ; Section 14.41

| Upgrade ; Section 14.42

| Via ; Section 14.45

| Warning ; Section 14.46

通用头区的名字可以跟随一个改变的版本号而被扩展。但是，新的或实验的头区可以被给通用头区的语义如果通讯双方都认同。认不出的头区被认为是实体头区。