4. HTTP 消息（HTTP Message）
4.1 消息类型（Message Types）
HTTP消息由客户端到服务器的请求和由服务器到客户端的回应组成。
HTTP-message = Simple-Request ; HTTP/0.9 messages
| Simple-Response
| Full-Request ; HTTP/1.0 messages
| Full-Response
完整的请求（Full-Request）和完整的回应（Full-Response）都使用RFC822[7]中实体传
输部分规定的消息格式。两者的消息都可能包括标题域（headers，可选）、实体主体（entity
body）。实体主体与标题间通过空行来分隔（即CRLF前没有内容的行）。
Full-Request = Request-Line ; Section 5.1
*( General-Header ; Section 4.3
| Request-Header ; Section 5.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2
Full-Response = Status-Line ; Section 6.1
*( General-Header ; Section 4.3
| Response-Header ; Section 6.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2
简单请求（Simple_Request）与简单回应（Simple-Response）不允许使用任何标题信息，
并限制只能使用唯一的请求方法（GET）
Simple-Request = "GET" SP Request-URI CRLF
Simple-Response = [ Entity-Body ]
不提倡使用简单方式请求格式，因为它防止了服务器在接到简单请求时对返回实体的介
质类型进行验证。
4.2 消息标题（Message Headers）
HTTP标题域，包括主标题（General-Header,4.3节）、请求标题（Request-Header ,5.2节）、
回应标题（Response-Header ,6.2节）及实体标题（Entity-Header,7.1节），都遵照RFC822-3.1
节[7]给出的通用格式定义。每个标题域由后紧跟冒号的名字，单空格（SP），字符及域值组
成。域名是大小写敏感的。虽然不提倡，标题域还是可以扩展成多行使用，只要这些行以一
个以上的SP或HT开头就行。
HTTP-header = field-name ":" [ field-value ] CRLF
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, tspecials, and quoted-string>
标题域接收的顺序并不重要，但良好的习惯是，先发送主标题，然后是请求标题或回应
标题，最后是实体标题。
当且仅当标题域的全部域值都用逗号分隔的列表示时（即，#（值）），多个有相同域名
的HTTP标题域才可以表示在一个消息里。而且必须能在不改变消息语法的前提下，将并发
的域值加到第一个值后面，之间用逗号分隔，最终能将多个标题域结合成“域名：域值”对。
4.3 普通标题域（General Header Fields）
有几种标题域是请求与回应都要使用的，但并不用于被传输的实体。这些标题只用于被
传输的消息。
General-Header = Date ; Section 10.6
| Pragma ; Section 10.12
普通标题域名称只有在与协议版本的变化结合起来后，才能进行可靠的扩展。实际上，
新的或实验中的标题域只要能被通讯各方识别，其语法就可使用，而无法识别的标题域都将
被视为实体域。
5. 请求（Request）
从客户端到服务器端的请求消息包括，消息首行中，对资源的请求方法、资源的标识符
及使用的协议。考虑到局限性更大的HTTP/0.9的向后兼容问题，有两种合法的HTTP请求
格式：
Request = Simple-Request | Full-Request
Simple-Request = "GET" SP Request-URI CRLF
Full-Request = Request-Line ; Section 5.1
*( General-Header ; Section 4.3
| Request-Header ; Section 5.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2
如果HTTP/1.0服务器收到简单请求，它必须回应一个HTTP/0.9格式的简单回应。
HTTP/1.0的客户端有能力接收完整回应，但不能产生简单请求。
5.1 请求队列（Request-Line）
请求队列以一个方法符号开头，跟在请求URI及协议版本的后面，以CRLF为结尾。
该元素用空格SP分隔。除了最后的CRLF，不允许出现单独的CR或LF符。
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
注意，简单请求与完整请求的请求队列之间的区别在于是否有HTTP版本域和是否可以
使用除GET以外的其它方法。
5.1.1 方法（Method）
方法代号指明了将要以何种方式来访问由请求URI指定的资源。方法是大小写敏感的。
Method = "GET" ; Section 8.1
|"HEAD" ; Section 8.2
| "POST" ; Section 8.3
| extension-method
extension-method = token
可以访问指定资源的方法列表是可以动态变化的；如果用某种方法访问资源被拒绝，客
户端可从回应中的返回码得到通知。服务器端在方法无法识别或没有实现时，返回状态代码
501（尚未没实现）。
这些方法被HTTP/1.0的应用程序普遍使用，完整定义请参见第8节。
5.1.2 请求URI（Request-URI）
请求URI就是统一资源标识符（3.2节），用来标识要请求的资源。
Request-URI = absoluteURI | abs_path
上面两种请求URI方式可根据实际的请求方式选择使用。
绝对URI（absoluteURI）格式只在代理（proxy）在产生请求时使用。代理的责任是将
请求向前推送，并将回应返回。如果请求是GET或HEAD方式，而且之前的回应被缓存，
如果代理忽略标题域的过期信息限制，它可能使用缓存中的消息。注意，代理可能将请求推
送至另外一个代理，也可将请求直接送至绝对URI中所指定的目的服务器。为了避免请求
循环，代理必须能够识别它的所有服务器名，包括别名、本地变量及数字形式的IP地址。
下面是一个请求队列的例子：
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.0
最普通的请求URI形式就是原始服务器或网关用来标识资源的方式。在这种方式下，
只有给出绝对路径的URI才能被传输（见3.2.1节）。例如，如客户端希望直接从原始服务
器上接收资源，它们将产生一个与主机"www.w3.org"80端口的TCP连接，并在完整请求之
后发送下面的命令：
GET /pub/WWW/TheProject.html HTTP/1.0
注意绝对路径不可以为空，如果URI中没有内容，也必须加上一个"/"（server root）。
请求URI以编码字符串方式传输，有些字符可能在传输过程中被转义（escape），如变
成“%HEXHEX”形式。具体这方面内容请参见RFC1738[4]。原始服务器在正确解释请求
之前必须对请求URI进行解码。
5.2 请求标题域（Request Header Fields）
请求标题域允许客户端向服务器端传递该请求的附加信息及客户端信息。该域做为请求
的修饰部分，遵照编程语言程序调用参数的语法形式。
Request-Header = Authorization ; Section 10.2
| From ; Section 10.8
| If-Modified-Since ; Section 10.9
| Referer ; Section 10.13
| User-Agent ; Section 10.15
请求标题域名只有在与协议版本的变化结合起来后，才能进行可靠的扩展。实际上，新
的或实验中的标题域只要能被通讯各方识别，其语法就可使用，而无法识别的标题域都将被
视为实体域。
6. 回应（Response）
在接收、解释请求消息后，服务器端返回HTTP回应消息。
Response = Simple-Response | Full-Response
Simple-Response = [ Entity-Body ]
Full-Response = Status-Line ; Section 6.1
*( General-Header ; Section 4.3
| Response-Header ; Section 6.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2
当请求是HTTP/0.9的或者服务器端只支持HTTP/0.9时，只能以Simple-Response方式
回应。如果客户端发送HTTP/1.0完整请求后，接收到的回应不是以状态行（Status-Line）
开头的，客户端将其视为简单回应，并相应对其进行分析。注意，简单请求只包括实体主体，
它在服务器端关闭连接时终止。
6.1 状态行（Status-Line）
完整回应消息的第一行就是状态行，它依次由协议版本、数字形式的状态代码、及相应
的词语文本组成，各元素间以空格（SP）分隔，除了结尾的CRLF外，不允许出现单独的
CR或LF符。
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
状态行总是以协议版本及状态代码开头，如：
"HTTP/" 1*DIGIT "." 1*DIGIT SP 3DIGIT SP
（如，"HTTP/1.0 200"）。
这种表示方式并不足以区分完整请求和简单请求。简单回应可能允许这种表达式出现在
实体主体的开始部分，但会引起消息的误解。因为大多数HTTP/0.9的服务器都只能回
应"text/html"类型，在这种情况下，不可能产生完整的回应。
6.1.1 状态代码和原因分析（Status Code and Reason
Phrase）
状态代码（Status-Code）由3位数字组成，表示请求是否被理解或被满足。原因分析是
用简短的文字来描述状态代码产生的原因。状态代码用来支持自动操作，原因分析是为人类
用户准备的。客户端不需要检查或显示原因分析。
状态代码的第一位数字定义了回应的类别，后面两位数字没有具体分类。首位数字有5
种取值可能：
o 1xx:：保留，将来使用。
o 2xx：成功 － 操作被接收、理解、接受（received, understood, accepted）。
o 3xx：重定向（Redirection）－ 要完成请求必须进行进一步操作。
o 4xx：客户端出错 － 请求有语法错误或无法实现。
o 5xx：服务器端出错 － 服务器无法实现合法的请求。
HTTP/1.0的状态代码、原因解释在下面给出。下面的原因解释只是建议采用，可任意
更改，而不会对协议造成影响。完整的代码定义在第9节。
Status-Code = "200" ; OK
| "201" ; Created
| "202" ; Accepted
| "204" ; No Content
| "301" ; Moved Permanently
| "302" ; Moved Temporarily
| "304" ; Not Modified
| "400" ; Bad Request
| "401" ; Unauthorized
| "403" ; Forbidden
| "404" ; Not Found
| "500" ; Internal Server Error
| "501" ; Not Implemented
| "502" ; Bad Gateway
| "503" ; Service Unavailable
| extension-code
extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>
HTTP状态代码是可扩展的，而只有上述代码才可以被当前全部的应用所识别。HTTP
应用不要求了解全部注册的状态代码，当然，如果了解了更好。实际上，应用程序必须理解
任何一种状态代码，如果碰到不识别的情况，可根据其首位数字来判断其类型并处理。另外，
不要缓存无法识别的回应。
例如，如果客户端收到一个无法识别的状态码431，可以安全地假定是请求出了问题，
可认为回应的状态码就是400。在这种情况下，用户代理应当在回应消息的实体中通知用户，
因为实体中可以包括一些人类可以识别的非正常状态的描述信息。
6.2 回应标题域（Response Header Fields）
回应标题域中包括不能放在状态行中的附加回应信息。该域还可以存放与服务器相关的
信息，以及在对请求URI所指定资源进行访问的下一步信息。
Response-Header = Location ; Section 10.11
| Server ; Section 10.14
| WWW-Authenticate ; Section 10.16
回应标题域名只有在与协议版本的变化结合起来后，才能进行可靠的扩展。实际上，新
的或实验中的标题域只要能被通讯各方识别，其语法就可使用，而无法识别的标题域都将被
视为实体域。