9 方法定義
HTTP/1.1通用方法的定義如下。雖然這個集合可以被擴展，但是并不能保證client和server擁有對擴展的相同定義。
HOST request-header頭區(qū)必須存在于所有的HTTP/1。1request。
9．1 安全和等冪方法
9.1.1 安全方法
實現(xiàn)者要意識到軟件代表了用戶在Internet上的操作，應(yīng)該認(rèn)真地讓用戶知道他們可以采取的action會給他們自己和其他帶來的影響。
特殊地，按約定GET，HEAD方法除獲取資源外不應(yīng)該有任何其他影響。這些方法應(yīng)該被認(rèn)為是安全的。這樣處理就允許user agent去表現(xiàn)其他方法如POST，PUT，和DELETE，這樣用戶就可以意識到一個可能不安全的方法并request。
自然的，不可能保證server對GET方法不產(chǎn)生旁效應(yīng)；事實上，一些動態(tài)資源把它作為一種特性。重要的區(qū)別是user并不要求旁效應(yīng)，所以不必要為他們負(fù)責(zé)。
9.1.2 等冪方法
方法也可以具有等冪特性，這樣的N>0個request的旁效應(yīng)是一致的。方法GET，HEAD，PUT，DELETE都有這個特性。同樣OPTIONS，TRACE SHOULD NOT也有旁效應(yīng)，也天生等冪。
但是，游客能一個request序列是不等冪的，即使所有的方法單獨是等冪的。（一個序列是等冪的當(dāng)且整個序列的執(zhí)行的結(jié)果和再次執(zhí)行全部，部分是一樣的。）例如，一個序列是不等冪的，如果它的結(jié)果依賴一個值，而這個值在這個序列中會被修改的。
一個沒有旁效應(yīng)的序列是等冪的，根據(jù)定義。（前提是沒有并發(fā)的操作會在同一個資源集上被執(zhí)行）。
9．2 options
用來代表一個request來請求關(guān)于request-uri標(biāo)記的request/response鏈所對應(yīng)的可用的通訊選項。這個方法允許client去確定和一個資源或一個server相關(guān)的選項或要求，而不用去應(yīng)用一個資源action或初始化一個資源獲取。
對于這個方法的response是不能緩存的。
如果options request 包含一個entity-body，那么media type必須由Content-Type區(qū)來指示。雖然這個規(guī)范并沒有為這樣一個body定義任何用處，HTTP的未來擴展可以使用它來向server做更細(xì)節(jié)的查詢。一個并不支持這樣一個擴展的server可以丟棄這個request body。
如果Request-URI是一個*，OPTIONS request是用來應(yīng)用給server而不是給一個特定資源。因為一個server的通訊選項一般依靠于資源，* request和“ping”或“no-op”方法的作用類似；除了測試server的接受力外并不做任何其他事情。例如，這個可以用來測試一個代理對HTTP/1。1的兼容性。
如果Request-URI不是一個*，OPITONS request只是指那些能和那個資源交流的選項上。
一個200 response應(yīng)該包含任何頭區(qū)來指示server和那個資源可用的特征，也可能包含沒有在這個規(guī)范中定義的擴展。Response body也應(yīng)該包含交流選項的信息。這樣一個body的格式并沒有在這篇規(guī)范里被定義，但是可以在HTTP的未來擴展中被定義。Content negotiation
可以被用來選擇合適的response 格式。如果沒有response body被包含，response必須包含一個Content-Length=0。
Max-Forwards請求頭區(qū)可以被用在一個request chain上的一個特殊代理。當(dāng)一個代理在一個absoluteURI接收到一個request forwarding被允許的OPTONS request，proxy必須檢查Max-Forwards值。如果Max-Forwards
值是0，proxy絕不能傳遞message，應(yīng)該response自己的通訊選項。如果Max-Forwards是一個大于0的值，proxy必須在它傳遞request的時候降低該值。如果在request 中沒有出現(xiàn)Max-Forwards，那么被傳遞的request決不能包含一個Max-Forwards區(qū)。
9．3 GET
GET方法意思是得到URI標(biāo)記的信息。如果URI只一個數(shù)據(jù)處理進程，那么處理后的數(shù)據(jù)是應(yīng)該在response的entity中被返回的而不是源文件，除非結(jié)果正好是那個處理進程的源文件。
如果包含If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range那么GET方法的寓意就變成了“conditional GET”。一個conditional GET方法請求entity只在描述的條件下才被傳輸。條件GET方法通過避免傳遞被client held的數(shù)據(jù)來允許刷新緩存entity以降低網(wǎng)絡(luò)的使用。
GET 方法的語義在Range頭區(qū)被包含在request之后改為“partial GET”。它只要求entity的一部分被傳遞。它也是通過完成entity而部分傳遞（例如為了避免傳遞client已經(jīng)存在的數(shù)據(jù)）來降低網(wǎng)絡(luò)負(fù)荷。
GET request的response是可以緩存的當(dāng)且僅當(dāng)它滿足HTTP緩存的要求（sec13）。
看section 15.1.3當(dāng)使用表單時考慮安全因素。
9.4 HEAD
HEAD方法等同于GET除了server決不能在一個response中返回一個message-body。而在header包含的元數(shù)據(jù)信息應(yīng)該和對GET的相同。這個方法可以被用來得到關(guān)于entity的元信息而不用得到entity。這個方法通常被用來測試超鏈接的有效性，可進入性，和最近的修改。
對一個HEAD request的response可以是可緩存的，這樣在response的信息可以被用來更新關(guān)于那個資源的先前的緩存entity。如果新的區(qū)指示緩存entity和當(dāng)前的不同那么緩存必須認(rèn)為這個entity是過時的。
9.5 POST
用來請求origin server來接受在request中包裹的entity作為URI標(biāo)記資源的下屬資源。POST被設(shè)計成包含下面的功能：
l 存在資源的直接
l 發(fā)布一個消息給一個公告牌，新聞組，郵件列表，或類似的文章組
l 提供一個數(shù)據(jù)塊，想提交一個表單的結(jié)果，給一個數(shù)據(jù)處理進程
l 擴展一個數(shù)據(jù)庫通過一個附加的操作
POST方法實際執(zhí)行的功能取決于server并且通常依賴于URI。post的entity從屬于URI，這就象一個文件從屬于一個包含它的目錄，一個新聞文章從屬于一個被post的新聞組，或一條記錄從屬于一個數(shù)據(jù)庫。
由post方法得到的結(jié)果可能不會得到一個結(jié)果。在這種情況下，或者200（OK）或者204（沒有內(nèi)容）作為response的status，這依靠于是否response包含一個描述結(jié)果的實體。
如果一個資源已經(jīng)被origin server創(chuàng)建，response應(yīng)該是201（Created）并且包含一個entity來描述request的status，并指向新資源和一個Location header（sec14.30）。
對這個方法的Response是不緩存的，除非它包含合適的Cache-Control或Expires。但是，303response可以被使用來引導(dǎo)user agent去得到一個緩存的資源。
Post request必須遵守消息傳遞要求（sec8.2）。
看sec15.1.3來獲得安全考慮。
9.6 PUT
Put方法要求包含的entity在URI之下被存儲。如果URI指向一個已經(jīng)存在的資源，entity應(yīng)該被認(rèn)為是一個對已經(jīng)存在的資源的修改版本。如果URI并沒有指向一個已經(jīng)存在的資源，并且那個URI能夠被user agent定義為一個新資源，origin server能夠創(chuàng)建那個URI對應(yīng)的資源。如果一個新資源被創(chuàng)建，origin server必須通知user agent通過201（Created）。如果一個存在資源被修改了，或者200或者204應(yīng)該被發(fā)送來指示request的成功完成。如果resource不能被創(chuàng)建或修改，那么一個合適的錯誤response應(yīng)該給出來以反映問題。一個entity的接收者決不能忽略任何它不理解或?qū)崿F(xiàn)的Content-* (e.g. Content-Range)頭區(qū)，必須返回一個501response。
如果request通過一個cache，并且URI標(biāo)記一個或更多個緩存entity，那些entity應(yīng)該被認(rèn)為是過時的。Response不緩存。
在POST和PUT請求之間的重要區(qū)別是URI的不同含義。在POST request的標(biāo)記資源將會處理entity。這個資源可能是一個數(shù)據(jù)接受進程，一個去一些其他協(xié)議的網(wǎng)關(guān)，或一個接收注解的單獨的entity。相比之下，在put request的URI標(biāo)記entity本身。User agent知道哪個URI適合，而且server決不能試圖去應(yīng)用這個request給一些其他資源。如果server想要request去指一個不同的URI，它必須發(fā)送一個301response；user agent可以關(guān)于是否重定向request做它自己的決定。
一個單個的資源可以不同的URI標(biāo)記。例如，一個文件可以有一個URI來標(biāo)記當(dāng)前版本，這是從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的狀態(tài)。
PUT request必須遵守SEC8。2描述的消息傳輸要求。
除非對一個特定entity-header做特殊標(biāo)記，在PUT request的entity-header應(yīng)該被應(yīng)用到被PUT創(chuàng)建或修改的資源。
9.7 DELETE
DELETE方法請求origin server刪除被URI標(biāo)記的資源。這個方法可以被在origin server上的手工操作沖突。即使返回的狀態(tài)碼標(biāo)記action被成功完成，client不能保證action被成功完成。但是，server不應(yīng)該指示成功，除非在response被給出的時候，它試圖刪除資源或把它移動到一個不可進入的地方。
一個成功的response應(yīng)該是200，如果response包含一個描述狀態(tài)的試題，202如果action還沒有被actted，或204如果已經(jīng)act但還沒有包含entity。
如果request 經(jīng)過一個cache并且URI標(biāo)記1個或多個緩存體，那些entries應(yīng)該被認(rèn)為是過時的。 Response不能緩存。
9．8 Trace
Trace方法被用來喚醒一個遠(yuǎn)端的應(yīng)用層的request message的轉(zhuǎn)回來。最后一個request的接收者要把request作為200response的entity返回給client。最后的接收者可能是一個server,1st proxy,gateway接收到了Max-Forwards=0的request。一個Trace request 絕對不能包含一個entity。
Trace允許client去看到在request chain的另一端什么被接受并使用那些數(shù)據(jù)來做測試或診斷。Via的使用很有意思，因為它作為chain的trace。使用Max-Forwards可以限制chain長度，這對測試在一個無限循環(huán)的proxy chain很有用。
如果一個request是有效的，response應(yīng)該包含整個的request message在body，Content-Type=“message/http”.不能緩存。
9.9 CONNECT
這個規(guī)范保留了CONNECT方法，它原用來讓一個proxy動態(tài)成為一個tunnel（SSL tunneling [44]).
10 Status Code Definitions
每一個status-Code被在下面描述，包括一個描述關(guān)于什么方法可以被反饋，和任何關(guān)于response的元數(shù)據(jù)信息。
10.1 Informational 1xx
這一類狀態(tài)編碼代表一個臨時的response，由status-line和一個可選的頭部組成，由一個空行結(jié)束。對這一類狀態(tài)代碼沒有必需的頭部。因為HTTP/1。0沒有定義任何1xx狀態(tài)碼，server決不能發(fā)送一個1xx response給一個HTTP/1。0client除非在實驗條件下。
一個client必須準(zhǔn)備好在一個常規(guī)response前接受1個或多個1xx狀態(tài)的response，即使client不期待一個100（Continue）狀態(tài)的message。未被期待的1xx狀態(tài)的response會被一個user agent忽略。
代理必須傳遞一個1xx response，除非在proxy和client之間的連接被關(guān)閉了，或者除非proxy本身要求產(chǎn)聲一個1xxresponse。
10.2 Successful 2xx
這一類狀態(tài)編碼意思是client的request被成功接收，理解，接受。
10.3 Redirection 3xx
這一類狀態(tài)編碼意思是更多的action需要被user agent執(zhí)行來滿足request。可以由user agent在沒有用戶的操作下進行，前提是在第2個request中的方法是GET或HEAD.一個client應(yīng)該偵測無限的redirection循環(huán)，因為這樣的循環(huán)對每一個redirection產(chǎn)生網(wǎng)絡(luò)負(fù)載。
注意：先前版本的規(guī)范推薦最大5個redirection。內(nèi)容開發(fā)者應(yīng)該意識到可能有用戶實現(xiàn)這樣一個固定限制。
10.4 Client Error 4xx
4xx的狀態(tài)碼是被用在client看起來出錯的情況下。除了對head request，server應(yīng)該包含一個entity來包含錯誤情況，和是否這是一個臨時或持久的條件。這些狀態(tài)碼對任何request method都可用。User agents應(yīng)該對user展現(xiàn)所有包含的entity。
如果client正在發(fā)送data，一個使用TCP的server的實現(xiàn)應(yīng)該仔細(xì)保證client認(rèn)識到包含response的package的接收到在server關(guān)閉輸入連接前。如果client在close后持續(xù)發(fā)送數(shù)據(jù)給server，server的TCP棧會發(fā)送一個reset packet給client，這將擦去client發(fā)過來的沒有接收到的輸入緩存在他們被HTTP應(yīng)用讀和解釋之前。
10.5 Server Error 5xx
表示server本身意識到它有錯或不能執(zhí)行request。除了對HEAD request,server應(yīng)該包含一個entity來包含對錯誤情況的解釋，和這是否一個臨時或持久的情況。User agent應(yīng)該表現(xiàn)任何包含的entity給用戶。這些response code對任何request 方法都是可用的。
11 Access Authentication
HTTP提供了幾個可選的challenge-response認(rèn)證機制，用來供一個server來要求一個client的request，client來提供認(rèn)證信息。“HTTP Authentication:Basic and Digest Access Authentication” [43]定義了通用的進入認(rèn)證框架和基本的以及摘要的認(rèn)證。這個規(guī)范吸收了“challenge” 和“credentials”的概念。