9 方法定义
HTTP/1.1通用方法的定义如下。虽然这个集合可以被扩展，但是并不能保证client和server拥有对扩展的相同定义。
HOST request-header头区必须存在于所有的HTTP/1。1request。
9．1 安全和等幂方法
9.1.1 安全方法
实现者要意识到软件代表了用户在Internet上的操作，应该认真地让用户知道他们可以采取的action会给他们自己和其他带来的影响。
特殊地，按约定GET，HEAD方法除获取资源外不应该有任何其他影响。这些方法应该被认为是安全的。这样处理就允许user agent去表现其他方法如POST，PUT，和DELETE，这样用户就可以意识到一个可能不安全的方法并request。
自然的，不可能保证server对GET方法不产生旁效应；事实上，一些动态资源把它作为一种特性。重要的区别是user并不要求旁效应，所以不必要为他们负责。
9.1.2 等幂方法
方法也可以具有等幂特性，这样的N>0个request的旁效应是一致的。方法GET，HEAD，PUT，DELETE都有这个特性。同样OPTIONS，TRACE SHOULD NOT也有旁效应，也天生等幂。
但是，游客能一个request序列是不等幂的，即使所有的方法单独是等幂的。（一个序列是等幂的当且整个序列的执行的结果和再次执行全部，部分是一样的。）例如，一个序列是不等幂的，如果它的结果依赖一个值，而这个值在这个序列中会被修改的。
一个没有旁效应的序列是等幂的，根据定义。（前提是没有并发的操作会在同一个资源集上被执行）。
9．2 options
用来代表一个request来请求关于request-uri标记的request/response链所对应的可用的通讯选项。这个方法允许client去确定和一个资源或一个server相关的选项或要求，而不用去应用一个资源action或初始化一个资源获取。
对于这个方法的response是不能缓存的。
如果options request 包含一个entity-body，那么media type必须由Content-Type区来指示。虽然这个规范并没有为这样一个body定义任何用处，HTTP的未来扩展可以使用它来向server做更细节的查询。一个并不支持这样一个扩展的server可以丢弃这个request body。
如果Request-URI是一个*，OPTIONS request是用来应用给server而不是给一个特定资源。因为一个server的通讯选项一般依靠于资源，* request和“ping”或“no-op”方法的作用类似；除了测试server的接受力外并不做任何其他事情。例如，这个可以用来测试一个代理对HTTP/1。1的兼容性。
如果Request-URI不是一个*，OPITONS request只是指那些能和那个资源交流的选项上。
一个200 response应该包含任何头区来指示server和那个资源可用的特征，也可能包含没有在这个规范中定义的扩展。Response body也应该包含交流选项的信息。这样一个body的格式并没有在这篇规范里被定义，但是可以在HTTP的未来扩展中被定义。Content negotiation
可以被用来选择合适的response 格式。如果没有response body被包含，response必须包含一个Content-Length=0。
Max-Forwards请求头区可以被用在一个request chain上的一个特殊代理。当一个代理在一个absoluteURI接收到一个request forwarding被允许的OPTONS request，proxy必须检查Max-Forwards值。如果Max-Forwards
值是0，proxy绝不能传递message，应该response自己的通讯选项。如果Max-Forwards是一个大于0的值，proxy必须在它传递request的时候降低该值。如果在request 中没有出现Max-Forwards，那么被传递的request决不能包含一个Max-Forwards区。
9．3 GET
GET方法意思是得到URI标记的信息。如果URI只一个数据处理进程，那么处理后的数据是应该在response的entity中被返回的而不是源文件，除非结果正好是那个处理进程的源文件。
如果包含If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range那么GET方法的寓意就变成了“conditional GET”。一个conditional GET方法请求entity只在描述的条件下才被传输。条件GET方法通过避免传递被client held的数据来允许刷新缓存entity以降低网络的使用。
GET 方法的语义在Range头区被包含在request之后改为“partial GET”。它只要求entity的一部分被传递。它也是通过完成entity而部分传递（例如为了避免传递client已经存在的数据）来降低网络负荷。
GET request的response是可以缓存的当且仅当它满足HTTP缓存的要求（sec13）。
看section 15.1.3当使用表单时考虑安全因素。
9.4 HEAD
HEAD方法等同于GET除了server决不能在一个response中返回一个message-body。而在header包含的元数据信息应该和对GET的相同。这个方法可以被用来得到关于entity的元信息而不用得到entity。这个方法通常被用来测试超链接的有效性，可进入性，和最近的修改。
对一个HEAD request的response可以是可缓存的，这样在response的信息可以被用来更新关于那个资源的先前的缓存entity。如果新的区指示缓存entity和当前的不同那么缓存必须认为这个entity是过时的。
9.5 POST
用来请求origin server来接受在request中包裹的entity作为URI标记资源的下属资源。POST被设计成包含下面的功能：
l 存在资源的直接
l 发布一个消息给一个公告牌，新闻组，邮件列表，或类似的文章组
l 提供一个数据块，想提交一个表单的结果，给一个数据处理进程
l 扩展一个数据库通过一个附加的操作
POST方法实际执行的功能取决于server并且通常依赖于URI。post的entity从属于URI，这就象一个文件从属于一个包含它的目录，一个新闻文章从属于一个被post的新闻组，或一条记录从属于一个数据库。
由post方法得到的结果可能不会得到一个结果。在这种情况下，或者200（OK）或者204（没有内容）作为response的status，这依靠于是否response包含一个描述结果的实体。
如果一个资源已经被origin server创建，response应该是201（Created）并且包含一个entity来描述request的status，并指向新资源和一个Location header（sec14.30）。
对这个方法的Response是不缓存的，除非它包含合适的Cache-Control或Expires。但是，303response可以被使用来引导user agent去得到一个缓存的资源。
Post request必须遵守消息传递要求（sec8.2）。
看sec15.1.3来获得安全考虑。
9.6 PUT
Put方法要求包含的entity在URI之下被存储。如果URI指向一个已经存在的资源，entity应该被认为是一个对已经存在的资源的修改版本。如果URI并没有指向一个已经存在的资源，并且那个URI能够被user agent定义为一个新资源，origin server能够创建那个URI对应的资源。如果一个新资源被创建，origin server必须通知user agent通过201（Created）。如果一个存在资源被修改了，或者200或者204应该被发送来指示request的成功完成。如果resource不能被创建或修改，那么一个合适的错误response应该给出来以反映问题。一个entity的接收者决不能忽略任何它不理解或实现的Content-* (e.g. Content-Range)头区，必须返回一个501response。
如果request通过一个cache，并且URI标记一个或更多个缓存entity，那些entity应该被认为是过时的。Response不缓存。
在POST和PUT请求之间的重要区别是URI的不同含义。在POST request的标记资源将会处理entity。这个资源可能是一个数据接受进程，一个去一些其他协议的网关，或一个接收注解的单独的entity。相比之下，在put request的URI标记entity本身。User agent知道哪个URI适合，而且server决不能试图去应用这个request给一些其他资源。如果server想要request去指一个不同的URI，它必须发送一个301response；user agent可以关于是否重定向request做它自己的决定。
一个单个的资源可以不同的URI标记。例如，一个文件可以有一个URI来标记当前版本，这是从URIFor example, an article might have a URI for identifying “the current version” which is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in several other URIs being defined by the origin server.
HTTP/1。1没有定义一个PUT方法如何影响一个orgin server的状态。
PUT request必须遵守SEC8。2描述的消息传输要求。
除非对一个特定entity-header做特殊标记，在PUT request的entity-header应该被应用到被PUT创建或修改的资源。
9.7 DELETE
DELETE方法请求origin server删除被URI标记的资源。这个方法可以被在origin server上的手工操作冲突。即使返回的状态码标记action被成功完成，client不能保证action被成功完成。但是，server不应该指示成功，除非在response被给出的时候，它试图删除资源或把它移动到一个不可进入的地方。
一个成功的response应该是200，如果response包含一个描述状态的试题，202如果action还没有被actted，或204如果已经act但还没有包含entity。
如果request 经过一个cache并且URI标记1个或多个缓存体，那些entries应该被认为是过时的。 Response不能缓存。
9．8 Trace
Trace方法被用来唤醒一个远端的应用层的request message的转回来。最后一个request的接收者要把request作为200response的entity返回给client。最后的接收者可能是一个server,1st proxy,gateway接收到了Max-Forwards=0的request。一个Trace request 绝对不能包含一个entity。
Trace允许client去看到在request chain的另一端什么被接受并使用那些数据来做测试或诊断。Via的使用很有意思，因为它作为chain的trace。使用Max-Forwards可以限制chain长度，这对测试在一个无限循环的proxy chain很有用。
如果一个request是有效的，response应该包含整个的request message在body，Content-Type=“message/http”.不能缓存。
9.9 CONNECT
这个规范保留了CONNECT方法，它原用来让一个proxy动态成为一个tunnel（SSL tunneling [44]).
10 Status Code Definitions
每一个status-Code被在下面描述，包括一个描述关于什么方法可以被反馈，和任何关于response的元数据信息。
10.1 Informational 1xx
这一类状态编码代表一个临时的response，由status-line和一个可选的头部组成，由一个空行结束。对这一类状态代码没有必需的头部。因为HTTP/1。0没有定义任何1xx状态码，server决不能发送一个1xx response给一个HTTP/1。0client除非在实验条件下。
一个client必须准备好在一个常规response前接受1个或多个1xx状态的response，即使client不期待一个100（Continue）状态的message。未被期待的1xx状态的response会被一个user agent忽略。
代理必须传递一个1xx response，除非在proxy和client之间的连接被关闭了，或者除非proxy本身要求产声一个1xxresponse。
10.2 Successful 2xx
这一类状态编码意思是client的request被成功接收，理解，接受。
10.3 Redirection 3xx
这一类状态编码意思是更多的action需要被user agent执行来满足request。可以由user agent在没有用户的操作下进行，前提是在第2个request中的方法是GET或HEAD.一个client应该侦测无限的redirection循环，因为这样的循环对每一个redirection产生网络负载。
注意：先前版本的规范推荐最大5个redirection。内容开发者应该意识到可能有用户实现这样一个固定限制。
10.4 Client Error 4xx
4xx的状态码是被用在client看起来出错的情况下。除了对head request，server应该包含一个entity来包含错误情况，和是否这是一个临时或持久的条件。这些状态码对任何request method都可用。User agents应该对user展现所有包含的entity。
如果client正在发送data，一个使用TCP的server的实现应该仔细保证client认识到包含response的package的接收到在server关闭输入连接前。如果client在close后持续发送数据给server，server的TCP栈会发送一个reset packet给client，这将擦去client发过来的没有接收到的输入缓存在他们被HTTP应用读和解释之前。
10.5 Server Error 5xx
表示server本身意识到它有错或不能执行request。除了对HEAD request,server应该包含一个entity来包含对错误情况的解释，和这是否一个临时或持久的情况。User agent应该表现任何包含的entity给用户。这些response code对任何request 方法都是可用的。
11 Access Authentication
HTTP提供了几个可选的challenge-response认证机制，用来供一个server来要求一个client的request，client来提供认证信息。“HTTP Authentication:Basic and Digest Access Authentication” [43]定义了通用的进入认证框架和基本的以及摘要的认证。这个规范吸收了“challenge” 和“credentials”的概念。