常見的HTTP Method深度解析

時間 2019-12-31

標籤常見的 http method 深度解析欄目 HTTP/TCP 简体版

原文原文鏈接

HTTP版本

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

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 方法。spa

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 容許在可選的響應主體中包含更多的信息，但並無對這種用法進行定義。