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./pub/WWW/TheProject.html HTTP/1.0
最普通的请求URI形式就是原始服务器或网关用来标识资源的方式。在这种方式下，
只有给出绝对路径的URI才能被传输（见3.2.1节）。例如，如客户端希望直接从原始服务
器上接收资源，它们将产生一个与主机"www."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
请求标题域名只有在与协议版本的变化结合起来后，才能进行可靠的扩展。实际上，新
的或实验中的标题域只要能被通讯各方识别，其语法就可使用，而无法识别的标题域都将被
视为实体域。
