HTTP
中文全称为超文本传输协议是一种为分布式，合作式，多媒体信息系统服务，面向应用层的协议。它是一种通用的，不分状态（stateless)的协议，除了诸如名称服务和分布对象管理系统之类的超文本用途外，还可以通过扩展它的请求方式，错误代码和报头来完成许多任务。HTTP的一个特点是数据表示方式的典型性和可协商性允许独立于传输数据而建立系统。
简单地阅读了HTTP/1.1的中文版原文，因为英文版不能理解，其中我印象最深的是它的请求应答机制，真正的体现写这个协议的智慧，用并不太繁杂的规定，去定义一个十分复杂的协议，还包含后来的发展，其包容性都十分完备，兼容性是相比较其他同类协议的最大优点吧，对其一些进行了摘要：
请求URI（Request-URI）
请求URI就是统一资源标识符，用来标识要请求的资源。
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进行解码。
回应（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"类型，在这种情况下，不可能产生完整的回应。
