最近没有更新是因为，时间比较紧张，另外，这几章比较繁琐，还是硬着头皮上吧，不然，老放在心里面，不踏实，而这几张是非常重要的几张，包括：方法、状态码、cache。
9. 方法定义
9.1.1 安全方法
在我们实现这些方法的时候，应该明白，浏览器（客户端）是代表用户在互联网上进行交互的，并且应该小心让用户明白自己的行为能够给自己或是别人带来不可预知的意义。
部分的，本协议已经确定了“GET”、“HEAD”方法除了获取资源外，不会带来其他的结果，因此这样的方法被认为是安全的。本协议还允许用户代理（浏览器）以特殊的方式进行诸如“POST”、“PUT”、“DELETE”这些方法，以保证能够让用户意识到这些方法的不安全性。
自然，当用户请求“GET”这种方法的时候，没必要规定服务器必须是无任何改变（副作用）的，实际上有些动态资源是有改变的。那么这个时候，最主要的区别是，用户端没有请求这些改变，因此用户端的内容是不能改变的。
9.1.2 等幂的方法
方法在请求N次和请求1次所产生的副作用一样的时候，我们就说这个方法是等幂的。“GET”、“HEAD”、“PUT”、“DELETE”有这样的特性， 而“OPTION”和“TRACE”不应该具有副作用，因此也是等幂的（内在的？）。
一个序列的请求，有可能不是等幂的，尽管这个序列中的每一个方法都是等幂的。反例：
在这个序列中，有一个请求的返回值依赖于另一个方法的结果，而这个结果是不定的，导致组后出现的结果是，同一个序列的请求，多次请求返回的结果不一致，那么就不是等幂的。当然，如果整个序列的执行结果总是相同的，那么这个序列也就是等幂的了。
因此根据，定义，一个序列，没有副作用，那么这个序列是等幂的。
9.2 OPTIONS方法
OPTIONS表明请求想得到在通过“Request-URI”建立的请求/响应链的可用的通信选项。
这个方法的结果，无法缓存。
如果这个方法带有信息实体，那么必须要在头域的Content-Type中指明媒体的类型，尽管当前，本协议中还没定义如何使用这个实体，当时在将来的扩展协议，会根据这个信息体来在服务器上制造更多的需求，另外，如果服务器不支持这个方法，将丢弃掉OPTION的信息体。
如果，Request-URI是*，OPTIONS将用于服务器，而不是去请求特殊的资源。由于这个方法是决定于资源的，所以这个*在“ping”或是“no-op”请求的时候，才会真正发挥作用，他除了能够测试服务器以外，毫无用途。比如，他可以测试一个代理，是不是支持HTTP/1.1
如果请求的资源，不是*的时候，OPTIONS将用于协议与资源通信的可用选项。
一个200响应，应该包含一个头域，定义了可以用于资源的通信选项，还有可能包含本协议没有提到的其他扩展选项。而信息的主题，应该包含可用的通信选项，尽管当前的协议还未定义这些选项，当时可以用于将来版本的扩展。如果响应信息，不包含主体信息（body），他的Content-Length应该为0.
Max-Forwards请求头域可能会被用于针对请求链中特定的代理。当代理收到一个OPTINONS请求，并且请求的URI为absoluteURI的时候，而且此请求是可以转发的时候，那么此时代理就必须要检测Max-Forwards头域了，如果这个值为0，那么代理不能转发此请求，如果大于0，那么代理应该递减该值（1--）再转发此请求，而如果没有Max-Forwards头域，那么转发的时候不能包含Max-Forwards域。
9.3 GET
GET方法是用于获取URI的信息（以实体信息的格式），如果此资源涉及到数据生成的一个过程，那么获取的数据应该是生成的结果，而不是源数据。
如果请求的方法包含If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range这些头域的话，GET将变成“条件GET”，那么就可以利用缓存，以节省网络开销。
要知道，GET请求的结果，是可以缓存的。
9.4 HEAD
HEAD方法跟GET方法是一样的，唯一的不同是他不需要返回信息实体，他常用于测试链接的有效性，可访问性，以及最近是否更改。HEAD也是可以被缓存的，如果出现一个新域（Content-Length, Content-MD5, ETag or Last-Modified）表明缓存实体与服务器上不一致，那么缓存将过保质期。
9.5 POST方法
POST方法被设计用来请求服务器接收请求中的实体，作为一个附属物，他常用于发布一个公告、新闻组、邮件列表或者相似文章组。POST请求的实际效果是由服务器来决定的，他可能不会对URI的资源起任何改变的作用，这时候200（成功）或204(没有内容)是比较合适的返回。如果请求被创建，将返回201并且包含一个实体，描述了请求的状态。
POST方法是不可缓存的，除非响应里有合适的的Cache-Control或者Expires头域。
9.6 PUT
PUT请求服务器把请求中的实体存储在URI的标识之下。如果此URI已经在服务器上存在，那么此实体，应该当作最新版本。如果请求的URI在服务器上不存在，且此URI被用户定义为一个新的资源，那么应该创建一个新的URI下标识的资源，此时服务器返回给用户201（已创建），如果已经存在的内容版本被更新了（第一种情况），应该发送200（OK）或是204响应。
如果请求穿过一个缓存，并且此请求URI指定一个或多个实体，那么这些实体都被认为是过时的，另外PUT方法是不可缓存的。
PUT和POST的最大区别在于URI，POST中的URI是一个能够处理请求的资源，如一个网关（网关能进行协议转换，而代理不行），而PUT方法里的URI是用于表示请求的实体，并且服务器不能将此请求用于其他的资源，如果期望用于其他资源，必须发送301（永久移动），由用户来决定是否进行一次新的请求。
9.7 DELETE
此方法用于请求服务器删除请求里URI指定的资源，客户不能保证此操作能够成功，尽管返回的是成功的状态，然而，既然服务器返回了成功状态，他就应该有打算删除资源，或是把他移动到一个不可用的位置。
如果返回的结果成功，并包含了成功的实体，那么应该是200（OK），如果还没执行，应该是202（已经接受你的请求），如果方法已经执行，但是不包含实体信息，应该返回204.
9.8 TRACE
此方法用于激发一个远程的应用层的请求信息回路。用于测试到服务器的网络通路。最后的接收者可能是源服务器，也可能是代理（此代理必须是Max-Forwards为0）。TRACE用于客户端了解数据被请求链的另一端的接受情况，并用这些数据去诊断。Via头域，可用于跟踪信息。Max-Forwards可用于限制请求链的长度，此响应不能被缓存。
9.9 CONNECT
此方法暂时保留，用于动态的切刀隧道代理。