GET

     GET方法意思是獲取被請求URI（Request-URI）指定的信息（以實(shí)體的格式）。如果請求
URI涉及到一個(gè)數(shù)據(jù)生成過程，那么這個(gè)過程生成的數(shù)據(jù)應(yīng)該被作為實(shí)體在響應(yīng)中返回而不是
過程的源文本，除非源文本恰好是過程的輸出。
     如果請求消息包含 If-Modified-Since,，If-Unmodified-Since，If-Match，If-None-Match 或者
If-Range頭域，GET的語義將變成“條件（conditionall） GET”。一個(gè)條件GET方法會(huì)請求滿
足條件頭域的實(shí)體。條件GET方法的目的是為了減少不必要的網(wǎng)絡(luò)使用，這通過允許利用緩存
里仍然保鮮的實(shí)體而不用多次請求或傳輸客戶端已經(jīng)擁有的實(shí)體來實(shí)現(xiàn)的。.
如果請求方法包含一個(gè)Range頭域，那么GET方法就變成“部分Get”（partial GET）方法。
一個(gè)部分GET會(huì)請求實(shí)體的一部分，這在14.35節(jié)里描述了。 部分GET方法的目的是為了減
少不必要的網(wǎng)絡(luò)使用，可以允許客戶端從服務(wù)器獲取實(shí)體的部分?jǐn)?shù)據(jù)，而不需要獲取客戶端本
地已經(jīng)擁有的部分實(shí)體數(shù)據(jù)。
GET請求的響應(yīng)是可緩存的（cacheable）如果此響應(yīng)滿足第13節(jié)HTTP緩存的要求。
看15.1.3節(jié)關(guān)于GET請求用于表單時(shí)安全考慮。

HEAD

HEAD 方法和GET 方法一致，除了服務(wù)器不能在響應(yīng)里返回消息主體。HEAD請求響應(yīng)里
HTTP頭域里的元信息（譯注：元信息就是頭域信息）應(yīng)該和GET請求響應(yīng)里的元信息一致。
此方法被用來獲取請求實(shí)體的元信息而不需要傳輸實(shí)體主體（entity-body）。此方法經(jīng)常被用
來測試超文本鏈接的有效性，可訪問性，和最近的改變。.
HEAD請求的響應(yīng)是可緩存的，因?yàn)轫憫?yīng)里的信息可能被緩存用于更新以前那個(gè)資源對應(yīng)緩存
的實(shí)體.。如果出現(xiàn)一個(gè)新的域值指明緩存的實(shí)體和當(dāng)前源服務(wù)器上的實(shí)體有所不同（可能因?yàn)?br>Content-Length，Content-MD5，ETag或Last-Modified值的改變），那么緩存（cache）必
須認(rèn)為緩存項(xiàng)是過時(shí)的（stale）。

POST

POST 方法被用于請求源服務(wù)器接受請求中的實(shí)體作為請求資源的一個(gè)新的從屬物。POST被
設(shè)計(jì)涵蓋下面的功能。
--已存在的資源的注釋；
--發(fā)布消息給一個(gè)布告板，新聞組，郵件列表，或者相似的文章組。
--提供一個(gè)數(shù)據(jù)塊，如提交一個(gè)表單給一個(gè)數(shù)據(jù)處理過程。
--通過追加操作來擴(kuò)展數(shù)據(jù)庫。
POST方法的實(shí)際功能是由服務(wù)器決定的，并且經(jīng)常依賴于請求URI（Request-URI）。POST
提交的實(shí)體是請求URI的從屬物，就好像一個(gè)文件從屬于一個(gè)目錄，一篇新聞文章從屬于一個(gè)
新聞組，或者一條記錄從屬于一個(gè)數(shù)據(jù)庫。
POST方法執(zhí)行的動(dòng)作可能不會(huì)對請求URI所指的資源起作用。在這種情況下，200（成功）或
者204（沒有內(nèi)容）將是適合的響應(yīng)狀態(tài)，這依賴于響應(yīng)是否包含一個(gè)描述結(jié)果的實(shí)體。
如果資源被源服務(wù)器創(chuàng)建，響應(yīng)應(yīng)該是201（Created）并且包含一個(gè)實(shí)體，此實(shí)體描述了請
求的狀態(tài)。并且引用了這個(gè)新資源和一個(gè)Location頭域（見14.30節(jié)）。
POST方法的響應(yīng)是不可緩存的。除非響應(yīng)里有合適的Cache-Control或者Expires頭域。然而，
303（見其他）響應(yīng)能被用戶代理利用去獲得可緩存的響應(yīng)。
POST 請求必須遵循8.2節(jié)里指明的消息傳送的要求。
參見15.1.3節(jié)關(guān)于安全性的考慮.

PUT

PUT方法請求服務(wù)器去把請求里的實(shí)體存儲(chǔ)在請求URI（Request-URI）標(biāo)識(shí)下。如果請求
URI（Request-URI）指定的的資源已經(jīng)在源服務(wù)器上存在，那么此請求里的實(shí)體應(yīng)該被當(dāng)作
是源服務(wù)器關(guān)于此URI所指定資源實(shí)體的最新修改版本。如果請求URI（Request-URI）指定
的資源不存在，并且此URI被用戶代理定義為一個(gè)新資源，那么源服務(wù)器就應(yīng)該根據(jù)請求里的
實(shí)體創(chuàng)建一個(gè)此URI所標(biāo)識(shí)下的資源。如果一個(gè)新的資源被創(chuàng)建了，源服務(wù)器必須能向用戶代
理（user agent） 發(fā)送201（已創(chuàng)建）響應(yīng)。如果已存在的資源被改變了，那么源服務(wù)器應(yīng)該
發(fā)送200（Ok）或者204（無內(nèi)容）響應(yīng)。如果資源不能根據(jù)請求URI創(chuàng)建或者改變，一個(gè)合
適的錯(cuò)誤響應(yīng)應(yīng)該給出以反應(yīng)問題的性質(zhì)。實(shí)體的接收者不能忽略任何它不理解和不能實(shí)現(xiàn)的
Content-*（如：Content-Range）頭域，并且必須返回501（沒有被實(shí)現(xiàn)）響應(yīng)。
如果請求穿過一個(gè)緩存（cache），并且此請求URI（Request-URI）指示了一個(gè)或多個(gè)當(dāng)前
緩存的實(shí)體，那么這些實(shí)體應(yīng)該被看作是舊的。PUT方法的響應(yīng)是不可緩存的。
POST方法和PUT方法請求最根本的區(qū)別是請求URI（Request-URI）的含義不同。POST請
求里的URI 指示一個(gè)能處理請求實(shí)體的資源（譯注：此資源可能是一段程序，如jsp 里的
servlet） 。此資源可能是一個(gè)數(shù)據(jù)接收過程，一個(gè)網(wǎng)關(guān)（gateway，譯注：網(wǎng)關(guān)和代理的區(qū)別
是：網(wǎng)關(guān)可以進(jìn)行協(xié)議轉(zhuǎn)換，而代理不能，只是起代理的作用，比如緩存服務(wù)器其實(shí)就是一個(gè)
代理），或者一個(gè)單獨(dú)接收注釋的實(shí)體。對比而言，PUT方法請求里的URI標(biāo)識(shí)請求里封裝的
實(shí)體一一用戶代理知道URI 意指什么，并且服務(wù)器不能把此請求應(yīng)用于其它資源
（resource）。如果服務(wù)器期望請求被應(yīng)用于一個(gè)不同的URI，那么它必須發(fā)送301（永久移
動(dòng)）響應(yīng)；用戶代理可以自己決定是否重定向請求。
一個(gè)單獨(dú)的資源可能會(huì)被許多不同的URI指定。如：一篇文章可能會(huì)有一個(gè)URI指定當(dāng)前版本，
而這個(gè)URI區(qū)別于這篇文章其它特殊版本的URI。這種情況下，對一個(gè)通用URI的PUT請求可
能會(huì)導(dǎo)致其資源的其它URI請求被源服務(wù)器重定義。
HTTP/1.1沒有定義PUT方法對源服務(wù)器的狀態(tài)影響。
PUT請求必須遵循8.2節(jié)中的消息傳送的要求。
除非特別指出，PUT方法請求里的實(shí)體頭域應(yīng)該被用于資源的創(chuàng)建或修改。

DELETE（刪除）

DELETE方法請求源服務(wù)器刪除請求URI指定的資源。此方法可能會(huì)在源服務(wù)器上被人為的干
涉（或通過其他方法）?？蛻舳瞬荒鼙ＷC此操作能被執(zhí)行，即使源服務(wù)器返回成功狀態(tài)碼。然而，
服務(wù)器不應(yīng)該指明成功除非它打算刪除資源或把此資源移到一個(gè)不可訪問的位置。
如果響應(yīng)里包含描述成功的實(shí)體，響應(yīng)應(yīng)該是200（OK）；如果DELETE動(dòng)作還沒有執(zhí)行，
應(yīng)該以202（已接受）響應(yīng)；如果DELETE請求方法已經(jīng)執(zhí)行但響應(yīng)不包含實(shí)體，那么應(yīng)該以
204（無內(nèi)容）響應(yīng)。
如果請求穿過緩存，并且請求URI（Request-URI）指定了一個(gè)或多個(gè)緩存當(dāng)前實(shí)體，那么這
些緩存項(xiàng)應(yīng)該被認(rèn)為是舊的。DELETE方法的響應(yīng)是不能被緩存的。

TRACE

TRACE方法被用于激發(fā)一個(gè)遠(yuǎn)程的，應(yīng)用層的請求消息回路（譯注：TRACE方法讓客戶端測
試到服務(wù)器的網(wǎng)絡(luò)通路，回路的意思如發(fā)送一個(gè)請返回一個(gè)響應(yīng)，這就是一個(gè)請求響應(yīng)回路，）。

最后的接收者也許是源服務(wù)器，也許是接收到包含Max-Forwards頭域值為0請求的代理
或網(wǎng)關(guān)。TRACE請求不能包含一個(gè)實(shí)體。
TRACE方法允許客戶端去了解數(shù)據(jù)被請求鏈的另一端接收的情況，并且利用那些數(shù)據(jù)信息去
測試或診斷。Via頭域值（見14.45）有特殊的用途，因?yàn)樗梢宰鳛檎埱箧湹母櫺畔?。利?br>Max-Forwards頭域允許客戶端限制請求鏈的長度，這是非常有用的，因?yàn)榭梢岳么巳y試代
理鏈在無限循環(huán)里轉(zhuǎn)發(fā)消息。
如果請求是有效的，響應(yīng)應(yīng)該在實(shí)體主體里包含整個(gè)請求消息，并且響應(yīng)應(yīng)該包含一個(gè)
Content-Type頭域值為”message/http”的頭域。此方法的響應(yīng)不能被緩存。

CONNECT（連接）

HTTP1.1 協(xié)議規(guī)范保留了CONNECT方法，此方法是為了能用于能動(dòng)態(tài)切換到隧道的代理