HTTP協定（RFC2616）方法定義

 OPTIONS

OPTIONS 方法表示在由 Request-URI 辨別的請求/響應鍊上關于有效通迅選項資訊的請

求。該方法允許用戶端判斷與某個資源相關的選項和/或需求或者伺服器的能力，而不需要

采用資源行為或發起資源擷取。

    該方法的響應不能緩存。

    如果OPTIONS請求包括實體（如由 Content-Length或 Transfer-Encoding的存在表示），

這時媒體類型必須通過 Content-Type 域表示。盡管本規範沒有定義該實體的用法，将來的

HTTP 擴充可能使用 OPTIONS 消息體來更詳細地查詢伺服器的資訊。伺服器不支援該擴充

可以丢棄該請求消息體。

    如果 Request-URI 是星号（“*”），OPTIONS 請求通常試圖應用于伺服器而不是特定的

資源。由于伺服器的通迅選項一般由資源決定，是以“*”請求隻作為“ping”或“no-op”

類型的方法有用；它沒有任何作用，除了允許用戶端測試伺服器的能力。例如，可用來測試

HTTP/1.1 代理的一緻性（或缺少因素）。

    如果 Request-URI不是星号，OPTIONS請求隻應用于與該資源通迅時的有效選項。

     200 響應應該包括任何頭部域來表示伺服器實作和可應用到該資源的可選特性（如

Allow），可能包括該規範沒有定義的擴充。如果有響應消息體，則應該還包括通迅選項的信

息。本規範沒有定義該消息體的格式，但可能在将來擴充 HTTP時定義。内容協商可用于選

擇适當的響應格式。如果不包括響應消息體，則響應必須包括域值為“0”的 Content-Length

域。

     Max-Forwards 請求頭部域可能用于請求鍊中定位特定代理。當代理收到關于允許請求

轉發的absoluteURI的OPTIONS請求時， 代理必須檢查Max-Forwards域。 如果Max-Forwards

域值為0（“0” ），則代理不能轉發該消息；取而代之，代理應該以它自己的通迅選項來響應。

如果 Max-Forwards 域值是大于 0 的整數，代理在轉發該請求時必須将域值減一。如果請求

中不存在 Max-Forwards域，則轉發的請求中不能包括Max-Forwards域。

GET

    GET 方法即擷取由 Request-URI 辨別的任何資訊（以實體的形式）。如果 Request-URI

引用某個資料處理過程，則應該以它産生的資料作為在響應中的實體，而不是該過程的源代

碼文本，除非該過程碰巧輸出該文本。

    如果請求消息包括 If-Modified-Since、If-Unmodified-Since、If-Match、If-None-Match或

者If-Range頭部域，則GET方法的語義變為“條件GET”。條件 GET方法請求隻傳輸在條

件頭部域描述情形下的實體。條件 GET 方法試圖通過允許重新整理緩存的實體而不需要多次請

求或傳輸用戶端已經擁有的資料來減少非必要的網絡使用。 

    如果請求消息包括 Range頭部域，則 GET方法的語義變為“局部 GET”。局部 GET請

求隻需傳輸實體的某部分。

HEAD

    除了伺服器不能在響應中傳回消息體，HEAD 方法與 GET 相同。HEAD 請求的響應中

的 HTTP 頭部中包含的元資訊應該與 GET 請求發送的響應中的資訊相同。該方法可用來獲

取請求暗示實體的元資訊， 而不需要傳輸實體本身。 該方法常用來測試超文本連結的有效性、

可用性和最近的修改。

    當響應中包含的資訊可用于更新先前從該資源緩存的實體時， HEAD 請求的響應可能是

可緩沖的。如果新的域值表明該緩沖的實體與目前實體不同（如可通過 Content-Length、

Content-MD5、ETag或Last-Modified的差別來表示），這時緩沖伺服器必須将該緩存實體作

為過期的。

POST

     POST 方法用來請求原始伺服器接受請求中封裝的實體作為從屬于請求行中的

Request-URI辨別的副屬。POST設計允許完成下列功能的統一方法：

     * 注解存在資源；

     * 上傳消息到論壇、新聞討論區或相似的讨論組；

     * 向資料處理過程提供資料塊，如遞交表單的結果；

     * 通過追加操作來擴充資料庫。

     POST 方法執行的實際功能由伺服器決定，且通常取決于 Request-URI。上傳的實體從

屬于該URI，通過檔案從屬于包含它的目錄，新的論文從屬于它上傳的新聞討論區，或記錄從屬

于資料庫的方式。

     POST 方法執行的行為可能不導緻通過 URI 能夠辨別的某個資源。在這種情況下，200

（OK）或 204（No Content）都是适合的響應狀态。這取決于描述結果的響應是否包括實體。 

    如果原始伺服器建立了資源，響應應該是 201（Created），且包含描述請求狀态的實體，

和新資源的引用，和Location頭部。

    該方法的響應不能緩存，除非響應包括适當的Cache-Control或 Expires頭部域。然而，

303（See Other）響應能夠用來引導使用者代理擷取可緩存的資源。

PUT

     PUT方法請求以提供的Request-URI存儲封裝的實體。如果 Request-URI引用已經存在

的資源，該封裝實體應該被認作原始伺服器存儲的修改版本。如果 Request-URI沒有指向已

存在的資源， 且該URI可以被請求的使用者代理定義為新的資源， 則原始伺服器可以用該 URI

建立資源。如果建立了新的資源，則原始伺服器必須通過 201（Created）響應提示使用者代理。

如果修改了已存在的資源，則應該發送200（OK）或 204（No Content）響應代碼來表示成

功完成了請求。如果不能按 Request-URI建立或修改資源，則應該給出适當的錯誤響應以反

映出問題的性質。實體的接受方不能乎略任何不了解或沒有實作的 Content-*（如

Content-Range）頭部，在這種情況下必須傳回 501（Not Implemented）響應。

    如果請求通過緩沖伺服器且Request-URI辨別出一個或多個緩沖的實體，則應該認為這

些實體過期了。該方法的響應不可緩存。

     POST和PUT請求間的基本差別反映在 Request-URI的不同意義。POST請求中 URI标

識的資源将處理封裝的實體。該資源可能是資料接收過程、其它協定的網關或接受注解的獨

立實體。與此對應，PUT請求中的URI辨別請求封裝的實體——使用者代理知道該 URI是目

标且伺服器不能試圖将該請求應用到其它資源上。 如果伺服器希望該請求應用到不同的 URI

上，則它必須發送301（Moved Permanently）請求；這時客戶代理可以自己決定是否要重定

向該請求。

    可以用許多不同的 URI 辨別同個資源。例如，一篇文章可以有辨別為“目前版本”的

URI，它獨立于辨別每個特别版本的 URI。在這種情況下，使用通用 URI 的 PUT 請求可能

造成原始伺服器定義的一些不同URI的結果。

     HTTP/1.1 沒有定義PUT方法如何影響原始伺服器的狀态。 

    除了其它特殊實體頭部的規定，PUT 請求中的實體頭部應該應用到 PUT 建立或修改的

資源上。

DELETE

     DELETE 方法請求原始伺服器删除Request-URI 辨別的資源。原始伺服器可在人為幹涉

下（或其它意思）屏閉該方法。用戶端不能確定該操作已經送出，即使原始伺服器發出的狀

态碼表明動作已經成功完成也如此。然而，在給出響應的時候，伺服器不應該表示成功，除

非它試圖删除該資源或将它移動到不可通路的位置。

    如果響應包含描述狀态的實體，成功響應應該是200（OK）。如果動作沒有實施，則是

202（Accepted）。如果動作已經實施但響應不包含實體，則是 204（No Content）。

    如果請求通過緩沖伺服器，且Request-URI辨別一個或多個目前緩存的實體，則應該認

為這些實體已經過期。該方法的響應不可緩存。

TRACE

     TRACE 方法用于引起遠端的，該請求消息的應用層回射。請求的最終接收者應該反射

200（OK）響應，并以該消息作為用戶端回收消息的實體。最終接收者是原始伺服器或第一

個收到請求中的Max-Forwards值為0（0）的代理或網關。TRACE 請求不能

包括實體。

     TRACE 允許用戶端看見請求鍊上的另一端收到了什麼，然後使用該資料作為測試或診

斷資訊。Via 頭部域的值有特殊作用，将它作為請求鍊路徑。使用Max-Forwards

頭部域允許用戶端限制請求鍊的長度，這對于測試無限循環轉發消息的代理鍊非常有用。

    如請求有效，則響應應該在實體中包含整個請求消息，設定 Content-Type 為

“message/http” 。該方法的響應不能緩存。

CONNECT

    規範保留 CONNECT 方法名。該方法用于代理，使之能夠動态切換隧道（例如 SSL

隧道）。