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