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?？梢杂?/SPAN>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”的概念。