|
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 |