HTTP版本

在HTTP的發展過程中，出現了很多HTTP版本，其中的大部分協議都是向下兼容的。在進行HTTP請求時，客戶端在請求時會告訴服務器它采用的協議版本號，而服務器則會在使用相同或者更早的協議版本進行響應。

HTTP/0.9

這是HTTP最早大規模使用的版，現已過時。在這個版本中 只有GET一種請求方法，在HTTP通訊也沒有指定版本號，也不支持請求頭信息。該版本不支持POST等方法，因此客戶端向服務器傳遞信息的能力非常有限。

HTTP/1.0

這個版本是第一個在HTTP通訊中指定版本號的協議版本，HTTP/1.0至今仍被廣泛采用，特別是在代理服務器中。

HTTP/1.0支持：GET、POST、HEAD三種HTTP請求方法。

HTTP/1.1

HTTP/1.1是當前正在使用的版本。該版本默認采用持久連接，并能很好地配合代理服務器工作。還支持以管道方式同時發送多個請求，以便降低線路負載，提高傳輸速度。

HTTP/1.1新增了：OPTIONS、PUT、DELETE、TRACE、CONNECT五種HTTP請求方法。

HTTP/2

這個版本是最新發布的版本，于今年5月（2015年5月）做HTTP標準正式發布。HTTP/2通過支持請求與相應的多路重用來減少延遲，通過壓縮HTTP頭字段將協議開銷降到最低，同時增加了對請求優先級和服務器端推送的支持。

HTTP Method

GET

GET 是最常用的方法。通常用于請求服務器發送某個資源。HTTP/1.1 要求服務器實現此方法。

HEAD

HEAD 方法與 GET 方法的行為很類似，但服務器在響應中只返回首部。不會返回實體的主體部分。這就允許客戶端在未獲取實際資源的情況下，對資源的首部進行檢查。使用 HEAD，可以:

• 在不獲取資源的情況下了解資源的情況(比如，判斷其類型);
• 通過查看響應中的狀態碼，看看某個對象是否存在;
• 通過查看首部，測試資源是否被修改了。

服務器開發者必須確保返回的首部與 GET 請求所返回的首部完全相同。遵循 HTTP/1.1 規范，就必須實現 HEAD 方法。

PUT

與 GET 從服務器讀取文檔相反，PUT 方法會向服務器寫入文檔。有些發布系統允許用戶創建 Web 頁面，并用 PUT 直接將其安裝到 Web 服務器上去。

PUT 方法的語義就是讓服務器用請求的主體部分來創建一個由所請求的 URL 命名的新文檔，或者，如果那個 URL 已經存在的話，就用這個主體來替代它。

因為 PUT 允許用戶對內容進行修改，所以很多 Web 服務器都要求在執行 PUT 之前，用密碼登錄。

和POST方法一樣，PUT方法也改變了資源的狀態，所以是 非安全 的。但是有一點和POST不同，它是 冪等 的，這是為什么呢？想想setter函數吧，重復調用，只要參數是一樣的，表述就是不變的。

POST

POST 方法起初是用來向服務器輸入數據的。實際上，通常會用它來支持 HTML 的表單。表單中填好的數據通常會被送給服務器，然后由服務器將其發送到它要去的地方(比如，送到一個服務器網關程序中，然后由這個程序對其進行處理)。

注： POST 用于向服務器發送數據。PUT 用于向服務器上的資源(例如文件)中存儲數據。

TRACE

客戶端發起一個請求時，這個請求可能要穿過防火墻、代理、網關或其他一些應用程序。每個中間節點都可能會修改原始的 HTTP 請求。TRACE 方法允許客戶端在 最終將請求發送給服務器時，看看它變成了什么樣子。

TRACE 請求會在目的服務器端發起一個 環回 診斷。行程最后一站的服務器會彈回一條 TRACE 響應，并在響應主體中攜帶它收到的原始請求報文。這樣客戶端就可以查看在所有中間 HTTP 應用程序組成的請求 / 響應鏈上，原始報文是否，以及如何被毀壞或修改過。

TRACE 方法主要用于診斷；也就是說，用于驗證請求是否如愿穿過了請求 / 響應鏈。它也是一種很好的工具，可以用來查看代理和其他應用程序對用戶請求所產生 效果。

盡管 TRACE 可以很方便地用于診斷，但它確實也有缺點，它假定中間應用程序對各種不同類型請求(不同的方法——GET、HEAD、POST 等)的處理是相同的。

很多 HTTP 應用程序會根據方法的不同做出不同的事情——比如，代理可能會將 POST 請求直接發送給服務器，而將 GET 請求發送給另一個 HTTP 應用程序(比如 Web 緩存)。TRACE 并不提供區分這些方法的機制。通常，中間應用程序會自行決定對 TRACE 請求的處理方式。

TRACE 請求中不能帶有實體的主體部分。TRACE 響應的實體主體部分包含了響應服務器收到的請求的精確副本。

當 TRACE 請求到達目的服務器時，16 整條請求報文都會被封裝在一條 HTTP 響應的主體中回送給發送端。當 TRACE 響應到達時，客戶端可以檢查服務器收到的確切報文，以及它所經過的代理列表(在 Via 首部)。TRACE 響應的 Content-Type 為 message/http，狀態為 200 OK。

Via

Via 首部字段列出了與報文途經的每個中間節點(代理或網關)有關的信息。報文每經過一個節點，都必須將這個中間節點添加到 Via 列表的末尾。

代理也可以用 Via 首部來檢測網絡中的路由循環。代理應該在發送一條請求之前， 在 Via 首部插入一個與其自身有關的獨特字符串，并在輸入的請求中查找這個字符 串，以檢測網絡中是否存在路由循環。

Via 首部字段包含一個由逗號分隔的 路標(waypoint)。每個路標都表示一個獨立的 代理服務器或網關，且包含與那個中間節點的協議和地址有關的信息。下面是一個 帶有兩個路標的 Via 首部實例:

Via = 1.1 cache.joes-hardware.com, 1.1 proxy.irenes-isp.net

Via 首部的正規語法如下所示:

Via = "Via" ":" 1#( waypoint ) waypoint = ( received-protocol received-by [ comment ] ) received-protocol = [ protocol-name "/" ] protocol-version received-by = ( host [ ":" port ] ) | pseudonym

注意，每個 Via 路標中最多包含 4 個組件:一個可選的協議名(默認為 HTTP)、一 個必選的協議版本、一個必選的節點名和一個可選的描述性注釋。

OPTIONS

OPTIONS 方法請求 Web 服務器告知其支持的各種功能。可以詢問服務器通常支持哪些方法，或者對某些特殊資源支持哪些方法。(有些服務器可能只支持對一些特殊類型的對象使用特定的操作)。

通過使用 OPTIONS，客戶端可以在與服務器進行交互之前，確定服務器的能力，這樣它就可以更方便地與具備不同特性的代理和服務器進行互操作了。

這為客戶端應用程序提供了一種手段，使其不用實際訪問那些資源就能判定訪問各種資源的最優方式。

如果 OPTIONS 請求的 URI 是個星號(*)，請求的就是整個服務器所支持的功能。

比如:

OPTIONS * HTTP/1.1

如果 URI 是個實際資源地址，OPTIONS 請求就是在查詢那個特定資源的可用特性:

OPTIONS http://www.joes-hardware.com/index.html HTTP/1.1

如果成功，OPTIONS方法就會返回一個包含了各種首部字段的200 OK響應，這些 字段描述了服務器所支持的，或資源可用的各種可選特性。HTTP/1.1 在響應中唯一 指定的首部字段是 Allow 首部，這個首部用于描述服務器所支持的各種方法(或者 服務器上的特定資源)。OPTIONS 允許在可選的響應主體中包含更多的信息，但并沒有對這種用法進行定義。

Allow首部

Allow 實體首部字段列出了請求 URI 標識的資源所支持的方法列表，如果請求 URI為 * 的話，列出的就是整個服務器所支持的方法列表。例如:

Allow: GET, HEAD, PUT

可以將 Allow 首部作為請求首部，建議在新的資源上支持某些方法。并不要求服務 器支持這些方法，但應該在相應的響應中包含一個 Allow 首部，列出它實際支持的方法。

因為客戶端可能已經通過其他途徑與原始服務器進行了交流，所以即使代理無法理解指定的所有方法，也不能對 Allow 首部字段進行修改。

DELETE

顧名思義，DELETE 方法所做的事情就是請服務器刪除請求 URL 所指定的資源。 但是，客戶端應用程序無法保證刪除操作一定會被執行。因為 HTTP 規范允許服務 器在不通知客戶端的情況下撤銷請求。

和POST方法一樣，DELETE方法也改變了資源的狀態，所以是非安全的。但是有一點和POST不同，它是冪等的，也就是說，就算是服務器在前一個請求中已經刪除了資源，它也必須返回200.這就意味著，我們在實現服務端的該方法是，需要跟蹤已經刪除的資源，否則就會返回404的。

CONNECT

CONNECT方法是HTTP/1.1協議預留的，能夠將連接改為管道方式的代理服務器。通常用于SSL加密服務器的鏈接與非加密的HTTP代理服務器的通信。

PATCH

PATCH方法出現的較晚，它在2010年的 RFC 5789 PATCH Method for HTTP 標準中被定義。PATCH請求與PUT請求類似，同樣用于資源的更新。二者有以下兩點不同：

• 但PATCH一般用于資源的部分更新，而PUT一般用于資源的整體更新。
• 當資源不存在時，PATCH會創建一個新的資源，而PUT只會對已在資源進行更新。

參考

• HTTP 權威指南
• RFC 7231, section 4: Request methods
• RFC 5789, section 2: Patch method

總結

以上是生活随笔為你收集整理的常见的HTTP Method深度解析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。