|
GET
GET方法意思是獲取被請求URI（Request-URI）指定的信息（以實體的格式）。如果請求
URI涉及到一個數(shù)據(jù)生成過程，那么這個過程生成的數(shù)據(jù)應該被作為實體在響應中返回而不是
過程的源文本，除非源文本恰好是過程的輸出。
如果請求消息包含 If-Modified-Since,，If-Unmodified-Since，If-Match，If-None-Match 或者
If-Range頭域，GET的語義將變成“條件（conditionall） GET”。一個條件GET方法會請求滿
足條件頭域的實體。條件GET方法的目的是為了減少不必要的網(wǎng)絡(luò)使用，這通過允許利用緩存
里仍然保鮮的實體而不用多次請求或傳輸客戶端已經(jīng)擁有的實體來實現(xiàn)的。.
如果請求方法包含一個Range頭域，那么GET方法就變成“部分Get”（partial GET）方法。
一個部分GET會請求實體的一部分，這在14.35節(jié)里描述了。 部分GET方法的目的是為了減
少不必要的網(wǎng)絡(luò)使用，可以允許客戶端從服務器獲取實體的部分數(shù)據(jù)，而不需要獲取客戶端本
地已經(jīng)擁有的部分實體數(shù)據(jù)。
GET請求的響應是可緩存的（cacheable）如果此響應滿足第13節(jié)HTTP緩存的要求。
看15.1.3節(jié)關(guān)于GET請求用于表單時安全考慮。
HEAD
HEAD 方法和GET 方法一致，除了服務器不能在響應里返回消息主體。HEAD請求響應里
HTTP頭域里的元信息（譯注：元信息就是頭域信息）應該和GET請求響應里的元信息一致。
此方法被用來獲取請求實體的元信息而不需要傳輸實體主體（entity-body）。此方法經(jīng)常被用
來測試超文本鏈接的有效性，可訪問性，和最近的改變。.
HEAD請求的響應是可緩存的，因為響應里的信息可能被緩存用于更新以前那個資源對應緩存
的實體.。如果出現(xiàn)一個新的域值指明緩存的實體和當前源服務器上的實體有所不同（可能因為
Content-Length，Content-MD5，ETag或Last-Modified值的改變），那么緩存（cache）必
須認為緩存項是過時的（stale）。
POST
POST 方法被用于請求源服務器接受請求中的實體作為請求資源的一個新的從屬物。POST被
設(shè)計涵蓋下面的功能。
--已存在的資源的注釋；
--發(fā)布消息給一個布告板，新聞組，郵件列表，或者相似的文章組。
--提供一個數(shù)據(jù)塊，如提交一個表單給一個數(shù)據(jù)處理過程。
--通過追加操作來擴展數(shù)據(jù)庫。
POST方法的實際功能是由服務器決定的，并且經(jīng)常依賴于請求URI（Request-URI）。POST
提交的實體是請求URI的從屬物，就好像一個文件從屬于一個目錄，一篇新聞文章從屬于一個
新聞組，或者一條記錄從屬于一個數(shù)據(jù)庫。
POST方法執(zhí)行的動作可能不會對請求URI所指的資源起作用。在這種情況下，200（成功）或
者204（沒有內(nèi)容）將是適合的響應狀態(tài)，這依賴于響應是否包含一個描述結(jié)果的實體。
如果資源被源服務器創(chuàng)建，響應應該是201（Created）并且包含一個實體，此實體描述了請
求的狀態(tài)。并且引用了這個新資源和一個Location頭域（見14.30節(jié)）。
POST方法的響應是不可緩存的。除非響應里有合適的Cache-Control或者Expires頭域。然而，
303（見其他）響應能被用戶代理利用去獲得可緩存的響應。
POST 請求必須遵循8.2節(jié)里指明的消息傳送的要求。
參見15.1.3節(jié)關(guān)于安全性的考慮.
PUT
PUT方法請求服務器去把請求里的實體存儲在請求URI（Request-URI）標識下。如果請求
URI（Request-URI）指定的的資源已經(jīng)在源服務器上存在，那么此請求里的實體應該被當作
是源服務器關(guān)于此URI所指定資源實體的最新修改版本。如果請求URI（Request-URI）指定
的資源不存在，并且此URI被用戶代理定義為一個新資源，那么源服務器就應該根據(jù)請求里的
實體創(chuàng)建一個此URI所標識下的資源。如果一個新的資源被創(chuàng)建了，源服務器必須能向用戶代
理（user agent） 發(fā)送201（已創(chuàng)建）響應。如果已存在的資源被改變了，那么源服務器應該
發(fā)送200（Ok）或者204（無內(nèi)容）響應。如果資源不能根據(jù)請求URI創(chuàng)建或者改變，一個合
適的錯誤響應應該給出以反應問題的性質(zhì)。實體的接收者不能忽略任何它不理解和不能實現(xiàn)的
Content-*（如：Content-Range）頭域，并且必須返回501（沒有被實現(xiàn)）響應。
如果請求穿過一個緩存（cache），并且此請求URI（Request-URI）指示了一個或多個當前
緩存的實體，那么這些實體應該被看作是舊的。PUT方法的響應是不可緩存的。
POST方法和PUT方法請求最根本的區(qū)別是請求URI（Request-URI）的含義不同。POST請
求里的URI 指示一個能處理請求實體的資源（譯注：此資源可能是一段程序，如jsp 里的
servlet） 。此資源可能是一個數(shù)據(jù)接收過程，一個網(wǎng)關(guān)（gateway，譯注：網(wǎng)關(guān)和代理的區(qū)別
是：網(wǎng)關(guān)可以進行協(xié)議轉(zhuǎn)換，而代理不能，只是起代理的作用，比如緩存服務器其實就是一個
代理），或者一個單獨接收注釋的實體。對比而言，PUT方法請求里的URI標識請求里封裝的
實體一一用戶代理知道URI 意指什么，并且服務器不能把此請求應用于其它資源
（resource）。如果服務器期望請求被應用于一個不同的URI，那么它必須發(fā)送301（永久移
動）響應；用戶代理可以自己決定是否重定向請求。
一個單獨的資源可能會被許多不同的URI指定。如：一篇文章可能會有一個URI指定當前版本，
而這個URI區(qū)別于這篇文章其它特殊版本的URI。這種情況下，對一個通用URI的PUT請求可
能會導致其資源的其它URI請求被源服務器重定義。
HTTP/1.1沒有定義PUT方法對源服務器的狀態(tài)影響。
PUT請求必須遵循8.2節(jié)中的消息傳送的要求。
除非特別指出，PUT方法請求里的實體頭域應該被用于資源的創(chuàng)建或修改。
DELETE（刪除）
DELETE方法請求源服務器刪除請求URI指定的資源。此方法可能會在源服務器上被人為的干
涉（或通過其他方法）?？蛻舳瞬荒鼙ＷC此操作能被執(zhí)行，即使源服務器返回成功狀態(tài)碼。然而，
服務器不應該指明成功除非它打算刪除資源或把此資源移到一個不可訪問的位置。
如果響應里包含描述成功的實體，響應應該是200（OK）；如果DELETE動作還沒有執(zhí)行，
應該以202（已接受）響應；如果DELETE請求方法已經(jīng)執(zhí)行但響應不包含實體，那么應該以
204（無內(nèi)容）響應。
如果請求穿過緩存，并且請求URI（Request-URI）指定了一個或多個緩存當前實體，那么這
些緩存項應該被認為是舊的。DELETE方法的響應是不能被緩存的。
TRACE
TRACE方法被用于激發(fā)一個遠程的，應用層的請求消息回路（譯注：TRACE方法讓客戶端測
試到服務器的網(wǎng)絡(luò)通路，回路的意思如發(fā)送一個請返回一個響應，這就是一個請求響應回路，）。
最后的接收者也許是源服務器，也許是接收到包含Max-Forwards頭域值為0請求的代理
或網(wǎng)關(guān)。TRACE請求不能包含一個實體。
TRACE方法允許客戶端去了解數(shù)據(jù)被請求鏈的另一端接收的情況，并且利用那些數(shù)據(jù)信息去
測試或診斷。Via頭域值（見14.45）有特殊的用途，因為它可以作為請求鏈的跟蹤信息。利用
Max-Forwards頭域允許客戶端限制請求鏈的長度，這是非常有用的，因為可以利用此去測試代
理鏈在無限循環(huán)里轉(zhuǎn)發(fā)消息。
如果請求是有效的，響應應該在實體主體里包含整個請求消息，并且響應應該包含一個
Content-Type頭域值為”message/http”的頭域。此方法的響應不能被緩存。
CONNECT（連接）
HTTP1.1 協(xié)議規(guī)范保留了CONNECT方法，此方法是為了能用于能動態(tài)切換到隧道的代理
|
