http
http是建立在统一资源标识符（URI）[3]提供的地址（URL）[4]和名字（URN）上[20]，以指出方法应用于哪个资源的。消息以类似于一种叫做多用途网络邮件扩展（MIME）[7] 的互联网邮件的格式传送。
HTTP的头域包括通用头，请求头，响应头和实体头四个部分。每个头域由一个域名，冒号（:）和域值三部分组成。域名是大小写无关的，域值前可以添加任何数量的空格符，头域可以被扩展为多行，在每行开始处，使用至少一个空格或制表符。
HTTP/1.1的消息头域值是由LWS或特殊字符分隔的字构成的。
这些特殊字符必须先被包含在引用字符串（quoted string）里之后才能用于参数值（如3.6节定义）里。
token （标记） = 1*<除CTLs与分割符以外的任意 CHAR >
separators（分割符） = "（" | "）" | "<" | ">" | "@"
| "," | ";" | ":" | """ | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
URI 比较
当比较两个URI是否匹配时，客户应该对整个URI比较时应该区分大小写，并且一个字节一个字节的比较。 但下面有些特殊情况：
- 一个为空或未给定的端口等同于URI-refernece（见RFC 2396）里的默认端口;
- 主机（host）名的比较必须不必分大小写;
- 方案（scheme）名的比较必须是不区分大小写的;
- 一个空绝对路径（abs_path）等同于"/"。
除了"保留（reserved）"和"不安全（unsafe）"字符集里的字符（参见RFC 2396 [42]） ，其它字符都等效于它们的"%HEXHEX"编码.
例如,以下三个URI是等同的:
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html
请求资源 （The Resource Identified by a Request）
请求里资源的精确定位是由请求里的Request-URI和Host头域决定的。
１． 如果Request-URI是绝对地址（absoluteURI），这时请求里的主机存在于Request-URI里。任何出现在请求里Host头域值应当被忽略。
２． 假如Request-URI不是绝对地址（absoluteURI），并且请求包括一个Host头域，则主机由该Host头域值决定．
３． 假如由规则１或规则２定义的主机是一个无效的主机，则应当以一个400（错误请求）错误消息返回。
缺少Host头域的HTTP/1.0请求的接收者可能会推测决定什么样的资源被请求（例如：检查URI的路径对于某个特定的主机是唯一的）。
请求队列（Request-Line）
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
请求队列以一个方法符号开头，跟在请求URI及协议版本的后面，以CRLF为结尾。 该元素用空格SP分隔。除了最后的CRLF，不允许出现单独的CR或LF符。
注意，简单请求与完整请求的请求队列之间的区别在于是否有HTTP版本域和是否可以 使用除GET以外的其它方法。
请求URI（Request-URI）
Request-URI = absoluteURI | abs_path
请求URI就是统一资源标识符，用来标识要请求的资源。
绝对URI（absoluteURI）格式只在代理（proxy）在产生请求时使用。
回应（Response）
Response = Simple-Response | Full-Response
在接收、解释请求消息后，服务器端返回HTTP回应消息。
当请求是HTTP/0.9的或者服务器端只支持HTTP/0.9时，只能以Simple-Response方式 回应
状态行（Status-Line）
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
状态代码
状态代码（Status-Code）由3位数字组成，表示请求是否被理解或被满足。
o 1xx:：保留，将来使用。
o 2xx：成功 － 操作被接收、理解、接受（received, understood, accepted）。
o 3xx：重定向（Redirection）－要完成请求必须进行进一步操作。
o 4xx：客户端出错 － 请求有语法错误或无法实现。
o 5xx：服务器端出错 －服务器无法实现合法的请求
消息主体 （Message Body）
请求中消息主体（message-body）的存在是被请求中消息头域中是否存在内容长度（Content-Length）或传输译码（Transfer-Encoding）头域来暗示的。
对于响应消息，消息里是否包含消息主体依赖相应的请求方法和响应状态码。所有HEAD请求方法的请求的响应消息不能包含消息主体，即使实体头域出现在请求里。所有1XX（信息的），204（无内容的）和304（没有修改的）的响应都不能包括一个消息主体（message-body）。所有其他的响应必须包括消息主体，虽然它可能长度为零.
消息的长度（Message Length）
一条消息的传输长度（transfer-length）是消息主体（message-body）的长度，当消息主体出现在消息中时；那就是说在实体主体被应用了传输编码（transfer-coding）后。当消息中出现消息主体时，消息主体的传输长度（transfer-length）由下面（以优先权的顺序）决定：:
1。任何不能包含消息主体（message-body）的消息（这种消息如1xx,204和304响应和任何HEAD请求的响应）总是被头域后的第一个空行（译注:CRLF）终止，不管消息里是否有实体头域（entity-header fields）。
2。如果Transfer-Encoding头域（见14.41节）出现，并且它的域值不是”identity”，那么传输长度（transfer-length）被“块”传输编码定义，除非消息因为关闭连接而被终结了。
3。如果Content-Length头域（属于实体头域）（见14.13节）出现，那么它的十进制值（以字节表示）就代表实体主体长度（entity-length，译注：实体长度其实就是实体主体的长度，以后把entity-length翻译成实体主体的长度）也代表传输长度（transfer-length）。Content-Length头域不能包含在消息中，如果实体主体长度（entity-length）和传输长度（transfer-length）两者不相等（也就是说，消息里应用了传输译码（Transfer-Encoding）头域）。如果一个消息即有传输译码（Transfer-Encoding）头域并且也Content-Length头域，后者会被忽略。
4。如果消息用到媒体类型“multipart/byteranges”，并且传输长度（transfer-length）另外也没有指定，那么这种自我定界的媒体类型定义了传输长度（transfer-length）。这种媒体类型不能被利用除非发送者知道接收者能怎样去解析它； HTTP1.1客户端请求里如果出现Range头域并且带有多个字节范围（byte-range）指示符，这就意味着客户端能解析multipart/byteranges响应。
一个Range请求头域可能会被一个不能理解multipart/byteranges的HTTP1.0代理（proxy）再次转发；在这种情况下，服务器必须能定界此消息利用这节的1,3或5项里定义的方法。
5。通过服务器关闭连接能确定消息的传输长度。（关闭连接并不能用来指明请求消息体的结束，因为这样可以让服务器没有机会继续给予响应）。
为了与HTTP/1.0应用程序兼容，包含HTTP/1.1消息主体的请求必须包括一个有效的内容长度（Content-Length）的头域，除非服务器是和HTTP/1.1遵循的。如果一个请求包含一个消息主体并且没有给出内容长度（Content-Length），那么服务器应该以400响应（错误的请求）如果他不能判断消息长度的话，或者以411响应（要求长度）如果它坚持想要收到一个有效内容长度（Content-length）。
所有的能接收实体的HTTP/1.1应用程序必须能接受"chunked"的传输编码（3.6节），因此可以允许这种机制来处理消息当消息的长度不能被提前决定时。
消息不能同时都包括内容长度（Content-Length）头域和非identity传输编码。如果消息包括了一个非identity的传输编码，内容长度（Content-Length）头域必须被忽略.
当内容长度（Content-Length）头域出现一个具有消息主体（message-body）的消息里，它的域值必须精确匹配消息主体里字节数量。HTTP/1.1用户代理必须通知用户当一个无效的长度接收了。