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設計允許完成下列功能的統一方法：
http://www.devdao.com/
注解存在資源；
上傳消息到論壇、新聞組或相似的討論組；
向數據處理過程提供數據塊，如遞交表單的結果；
通過追加操作來擴展數據庫。
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隧道)。