HTTP協議詳解（三）

HTTP協議詳解（三）

HTTP協議詳解之響應報文

狀態行以及狀態碼說明

包含表明響應結果的狀態碼，原因短語和 HTTP 版本。
例如：HTTP/1.1 200 OK

下面來看看常用的14種狀態碼：

• 200 OK
  表示從客戶端發來的請求在服務器端被正常處理了。
• 204 No Content
  該狀態碼代表服務器接收的請求已成功處理，但在返回的響應報文中不含實體的主體部分。另外，也不允許返回任何實體的主體。比如，當從瀏覽器發出請求處理後，返回 204 響應，那麼瀏覽器顯示的頁面不發生更新。
• 206 Partial Content
  該狀態碼錶示客戶端進行了範圍請求，而服務器成功執行了這部分的GET 請求。響應報文中包含由 Content-Range 指定範圍的實體內容。
• 301 Moved Permanently
  永久性重定向。該狀態碼錶示請求的資源已被分配了新的 URI，以後應使用資源現在所指的 URI。也就是說，如果已經把資源對應的 URI保存爲書籤了，這時應該按 Location 響應首部字段提示的 URI 重新保存。
  像下方給出的請求 URI，當指定資源路徑的最後忘記添加斜槓“/”，就會產生 301 狀態碼。
  http://example.com/sample
• 302 Found
  臨時性重定向。該狀態碼錶示請求的資源已被分配了新的 URI，希望用戶（本次）能使用新的 URI 訪問。
  和 301 Moved Permanently 狀態碼相似，但 302 狀態碼代表的資源不是被永久移動，只是臨時性質的。換句話說，已移動的資源對應的URI 將來還有可能發生改變。比如，用戶把 URI 保存成書籤，但不會像 301 狀態碼出現時那樣去更新書籤，而是仍舊保留返回 302 狀態碼的頁面對應的 URI。
• 303 See Other
  該狀態碼錶示由於請求對應的資源存在着另一個 URI，應使用 GET方法定向獲取請求的資源。
  303 狀態碼和 302 Found 狀態碼有着相同的功能，但 303 狀態碼明確表示客戶端應當採用 GET 方法獲取資源，這點與 302 狀態碼有區別。
  比如，當使用 POST 方法訪問 CGI 程序，其執行後的處理結果是希望客戶端能以 GET 方法重定向到另一個 URI 上去時，返回 303 狀態碼。雖然 302 Found 狀態碼也可以實現相同的功能，但這裏使用 303狀態碼是最理想的。

• 當 301、302、303 響應狀態碼返回時，幾乎所有的瀏覽器都會把POST 改成 GET，並刪除請求報文內的主體，之後請求會自動再次發送。
• 301、302 標準是禁止將 POST 方法改變成 GET 方法的，但實際使用時大家都會這麼做。

• 304 Not Modified
  該狀態碼錶示客戶端發送附帶條件的請求（是指採用 GET 方法的請求報文中包含 If-Match等）時，服務器端允許請求訪問資源，但未滿足條件的情況。304 狀態碼返回時，不包含任何響應的主體部分。304 雖然被劃分在 3XX 類別中，但是和重定向沒有關係。
• 307 Temporary Redirect
  臨時重定向。該狀態碼與 302 Found 有着相同的含義。儘管 302 標準禁止 POST 變換成 GET，但實際使用時大家並不遵守。
  307 會遵照瀏覽器標準，不會從 POST 變成 GET。但是，對於處理響應時的行爲，每種瀏覽器有可能出現不同的情況。
• 400 Bad Request
  該狀態碼錶示請求報文中存在語法錯誤。當錯誤發生時，需修改請求的內容後再次發送請求。另外，瀏覽器會像 200 OK 一樣對待該狀態碼。
• 401 Unauthorized
  該狀態碼錶示發送的請求需要有通過 HTTP 認證（BASIC 認證、DIGEST 認證）的認證信息。另外若之前已進行過 1 次請求，則表示用 戶認證失敗。
  
  返回含有 401 的響應必須包含一個適用於被請求資源的 WWWAuthenticate首部用以質詢（challenge）用戶信息。當瀏覽器初次接收到 401 響應，會彈出認證用的對話窗口。
• 403 Forbidden
  該狀態碼錶明對請求資源的訪問被服務器拒絕了。服務器端沒有必要給出拒絕的詳細理由，但如果想作說明的話，可以在實體的主體部分
  對原因進行描述，這樣就能讓用戶看到了。未獲得文件系統的訪問授權，訪問權限出現某些問題（從未授權的發送源 IP 地址試圖訪問）等列舉的情況都可能是發生 403 的原因。
• 404 Not Found
  該狀態碼錶明服務器上無法找到請求的資源。除此之外，也可以在服務器端拒絕請求且不想說明理由時使用。
• 500 Internal Server Error
  該狀態碼錶明服務器端在執行請求時發生了錯誤。也有可能是 Web應用存在的 bug 或某些臨時的故障。
• 503 Service Unavailable
  該狀態碼錶明服務器暫時處於超負載或正在進行停機維護，現在無法處理請求。如果事先得知解除以上狀況需要的時間，最好寫入RetryAfter 首部字段再返回給客戶端。

響應首部字段

響應首部字段是由服務器端向客戶端返回響應報文中所使用的字段，用於補充響應的附加信息、服務器信息，以及對客戶端的附加要求等信息。

Accept-Ranges

首部字段 Accept-Ranges 是用來告知客戶端服務器是否能處理範圍請求，以指定獲取服務器端某個部分的資源。
可指定的字段值有兩種，可處理範圍請求時指定其爲 bytes，反之則指定其爲 none。

Age

首部字段 Age 能告知客戶端，源服務器在多久前創建了響應。字段值的單位爲秒。
若創建該響應的服務器是緩存服務器，Age 值是指緩存後的響應再次發起認證到認證完成的時間值。代理創建響應時必須加上首部字Age。

ETag

首部字段 ETag 能告知客戶端實體標識。它是一種可將資源以字符串形式做唯一性標識的方式。服務器會爲每份資源分配對應的 ETag值。
另外，當資源更新時，ETag 值也需要更新。生成 ETag 值時，並沒有統一的算法規則，而僅僅是由服務器來分配。
資源被緩存時，就會被分配唯一性標識。例如，當使用中文版的瀏覽器訪問 http://www.google.com/ 時，就會返回中文版對應的資源，而使用英文版的瀏覽器訪問時，則會返回英文版對應的資源。兩者的URI 是相同的，所以僅憑 URI 指定緩存的資源是相當困難的。若在下載過程中出現連接中斷、再連接的情況，都會依照 ETag 值來指定資源。

• 強 ETag 值
  強 ETag 值，不論實體發生多麼細微的變化都會改變其值。例如：ETag: "usagi-1234"
• 弱 ETag 值
  弱 ETag 值只用於提示資源是否相同。只有資源發生了根本改變，產生差異時纔會改變 ETag 值。這時，會在字段值最開始處附加 W/。
  例如：ETag: W/"usagi-1234"

Location

使用首部字段 Location 可以將響應接收方引導至某個與請求 URI 位置不同的資源。基本上，該字段會配合 3xx ：Redirection 的響應，提供重定向的URI。
基本上，該字段會配合 3xx ：Redirection 的響應，提供重定向的URI。幾乎所有的瀏覽器在接收到包含首部字段 Location 的響應後，都會強制性地嘗試對已提示的重定向資源的訪問。

Proxy-Authenticate

響應首部字段 Proxy-Authenticate 會把由代理服務器所要求的認證信息發送給客戶端。
它與客戶端和服務器之間的 HTTP 訪問認證的行爲相似，不同之處在於其認證行爲是在客戶端與代理之間進行的。而客戶端與服務器之間進行認證時，首部字段 WWW-Authorization 有着相同的作用。
例如：Proxy-Authenticate: Basic realm="Usagidesign Auth"

Retry-After

首部字段 Retry-After 告知客戶端應該在多久之後再次發送請求。主要配合狀態碼 503 Service Unavailable 響應，或 3xx Redirect 響應一使用。字段值可以指定爲具體的日期時間（Wed, 04 Jul 2012 06：34：24GMT 等格式），也可以是創建響應後的秒數。

Server

首部字段 Server 告知客戶端當前服務器上安裝的 HTTP 服務器應用程序的信息。不單單會標出服務器上的軟件應用名稱，還有可能包括版本號和安裝時啓用的可選項。
例如：Server: Apache/2.2.17 (Unix) Server: Apache/2.2.6 (Unix) PHP/5.2.5

Vary

首部字段 Vary 可對緩存進行控制。源服務器會向代理服務器傳達關於本地緩存使用方法的命令。
從代理服務器接收到源服務器返回包含 Vary 指定項的響應之後，若再要進行緩存，僅對請求中含有相同 Vary 指定首部字段的請求返回緩存。即使對相同資源發起請求，但由於 Vary 指定的首部字段不相同，因此必須要從源服務器重新獲取資源。

上圖中當代理服務器接收到帶有 Vary 首部字段指定獲取資源的請求時，如果使用的 Accept-Language 字段的值相同，那麼就直接從緩存返回響應。反之，則需要先從源服務器端獲取資源後才能作爲響應返回。
Vary: Accept-Language

WWW-Authenticate

首部字段 WWW-Authenticate 用於 HTTP 訪問認證。它會告知客戶端適用於訪問請求 URI 所指定資源的認證方案（Basic 或是 Digest）和帶參數提示的質詢（challenge）。狀態碼 401 Unauthorized 響應中，肯定帶有首部字段 WWW-Authenticate。
例子：WWW-Authenticate: Basic realm="Usagidesign Auth"
上述示例中，realm 字段的字符串是爲了辨別請求 URI 指定資源所受到的保護策略。有關該首部，請參閱本章之後的內容。

通用首部字段

通用首部字段是指，請求報文和響應報文雙方都會使用的首部。

詳細說明參見前面章節:HTTP協議詳解（二）

實體首部字段

實體首部字段是包含在請求報文和響應報文中的實體部分所使用的首部，用於補充內容的更新時間等與實體相關的信息。

詳細說明參見前面章節:HTTP協議詳解（二）

響應報文主體

指請求資源返回的內容

響應報文樣例