Http Message结构学习总结

最近做的东西需要更深入地了解Http协议，故死磕了一下RFC2616－HTTP/1.1协议，主要是了解Http Message结构及每部分含义，在此总结一下，写一个模拟发送HTTP请求的工具，由于时间有限，工具写得比较烂，使用也不怎么人性化:<，这些缺点以后再慢慢修改吧，HttpSender下载。

（注：下面如“(14.1)”表示是在RFC2616第14章第1节有更详细的介绍）

一.Http Message结构

    了解Http Message先看下图：

Http Message包含3个部分：

(1).请求行/状态行

(2).消息头（Message Header），分为4类：常规头，请求头，响应头和实体头，下面会详细介绍，一个Message里可以有多个消息头。

(3).消息体（Message Body），这个是可选的。

二.Http Message分两类：

1.请求消息（Request Message）

Request Message结构如下：

(1).请求行（Request-Line）结构(5.1)：

Http方法（Http Method）：主要有8类：GET,POST......下面会介绍。

Request-URI：请求操作的资源。

Http-Version：Http的版本，如：Http/1.0，Http/1.1

(2).消息头：

请求消息（Request Message）不应包含响应头。

2.响应消息（Response Message）

Response Message结构如下：

(1).状态行（Status-Line）结构：

Http-Version：Http的版本，如：Http/1.0，Http/1.1

Status-Code（状态码）：状态码是一个三位数字，我对状态码的理解是：对请求(request)做出响应的类型/结果。

状态码第一位数字定义了响应类型，这里分为5种：

-1XX：Informational，请求接收到了，正在进一步的处理中（Request received, continuing process）。

-2XX：Success，表示用户请求被正确接收（The action was successfully received,understood, and accepted），这里典型的是：200 OK

-3XX：Redirection，表示请求没有成功，客户必须采取进一步的动作 (Further action must be taken in order to complete the request.)

-4XX：Client Error，表示客户端提交的请求有错误（The request contains bad syntax or cannot be fulfilled），典型的有：404 Not Found

-5XX：Server Error，表示服务器不能完成对请求的处理 (The server failed to fulfill an apparently valid request)，典型的是：503 Service Unavailable

（注：详细的状态码会在文章的最后列出）

(2).消息头：

响应消息（Response Message）不应包含请求头。

三.Http消息头包括4类：

Http消息头（Message Header），主要是带上一些处理HTTP消息所需的辅助信息。

Http消息头结构如下：

1.Field-Name：下面提到的，如：Cache-Control，Date...等，这些就是Field-Name，在RFC文档中Field-Name的数量是有限的，只有43个，而你自己可以增加自定义的Field-Name，但由于浏览器是按照RFC规范实施的（当然它们也有它们自定义的消息头），所以除非是自己实现服务器和客户端，否则，自定义的Field-Name一般没用。

2.Field-Vlaue：根据Field-Name的不同，会有不同的Field-Value

1.常规头（4.5节）

常规头（generl-header）：request和response都有可能会用到的，但和消息体无关的一些附加信息。

  (1).Cache-Control（14.9）

  (2).Connection（14.10）

  (3).Date（14.18）

  (4).Pragma（14.32）

  (5).Trailer（14.40）

  (6).Transfer-Encoding（14.41）

  (7).Upgrade（14.42）

  (8).Via（14.45）

  (9).Warning（14.46）

2.请求头（5.3节）

请求头（request-header）：一些关于客户端/request的附加信息。

  (1).Accept（14.1）

  (2).Accept-Charset（14.2）

  (3).Accept-Encoding（14.3）

  (4).Accept-Language（14.4）

  (5).Authorization（14.8）

  (6).Expect（14.20）

  (7).From（14.22）

  (8).Host（14.23）

  (9).If-Match（14.24）

  (10).If-Modified-Since（14.25）

  (11).If-None-Match（14.26）

  (12).If-Range（14.27）

  (13).If-Unmodified-Since（14.28）

  (14).Max-Forwards（14.31）

  (15).Proxy-Authorization（14.34）

  (16).Range（14.35）

  (17).Referer（14.36）

  (18).TE（14.39）

  (19).User-Agent（14.43）

3.响应头（6.2节）

响应头（response header）：一些关于响应（response）的附加信息。

  (1).Accept-Ranges（14.5）

  (2).Age（14.6）

  (3).ETag（14.19）

  (4).Location（14.30）

  (5).Proxy-Authenticate（14.33）

4.实体头（7.1节）

实体头（entity-header）：和消息体有关的附加信息。

  (1).Allow（14.7）

  (2).Content-Encoding（14.11）

  (3).Content-Language（14.12）

  (4).Content-Length（14.13）

  (5).Content-Location（14.14）

  (6).Content-MD5（14.15）

  (7).Content-Range（14.16）

  (8).Content-Type（14.17）

  (9).Expires（14.21）

  (11).Last-Modified（14.29）

  (12).extension-header

看到这里你可能会很奇怪，为什么会没有Cookie，Content-Disposition这种常见的信息头？！这里我说一下，Content-Disposition不是HTTP标准的一部分，但它在其他RFC文档中定义了（RFC1806）。而Cookie呢？首先看看Cookie是用来干嘛的：Cookie和Session是为了解决Http协议中无状态的问题，由于Http的设计者们时就没打算让Http有状态这种特性，故Cookie这种东西是肯定不可能是Http标准中的一部分。其实，它们都属于上面所说的：extension-header。其实各种浏览器都有它们自定义的扩展头，特别是IE！

四.Http/1.1方法（9节）：

1.OPTIONS：简单说它的作用是查询信息，例如：查询服务器的能力(能干些什么)/查询操作该资源需要一些什么......当然，你可以不查询，直接操作资源/向服务器发送请求，如果服务器直接，它会告诉你成功/失败，如果服务器不支持，它也会告诉你不支持，但这样效率比较低，因为你操作了资源/你需要初始化资源，而OPTIONS不会执行这些操作，它仅仅是询问，当你不知道能否对资源执行此操作时，可以使用OPTIONS提高效率。

2.GET：请求资源（详细参考《浅谈HTTP中Get与Post的区别》）

3.HEAD：主要是获取服务器响应的头信息，它的响应消息(response message)没有消息体(message body)，只有消息头(message headers)，作用是获取服务器的一些信息，如：Cache-Control等，以给客户端足够的信息决定接下来该如何去做。

4.POST：更新资料（详细参考《浅谈HTTP中Get与Post的区别》）

5.PUT：如果请求的URI是已经存在的资源，则PUT请求所附的实体应被当作修改服务器中的资源，成功的话返回200或者204。如果请求的URI资源不存在，则URI可以被定义成新的资源，这时，服务器必须通过201（建立）响应通知用户。

POST和PUT不同点在反映在对request-URI的不同意义。使用POST方法时，URI资源会处理POST所提交的数据，这时的URI资源可以看作是接收并处理数据的程序。而使用PUT方法时，请求(request)中的实体数据会被认为是URI资源，而服务器不会试图用其他资源去接收这个请求。

6.DELETE：要求服务器释放请求(request)中URI所指向的资源。在服务器上，DELETE方法可能会被强行制止，所以客户端不能担保操作已经实现，即使服务器返回的状态码说明操作已经成功完成了（当然，如果服务器返回了成功，说明服务器已经打算去删除/移动需要被删除的资源了）。

7.TRACE：TRACE 方法用于引起远程的，该请求消息的应用层回射。请求的最终接收者应该反射200（OK）响应，并以该消息作为客户端回收消息的实体。最终接收者是原始服务器或第一个收到请求中的Max-Forwards值为0（0）的代理或网关。TRACE请求(注意是请求不是响应)不能包括实体。以上是RFC文档的解释，或许你没看明白上面到底想说什么，但只要你知道它的作用，你大概也能猜到了:>，TRACE作用是：允许客户端看见请求链上的另一端收到了什么，然后使用该数据作为测试或诊断信息。就是说响应请求(response)的实体里包含了服务器/网关接收到的数据，而其中消息头Via的值有特殊作用，将它作为请求链路径。使用Max-Forwards头部域允许客户端限制请求链的长度，这对于测试无限循环转发消息的代理链非常有用。

8.CONNECT：规范保留 CONNECT 方法名。该方法用于代理，使之能够动态切换隧道（例如 SSL隧道）。

9.extension-method

    先写这么多，本想再写写每类消息头的中Field-Name具体含义，但罗马非一天建成，日后再继续吧:<~~本文如有错漏，请各位指出，谢谢。

转载请说明出处，谢谢![hyddd(http://www.cnblogs.com/hyddd/)]

五.参考文献

[1].RCF2616

六.附录(状态码)

"100"（10.1.1）Continue
"101"（10.1.2）Switching Protocols
"200"（10.2.1）OK
"201"（10.2.2）Created
"202"（10.2.3）Accepted
"203"（10.2.4）Non-Authoritative Information
"204"（10.2.5）No Content
"205"（10.2.6）Reset Content
"206"（10.2.7）Partial Content
"300"（10.3.1）Multiple Choices
"301"（10.3.2）Moved Permanently
"302"（10.3.3）Found
"303"（10.3.4）See Other
"304"（10.3.5）Not Modified
"305"（10.3.6）Use Proxy
"307"（10.3.8）Temporary Redirect
"400"（10.4.1）Bad Request
"401"（10.4.2）Unauthorized
"402"（10.4.3）Payment Required
"403"（10.4.4）Forbidden
"404"（10.4.5）Not Found
"405"（10.4.6）Method Not Allowed
"406"（10.4.7）Not Acceptable
"407"（10.4.8）Proxy Authentication Required
"408"（10.4.9）Request Time-out
"409"（10.4.10）Conflict
"410"（10.4.11）Gone
"411"（10.4.12）Length Required
"412"（10.4.13）Precondition Failed
"413"（10.4.14）Request Entity Too Large
"414"（10.4.15）Request-URI Too Large
"415"（10.4.16）Unsupported Media Type
"416"（10.4.17）Requested range not satisfiable
"417"（10.4.18）Expectation Failed
"500"（10.5.1）Internal Server Error
"501"（10.5.2）Not Implemented
"502"（10.5.3）Bad Gateway
"503"（10.5.4）Service Unavailable
"504"（10.5.5）Gateway Time-out
"505"（10.5.6）HTTP Version not supported