http狀態碼 以及請求響應頭相關

1xx消息[編輯]

這一類型的狀態碼，代表請求已被接受，需要繼續處理。這類響應是臨時響應，只包含狀態行和某些可選的響應頭信息，並以空行結束。由於HTTP/1.0協議中沒有定義任何1xx狀態碼，所以除非在某些試驗條件下，服務器禁止向此類客戶端發送1xx響應。 這些狀態碼代表的響應都是信息性的，標示客戶應該采取的其他行動。

100 Continue

客戶端應當繼續發送請求。這個臨時響應是用來通知客戶端它的部分請求已經被服務器接收，且仍未被拒絕。客戶端應當繼續發送請求的剩余部分，或者如果請求已經完成，忽略這個響應。服務器必須在請求完成后向客戶端發送一個最終響應。

101 Switching Protocols

服務器已經理解了客戶端的請求，並將通過Upgrade消息頭通知客戶端采用不同的協議來完成這個請求。在發送完這個響應最后的空行后，服務器將會切換到在Upgrade消息頭中定義的那些協議。

只有在切換新的協議更有好處的時候才應該采取類似措施。例如，切換到新的HTTP版本（如 HTTP/2）比舊版本更有優勢，或者切換到一個實時且同步的協議以傳送利用此類特性的資源。

102 Processing

由 WebDAV（ RFC 2518）擴展的狀態碼，代表處理將被繼續執行。

2xx成功[編輯]

這一類型的狀態碼，代表請求已成功被服務器接收、理解、並接受。

200 OK

請求已成功，請求所希望的響應頭或數據體將隨此響應返回。

201 Created

請求已經被實現，而且有一個新的資源已經依據請求的需要而創建，且其 URI已經隨Location頭信息返回。假如需要的資源無法及時創建的話，應當返回' 202 Accepted'。

202 Accepted

服務器已接受請求，但尚未處理。正如它可能被拒絕一樣，最終該請求可能會也可能不會被執行。在異步操作的場合下，沒有比發送這個狀態碼更方便的做法了。

返回202狀態碼的響應的目的是允許服務器接受其他過程的請求（例如某個每天只執行一次的基於 批處理的操作），而不必讓客戶端一直保持與服務器的連接直到批處理操作全部完成。在接受請求處理並返回202狀態碼的響應應當在返回的實體中包含一些指示處理當前狀態的信息，以及指向處理狀態監視器或狀態預測的指針，以便用戶能夠估計操作是否已經完成。

203 Non-Authoritative Information

服務器已成功處理了請求，但返回的實體頭部元信息不是在原始服務器上有效的確定集合，而是來自本地或者第三方的拷貝。當前的信息可能是原始版本的子集或者超集。例如，包含資源的 元數據可能導致原始服務器知道元信息的超集。使用此狀態碼不是必須的，而且只有在響應不使用此狀態碼便會返回 200 OK的情況下才是合適的。

204 No Content

服務器成功處理了請求，但不需要返回任何實體內容，並且希望返回更新了的元信息。響應可能通過實體頭部的形式，返回新的或更新后的元信息。如果存在這些頭部信息，則應當與所請求的變量相呼應。

如果客戶端是 瀏覽器的話，那么用戶瀏覽器應保留發送了該請求的頁面，而不產生任何文檔視圖上的變化，即使按照規范新的或更新后的元信息應當被應用到用戶瀏覽器活動視圖中的文檔。

由於204響應被禁止包含任何消息體，因此它始終以消息頭后的第一個空行結尾。

205 Reset Content

服務器成功處理了請求，且沒有返回任何內容。但是與 204響應不同，返回此狀態碼的響應要求請求者重置文檔視圖。該響應主要是被用於接受用戶輸入后，立即重置表單，以便用戶能夠輕松地開始另一次輸入。

與204響應一樣，該響應也被禁止包含任何消息體，且以消息頭后的第一個空行結束。

206 Partial Content

服務器已經成功處理了部分GET請求。類似於 FlashGet或者 迅雷這類的HTTP  下載工具都是使用此類響應實現斷點續傳或者將一個大文檔分解為多個下載段同時下載。

該請求必須包含Range頭信息來指示客戶端希望得到的內容范圍，並且可能包含If-Range來作為請求條件。

響應必須包含如下的頭部域：

• Content-Range用以指示本次響應中返回的內容的范圍；如果是Content-Type為multipart/byteranges的多段下載，則每一multipart段中都應包含Content-Range域用以指示本段的內容范圍。假如響應中包含Content-Length，那么它的數值必須匹配它返回的內容范圍的真實字節數。
• Date
• ETag和／或Content-Location，假如同樣的請求本應該返回200響應。
• Expires, Cache-Control，和／或Vary，假如其值可能與之前相同變量的其他響應對應的值不同的話。

假如本響應請求使用了If-Range強緩存驗證，那么本次響應不應該包含其他實體頭；假如本響應的請求使用了If-Range弱緩存驗證，那么本次響應禁止包含其他實體頭；這避免了緩存的實體內容和更新了的實體頭信息之間的不一致。否則，本響應就應當包含所有本應該返回200響應中應當返回的所有實體頭部域。

假如ETag或Last-Modified頭部不能精確匹配的話，則客戶端 緩存應禁止將206響應返回的內容與之前任何緩存過的內容組合在一起。

任何不支持Range以及Content-Range頭的緩存都禁止緩存206響應返回的內容。

207 Multi-Status

由WebDAV( RFC 2518)擴展的狀態碼，代表之后的消息體將是一個 XML消息，並且可能依照之前子請求數量的不同，包含一系列獨立的響應代碼。

3xx重定向[編輯]

這類狀態碼代表需要客戶端采取進一步的操作才能完成請求。通常，這些狀態碼用來重定向，后續的請求地址（重定向目標）在本次響應的Location域中指明。

當且僅當后續的請求所使用的方法是GET或者HEAD時，用戶瀏覽器才可以在沒有用戶介入的情況下自動提交所需要的后續請求。客戶端應當自動監測無限循環重定向（例如：A→B→C→……→A或A→A），因為這會導致服務器和客戶端大量不必要的資源消耗。按照HTTP/1.0版規范的建議，瀏覽器不應自動訪問超過5次的重定向。

300 Multiple Choices

被請求的資源有一系列可供選擇的回饋信息，每個都有自己特定的地址和瀏覽器驅動的商議信息。用戶或瀏覽器能夠自行選擇一個首選的地址進行重定向。

除非這是一個HEAD請求，否則該響應應當包括一個資源特性及地址的列表的實體，以便用戶或瀏覽器從中選擇最合適的重定向地址。這個實體的格式由Content-Type定義的格式所決定。瀏覽器可能根據響應的格式以及瀏覽器自身能力，自動作出最合適的選擇。當然，RFC 2616規范並沒有規定這樣的自動選擇該如何進行。

如果服務器本身已經有了首選的回饋選擇，那么在Location中應當指明這個回饋的 URI；瀏覽器可能會將這個Location值作為自動重定向的地址。此外，除非額外指定，否則這個響應也是可緩存的。

301 Moved Permanently

被請求的資源已永久移動到新位置，並且將來任何對此資源的引用都應該使用本響應返回的若干個URI之一。如果可能，擁有鏈接編輯功能的客戶端應當自動把請求的地址修改為從服務器反饋回來的地址。除非額外指定，否則這個響應也是可緩存的。

新的永久性的URI應當在響應的Location域中返回。除非這是一個HEAD請求，否則響應的實體中應當包含指向新的URI的 超鏈接及簡短說明。

如果這不是一個GET或者HEAD請求，因此瀏覽器禁止自動進行重定向，除非得到用戶的確認，因為請求的條件可能因此發生變化。

注意：對於某些使用HTTP/1.0協議的瀏覽器，當它們發送的POST請求得到了一個301響應的話，接下來的重定向請求將會變成GET方式。

302 Found

請求的資源現在臨時從不同的URI響應請求。由於這樣的重定向是臨時的，客戶端應當繼續向原有地址發送以后的請求。只有在Cache-Control或Expires中進行了指定的情況下，這個響應才是可緩存的。

新的臨時性的URI應當在響應的Location域中返回。除非這是一個HEAD請求，否則響應的實體中應當包含指向新的URI的超鏈接及簡短說明。

如果這不是一個GET或者HEAD請求，那么瀏覽器禁止自動進行重定向，除非得到用戶的確認，因為請求的條件可能因此發生變化。

注意：雖然RFC 1945和RFC 2068規范不允許客戶端在重定向時改變請求的方法，但是很多現存的瀏覽器將302響應視作為 303響應，並且使用GET方式訪問在Location中規定的URI，而無視原先請求的方法。狀態碼303和 307被添加了進來，用以明確服務器期待客戶端進行何種反應。

303 See Other

對應當前請求的響應可以在另一個URI上被找到，而且客戶端應當采用GET的方式訪問那個資源。這個方法的存在主要是為了允許由腳本激活的POST請求輸出重定向到一個新的資源。這個新的URI不是原始資源的替代引用。同時，303響應禁止被緩存。當然，第二個請求（重定向）可能被緩存。

新的URI應當在響應的Location域中返回。除非這是一個HEAD請求，否則響應的實體中應當包含指向新的URI的超鏈接及簡短說明。

注意：許多HTTP/1.1版以前的瀏覽器不能正確理解303狀態。如果需要考慮與這些瀏覽器之間的互動， 302狀態碼應該可以勝任，因為大多數的瀏覽器處理302響應時的方式恰恰就是上述規范要求客戶端處理303響應時應當做的。

304 Not Modified

如果客戶端發送了一個帶條件的GET請求且該請求已被允許，而文檔的內容（自上次訪問以來或者根據請求的條件）並沒有改變，則服務器應當返回這個狀態碼。304響應禁止包含消息體，因此始終以消息頭后的第一個空行結尾。

該響應必須包含以下的頭信息：

• Date，除非這個服務器沒有時鍾。假如沒有時鍾的服務器也遵守這些規則，那么代理服務器以及客戶端可以自行將Date字段添加到接收到的響應頭中去（正如RFC 2068中規定的一樣），緩存機制將會正常工作。
• ETag和／或Content-Location，假如同樣的請求本應返回200響應。
• Expires, Cache-Control，和／或Vary，假如其值可能與之前相同變量的其他響應對應的值不同的話。

假如本響應請求使用了強緩存驗證，那么本次響應不應該包含其他實體頭；否則（例如，某個帶條件的GET請求使用了弱緩存驗證），本次響應禁止包含其他實體頭；這避免了緩存了的實體內容和更新了的實體頭信息之間的不一致。

假如某個304響應指明了當前某個實體沒有緩存，那么緩存系統必須忽視這個響應，並且重復發送不包含限制條件的請求。

假如接收到一個要求更新某個緩存條目的304響應，那么緩存系統必須更新整個條目以反映所有在響應中被更新的字段的值。

305 Use Proxy

被請求的資源必須通過指定的代理才能被訪問。Location域中將給出指定的代理所在的URI信息，接收者需要重復發送一個單獨的請求，通過這個代理才能訪問相應資源。只有原始服務器才能創建305響應。

注意：RFC 2068中沒有明確305響應是為了重定向一個單獨的請求，而且只能被原始服務器創建。忽視這些限制可能導致嚴重的安全后果。

306 Switch Proxy

在最新版的規范中，306狀態碼已經不再被使用。

307 Temporary Redirect

請求的資源現在臨時從不同的URI響應請求。由於這樣的重定向是臨時的，客戶端應當繼續向原有地址發送以后的請求。只有在Cache-Control或Expires中進行了指定的情況下，這個響應才是可緩存的。

新的臨時性的URI應當在響應的Location域中返回。除非這是一個HEAD請求，否則響應的實體中應當包含指向新的URI的超鏈接及簡短說明。因為部分瀏覽器不能識別307響應，因此需要添加上述必要信息以便用戶能夠理解並向新的URI發出訪問請求。

如果這不是一個GET或者HEAD請求，那么瀏覽器禁止自動進行重定向，除非得到用戶的確認，因為請求的條件可能因此發生變化。

4xx客戶端錯誤[編輯]

這類的狀態碼代表了客戶端看起來可能發生了錯誤，妨礙了服務器的處理。除非響應的是一個HEAD請求，否則服務器就應該返回一個解釋當前錯誤狀況的實體，以及這是臨時的還是永久性的狀況。這些狀態碼適用於任何請求方法。瀏覽器應當向用戶顯示任何包含在此類錯誤響應中的實體內容。

如果錯誤發生時客戶端正在傳送數據，那么使用TCP的服務器實現應當仔細確保在關閉客戶端與服務器之間的連接之前，客戶端已經收到了包含錯誤信息的數據包。如果客戶端在收到錯誤信息后繼續向服務器發送數據，服務器的TCP棧將向客戶端發送一個重置數據包，以清除該客戶端所有還未識別的輸入緩沖，以免這些數據被服務器上的應用程序讀取並干擾后者。

400 Bad Request

由於包含 語法錯誤，當前請求無法被服務器理解。除非進行修改，否則客戶端不應該重復提交這個請求。

401 Unauthorized

當前請求需要用戶驗證。該響應必須包含一個適用於被請求資源的WWW-Authenticate信息頭用以詢問用戶信息。客戶端可以重復提交一個包含恰當的Authorization頭信息的請求。如果當前請求已經包含了Authorization證書，那么401響應代表着服務器驗證已經拒絕了那些證書。如果401響應包含了與前一個響應相同的身份驗證詢問，且瀏覽器已經至少嘗試了一次驗證，那么瀏覽器應當向用戶展示響應中包含的實體信息，因為這個實體信息中可能包含了相關診斷信息。參見RFC 2617。

402 Payment Required

該狀態碼是為了將來可能的需求而預留的。

403 Forbidden

服務器已經理解請求，但是拒絕執行它。與 401響應不同的是，身份驗證並不能提供任何幫助，而且這個請求也不應該被重復提交。如果這不是一個HEAD請求，而且服務器希望能夠講清楚為何請求不能被執行，那么就應該在實體內描述拒絕的原因。當然服務器也可以返回一個 404響應，假如它不希望讓客戶端獲得任何信息。

404 Not Found

請求失敗，請求所希望得到的資源未被在服務器上發現。沒有信息能夠告訴用戶這個狀況到底是暫時的還是永久的。假如服務器知道情況的話，應當使用 410狀態碼來告知舊資源因為某些內部的配置機制問題，已經永久的不可用，而且沒有任何可以跳轉的地址。404這個狀態碼被廣泛應用於當服務器不想揭示到底為何請求被拒絕或者沒有其他適合的響應可用的情況下。

405 Method Not Allowed

請求行中指定的請求方法不能被用於請求相應的資源。該響應必須返回一個Allow頭信息用以表示出當前資源能夠接受的請求方法的列表。

鑒於PUT，DELETE方法會對服務器上的資源進行寫操作，因而絕大部分的 網頁服務器都不支持或者在默認配置下不允許上述請求方法，對於此類請求均會返回405錯誤。

406 Not Acceptable

請求的資源的內容特性無法滿足請求頭中的條件，因而無法生成響應實體。

除非這是一個HEAD請求，否則該響應就應當返回一個包含可以讓用戶或者瀏覽器從中選擇最合適的實體特性以及地址列表的實體。實體的格式由Content-Type頭中定義的媒體類型決定。瀏覽器可以根據格式及自身能力自行作出最佳選擇。但是，規范中並沒有定義任何作出此類自動選擇的標准。

407 Proxy Authentication Required

與 401響應類似，只不過客戶端必須在代理服務器上進行身份驗證。代理服務器必須返回一個Proxy-Authenticate用以進行身份詢問。客戶端可以返回一個Proxy-Authorization信息頭用以驗證。參見RFC 2617。

408 Request Timeout

請求超時。客戶端沒有在服務器預備等待的時間內完成一個請求的發送。客戶端可以隨時再次提交這一請求而無需進行任何更改。

409 Conflict

由於和被請求的資源的當前狀態之間存在沖突，請求無法完成。這個代碼只允許用在這樣的情況下才能被使用：用戶被認為能夠解決沖突，並且會重新提交新的請求。該響應應當包含足夠的信息以便用戶發現沖突的源頭。

沖突通常發生於對PUT請求的處理中。例如，在采用版本檢查的環境下，某次PUT提交的對特定資源的修改請求所附帶的版本信息與之前的某個（第三方）請求向沖突，那么此時服務器就應該返回一個409錯誤，告知用戶請求無法完成。此時，響應實體中很可能會包含兩個 沖突版本之間的差異比較，以便用戶重新提交 歸並以后的新版本。

410 Gone

被請求的資源在服務器上已經不再可用，而且沒有任何已知的轉發地址。這樣的狀況應當被認為是永久性的。如果可能，擁有鏈接編輯功能的客戶端應當在獲得用戶許可后刪除所有指向這個地址的引用。如果服務器不知道或者無法確定這個狀況是否是永久的，那么就應該使用 404狀態碼。除非額外說明，否則這個響應是可緩存的。

410響應的目的主要是幫助網站管理員維護網站，通知用戶該資源已經不再可用，並且服務器擁有者希望所有指向這個資源的遠端連接也被刪除。這類事件在限時、增值服務中很普遍。同樣，410響應也被用於通知客戶端在當前服務器站點上，原本屬於某個個人的資源已經不再可用。當然，是否需要把所有永久不可用的資源標記為'410 Gone'，以及是否需要保持此標記多長時間，完全取決於服務器擁有者。

411 Length Required

服務器拒絕在沒有定義Content-Length頭的情況下接受請求。在添加了表明請求消息體長度的有效Content-Length頭之后，客戶端可以再次提交該請求。

412 Precondition Failed

服務器在驗證在請求的頭字段中給出先決條件時，沒能滿足其中的一個或多個。這個狀態碼允許客戶端在獲取資源時在請求的元信息（請求頭字段數據）中設置先決條件，以此避免該請求方法被應用到其希望的內容以外的資源上。

413 Request Entity Too Large

服務器拒絕處理當前請求，因為該請求提交的實體數據大小超過了服務器願意或者能夠處理的范圍。此種情況下，服務器可以關閉連接以免客戶端繼續發送此請求。

如果這個狀況是臨時的，服務器應當返回一個Retry-After的響應頭，以告知客戶端可以在多少時間以后重新嘗試。

414 Request-URI Too Long

請求的URI長度超過了服務器能夠解釋的長度，因此服務器拒絕對該請求提供服務。這比較少見，通常的情況包括：

• 本應使用POST方法的表單提交變成了GET方法，導致查詢字符串（Query String）過長。
• 重定向URI“黑洞”，例如每次重定向把舊的URI作為新的URI的一部分，導致在若干次重定向后URI超長。
• 客戶端正在嘗試利用某些服務器中存在的安全漏洞攻擊服務器。這類服務器使用固定長度的緩沖讀取或操作請求的URI，當GET后的參數超過某個數值后，可能會產生緩沖區溢出，導致任意代碼被執行^[1]。沒有此類漏洞的服務器，應當返回414狀態碼。

415 Unsupported Media Type

對於當前請求的方法和所請求的資源，請求中提交的實體並不是服務器中所支持的格式，因此請求被拒絕。

416 Requested Range Not Satisfiable

如果請求中包含了Range請求頭，並且Range中指定的任何數據范圍都與當前資源的可用范圍不重合，同時請求中又沒有定義If-Range請求頭，那么服務器就應當返回416狀態碼。

假如Range使用的是字節范圍，那么這種情況就是指請求指定的所有數據范圍的首字節位置都超過了當前資源的長度。服務器也應當在返回416狀態碼的同時，包含一個Content-Range實體頭，用以指明當前資源的長度。這個響應也被禁止使用multipart/byteranges作為其Content-Type。

417 Expectation Failed

在請求頭Expect中指定的預期內容無法被服務器滿足，或者這個服務器是一個代理服務器，它有明顯的證據證明在當前 路由的下一個節點上，Expect的內容無法被滿足。

418 I'm a teapot

本操作碼是在1998年作為 IETF的傳統 愚人節笑話, 在RFC 2324  超文本咖啡壺控制協議中定義的，並不需要在真實的HTTP服務器中定義。當一個控制茶壺的 HTCPCP收到BREW或POST指令要求其煮咖啡時應當回傳此錯誤。

421 There are too many connections from your internet address

從當前客戶端所在的 IP地址到服務器的連接數超過了服務器許可的最大范圍。通常，這里的IP地址指的是從服務器上看到的客戶端地址（比如用戶的 網關或者 代理服務器地址）。在這種情況下，連接數的計算可能涉及到不止一個 終端用戶。

422 Unprocessable Entity

請求格式正確，但是由於含有 語義錯誤，無法響應。（ RFC 4918  WebDAV）

423 Locked

當前資源被鎖定。（ RFC 4918  WebDAV）

424 Failed Dependency

由於之前的某個請求發生的錯誤，導致當前請求失敗，例如PROPPATCH。（ RFC 4918  WebDAV）

425 Unordered Collection

在 WebDav Advanced Collections草案中定義，但是未出現在《WebDAV順序集協議》（ RFC 3658）中。

426 Upgrade Required

客戶端應當切換到 TLS/1.0。（ RFC 2817）

449 Retry With

由 微軟擴展，代表請求應當在執行完適當的操作后進行重試。

451 Unavailable For Legal Reasons

由 IETF核准，代表該訪問因 法律的要求而被拒絕。 ^{[2] [3]}

5xx服務器錯誤[編輯]

這類狀態碼代表了服務器在處理請求的過程中有錯誤或者異常狀態發生，也有可能是服務器意識到以當前的軟硬件資源無法完成對請求的處理。除非這是一個HEAD請求，否則服務器應當包含一個解釋當前錯誤狀態以及這個狀況是臨時的還是永久的解釋信息實體。瀏覽器應當向用戶展示任何在當前響應中被包含的實體。

這些狀態碼適用於任何響應方法。

500 Internal Server Error

服務器遇到了一個未曾預料的狀況，導致了它無法完成對請求的處理。一般來說，這個問題都會在服務器的程序碼出錯時出現。

501 Not Implemented

服務器不支持當前請求所需要的某個功能。當服務器無法識別請求的方法，並且無法支持其對任何資源的請求。

502 Bad Gateway

作為 網關或者 代理工作的服務器嘗試執行請求時，從上游服務器接收到無效的響應。

503 Service Unavailable

由於臨時的服務器維護或者 過載，服務器當前無法處理請求。這個狀況是臨時的，並且將在一段時間以后恢復。如果能夠預計延遲時間，那么響應中可以包含一個Retry-After頭用以標明這個延遲時間。如果沒有給出這個Retry-After信息，那么客戶端應當以處理 500響應的方式處理它。

504 Gateway Timeout

作為網關或者代理工作的服務器嘗試執行請求時，未能及時從上游服務器（URI標識出的服務器，例如 HTTP、 FTP、 LDAP）或者輔助服務器（例如 DNS）收到響應。

注意：某些代理服務器在DNS查詢 超時時會返回 400或者 500錯誤。

505 HTTP Version Not Supported

服務器不支持，或者拒絕支持在請求中使用的HTTP版本。這暗示着服務器不能或不願使用與客戶端相同的版本。響應中應當包含一個描述了為何版本不被支持以及服務器支持哪些協議的實體。

506 Variant Also Negotiates

由《透明內容協商協議》（ RFC 2295）擴展，代表服務器存在內部配置錯誤：被請求的協商變元資源被配置為在透明內容協商中使用自己，因此在一個協商處理中不是一個合適的重點。

507 Insufficient Storage

服務器無法存儲完成請求所必須的內容。這個狀況被認為是臨時的。（ WebDAV  RFC 4918）

509 Bandwidth Limit Exceeded

服務器達到 帶寬限制。這不是一個官方的狀態碼，但是仍被廣泛使用。

510 Not Extended

獲取資源所需要的策略並沒有被滿足。（ RFC 2774）

基本格式[編輯]

協議頭的字段，是在請求（request）或回復（response）那一行（這是一條消息的第一行內容）內容之后傳輸的。協議頭的字段，是以明文的字符串格式傳輸的，以冒號分隔的鍵名/值對，最后以回車(CR)和換行(LF)符序列結尾。協議 頭部分的結束，是以一個空白的字段來標識的，結果就是，會傳輸兩個連續的回車換行符對。 在歷史上，曾經會將狠長的文字行以多個短行的形式傳輸； 在下一行的開頭，輸出一個空格(SP)或者一個水平制表符(HT)，表示它是一個后續行。如今， 這種換行形式已經廢棄了^[1]。

字段名[編輯]

在由互聯網工程任務組 (IETF)發行的征求修正意見書 7231 中，對一組核心的字段進行了標准化。 有一份對於這些字段的官方的登記冊，以及 一系列的補充規范 ，由互聯網號碼分配局（IANA）維護。各個應用程序 也可以自行定義額外的字段名字及相應的值。

協議頭的固定登記冊和臨時注冊倉庫是由互聯網號碼分配局維護的。 按照慣例 ，對於非標准的協議頭字段， 是在字段名字前面加上 X- 前綴來標識的。 然而 ，這一慣例在2012 年六月被廢棄了，因為 ，按照這種慣例， 當非標准字段變成標准字段時，會引起很多不方便之處。 之前曾有的，對於 Downgraded- 的使用限制，也被取消了。

字段值[編輯]

某些字段 中可以包含注釋內容 ( 也就是說，在 User-Agent 、 Server 、 Via字段 中 ) ， 這些注釋內容可被應用程序忽略。

很多字段值中都會帶有帶權重的（quality ( q )）鍵值對， 這種權重會在 內容協商 的過程 中使用。

大小限制[編輯]

標准 中沒有針對每個協議頭字段的名字和值的尺寸設置任何限制， 也沒有限制字段的個數。然而 ，出於實際場景及安全性的考慮，大部分的服務器、客戶端和代理軟件都會實施一些限制。例如， 阿帕奇（Apache）2.3 服務器， 在默認情況下， 會限制每個字段的尺寸不超過 8190字節 ， 同時，單個請求中最多可以有 100 個協議頭字段^[2]。  

請求字段[編輯]

協議頭字段名	說明	示例	狀態
Accept	能夠接受的回應內容類型（Content-Types）。參見內容協商。	Accept: text/plain	Permanent
Accept-Charset	能夠接受的字符集	Accept-Charset: utf-8	Permanent
Accept-Encoding	能夠接受的編碼方式列表。參考 超文本傳輸協議壓縮 。	Accept-Encoding: gzip, deflate	Permanent
Accept-Language	能夠接受的回應內容的自然語言列表。參考 內容協商 。	Accept-Language: en-US	Permanent
Accept-Datetime	能夠接受的按照時間來表示的版本	Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT	Provisional
Authorization	用於超文本傳輸協議的認證的認證信息	Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==	Permanent
Cache-Control	用來指定在這次的請求/回復鏈中的所有緩存機制 都必須 遵守的指令	Cache-Control: no-cache	Permanent
Connection	該瀏覽器想要優先使用的連接類型 [3]	Connection: keep-alive Connection: Upgrade	Permanent
Cookie	之前由服務器通過 Set- Cookie （下文詳述）發送的一個 超文本傳輸協議Cookie	Cookie: $Version=1; Skin=new;	Permanent: standard
Content-Length	以 八位字節數組 （8位的字節）表示的請求體的長度	Content-Length: 348	Permanent
Content-MD5	請求體的內容的二進制 MD5 散列值，以 Base64 編碼的結果	Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==	Obsolete[4]
Content-Type	請求體的 多媒體類型 （用於POST和PUT請求中）	Content-Type: application/x-www-form-urlencoded	Permanent
Date	發送該消息的日期和時間(按照 RFC 7231 中定義的"超文本傳輸協議日期"格式來發送)	Date: Tue, 15 Nov 1994 08:12:31 GMT	Permanent
Expect	表明客戶端要求服務器做出特定的行為	Expect: 100-continue	Permanent
From	發起此請求的用戶的郵件地址	From: [e-mail]	Permanent
Host	服務器的域名(用於 虛擬 主機 )，以及服務器所監聽的 傳輸控制協議端口 號。如果所請求的端口是對應的服務的標准端口，則 端口 號可被省略。  [5] 自超文件傳輸協議版本1.1（HTTP/1.1）開始便是必需字段。	Host: en.wikipedia.org:80 Host: en.wikipedia.org	Permanent
If-Match	僅當客戶端提供的實體與服務器上對應的實體相匹配時，才進行對應的操作。主要作用時，用作像 PUT 這樣的方法中，僅當從用戶上次更新某個資源以來，該資源未被修改的情況下，才更新該資源。	If-Match: "737060cd8c284d8af7ad3082f209582d"	Permanent
If-Modified-Since	允許在對應的內容未被修改的情況下返回304未修改（ 304 Not Modified ）	If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT	Permanent
If-None-Match	允許在對應的內容未被修改的情況下返回304未修改（ 304 Not Modified ），參考 超文本傳輸協議 的實體標記	If-None-Match: "737060cd8c284d8af7ad3082f209582d"	Permanent
If-Range	如果該實體未被修改過，則向我發送我所缺少的那一個或多個部分；否則，發送整個新的實體	If-Range: "737060cd8c284d8af7ad3082f209582d"	Permanent
If-Unmodified-Since	僅當該實體自某個特定時間已來未被修改的情況下，才發送回應。	If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT	Permanent
Max-Forwards	限制該消息可被代理及網關轉發的次數。	Max-Forwards: 10	Permanent
Origin	發起一個針對 跨來源資源共享 的請求（要求服務器在回應中加入一個‘訪問控制-允許來源’（'Access-Control-Allow-Origin'）字段）。	Origin: http://www.example-social-network.com	Permanent: standard
Pragma	與具體的實現相關，這些字段可能在請求/回應鏈中的任何時候產生 多種效果。	Pragma: no-cache	Permanent
Proxy-Authorization	用來向代理進行認證的認證信息。	Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==	Permanent
Range	僅請求某個實體的一部分。字節偏移以0開始。參考 字節服務 。	Range: bytes=500-999	Permanent
Referer [sic]	表示瀏覽器所訪問的前一個頁面，正是那個頁面上的某個鏈接將瀏覽器帶到了當前所請求的這個頁面。(“引導者”（“referrer”）這個單詞，在RFC 中被拼錯了，因此在大部分的軟件實現中也拼錯了，以至於，錯誤的拼法成為了標准的用法，還被當成了正確的術語)	Referer: http://en.wikipedia.org/wiki/Main_Page	Permanent
TE	瀏覽器預期接受的傳輸編碼方式：可使用回應協議頭Transfer-Encoding 字段中的那些值，另外還有一個值可用，"trailers"（與" 分 塊 "傳輸方式相關），用來表明，瀏覽器希望在最后一個尺寸為0的塊之后還接收到一些額外的字段。	TE: trailers, deflate	Permanent
User-Agent	瀏覽器的瀏覽器身份標識字符串	User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/21.0	Permanent
Upgrade	要求服務器升級到另一個協議。	Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11	Permanent
Via	向服務器告知，這個請求是由哪些代理發出的。	Via: 1.0 fred, 1.1 example.com (Apache/1.1)	Permanent
Warning	一個一般性的警告，告知，在實體內容體中可能存在錯誤。	Warning: 199 Miscellaneous warning	Permanent

常見的非標准請求字段[編輯]

字段名	說明	示例
X-Requested-With	主要用於標識 Ajax 及可擴展標記語言 請求。大部分的 爪哇腳本框架 會發送這個字段，且將其值設置為 XMLHttpRequest	X-Requested-With: XMLHttpRequest
DNT[6]	請求某個網頁應用程序停止跟蹤某個用戶。在火狐瀏覽器中，相當於X-Do-Not-Track協議頭字段(自 火狐4.0 測試（Beta） 11版開始支持)。 Safari 和 Internet Explorer 9 也支持這個字段。在2011 年三月7 日，有人向互聯網工程任務組提交了一個草案。  [7] 萬維網協會 的跟蹤保護工作組正在就此制作一項規范。[8]	DNT: 1 (Do Not Track Enabled) DNT: 0 (Do Not Track Disabled)
X-Forwarded-For[9]	一個事實標准 ，用於標識某個通過超文本傳輸協議代理或負載均衡連接到某個網頁服務器的客戶端的原始互聯網地址	X-Forwarded-For: client1, proxy1, proxy2 X-Forwarded-For: 129.78.138.66, 129.78.64.103
X-Forwarded-Host[10]	a de facto standard for identifying the original host requested by the client in the Host HTTP request header, since the host name and/or port of the reverse proxy (load balancer) may differ from the origin server handling the request.	X-Forwarded-Host: en.wikipedia.org:80 X-Forwarded-Host: en.wikipedia.org
X-Forwarded-Proto[11]	一個事實標准 用於標識某個超文本傳輸協議請求最初所使用的協議，因為，在反向代理(負載均衡)上，即使最初發往該反向代理的請求類型是安全的超文本傳輸協議（HTTPS），該反向代理也仍然可能會使用超文本傳輸協議（HTTP）來與網頁服務器通信。谷歌客戶端在與谷歌服務器通信時會使用該協議頭的一個替代形式（X-ProxyUser-Ip）。	X-Forwarded-Proto: https
Front-End-Https[12]	Non-standard header field used by Microsoft applications and load-balancers	Front-End-Https: on
X-Http-Method-Override[13]	請求某個網頁應用程序使用該協議頭字段中指定的方法（一般是PUT或DELETE）來覆蓋掉在請求中所指定的方法（一般是POST）。當某個瀏覽器或防火牆阻止直接發送PUT 或DELETE 方法時（注意，這可能是因為軟件中的某個漏洞，因而需要修復，也可能是因為某個配置選項就是如此要求的，因而不應當設法繞過），可使用這種方式。	X-HTTP-Method-Override: DELETE
X-ATT-DeviceId[14]	Allows easier parsing of the MakeModel/Firmware that is usually found in the User-Agent String of AT&T Devices	X-Att-Deviceid: GT-P7320/P7320XXLPG
X-Wap-Profile[15]	Links to an XML file on the Internet with a full description and details about the device currently connecting. In the example to the right is an XML file for an AT&T Samsung Galaxy S2.	x-wap-profile:http://wap.samsungmobile.com/uaprof/SGH-I777.xml
Proxy-Connection[16]	因為對超文本傳輸協議規范的誤解而實現的一個協議頭。因為早期超文本傳輸協議版本實現中的錯誤而出現。與標准的連接（Connection）字段的功能完全相同。	Proxy-Connection: keep-alive
X-UIDH[17][18][19]	Server-side deep packet insertion of a unique ID identifying customers of Verizon Wireless; also known as "perma-cookie" or "supercookie"	X-UIDH: ...
X-Csrf-Token[20]	Used to prevent cross-site request forgery. Alternative header names are: X-CSRFToken[21] and X-XSRF-TOKEN[22]	X-Csrf-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql

回應字段[編輯]

Field name	Description	Example	Status
Access-Control-Allow-Origin	指定哪些網站可參與到 跨來源資源共享 過程中	Access-Control-Allow-Origin: *	Provisional
Accept-Patch[23]	Specifies which patch document formats this server supports	Accept-Patch: text/example;charset=utf-8	Permanent
Accept-Ranges	這個服務器支持哪些種類的部分內容范圍	Accept-Ranges: bytes	Permanent
Age	這個對象在 代理緩存 中存在的時間，以秒為單位	Age: 12	Permanent
Allow	對於特定資源有效的動作。針對405不允許該方法（ 405 Method not allowed ）而使用	Allow: GET, HEAD	Permanent
Cache-Control	向從服務器直到客戶端在內的所有緩存機制告知，它們是否可以緩存這個對象。其單位為秒	Cache-Control: max-age=3600	Permanent
Connection	針對該連接所預期的選項 [3]	Connection: close	Permanent
Content-Disposition[24]	An opportunity to raise a "File Download" dialogue box for a known MIME type with binary format or suggest a filename for dynamic content. Quotes are necessary with special characters.	Content-Disposition: attachment; filename="fname.ext"	Permanent
Content-Encoding	在數據上使用的編碼類型。參考 超文本傳輸協議壓縮 。	Content-Encoding: gzip	Permanent
Content-Language	內容所使用的語言 [25]	Content-Language: da	Permanent
Content-Length	回應消息體的長度，以 字節 （8位為一字節）為單位	Content-Length: 348	Permanent
Content-Location	所返回的數據的一個候選位置	Content-Location: /index.htm	Permanent
Content-MD5	回應內容的二進制 MD5 散列，以 Base64 方式編碼	Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==	Obsolete[26]
Content-Range	這條部分消息是屬於某條完整消息的哪個部分	Content-Range: bytes 21010-47021/47022	Permanent
Content-Type	當前內容的MIME類型	Content-Type: text/html; charset=utf-8	Permanent
Date	此條消息被發送時的日期和時間(按照 RFC 7231 中定義的“超文本傳輸協議日期”格式來表示)	Date: Tue, 15 Nov 1994 08:12:31 GMT	Permanent
ETag	對於某個資源的某個特定版本的一個標識符，通常是一個 消息散列	ETag: "737060cd8c284d8af7ad3082f209582d"	Permanent
Expires	指定一個日期/時間，超過該時間則認為此回應已經過期	Expires: Thu, 01 Dec 1994 16:00:00 GMT	Permanent: standard
Last-Modified	所請求的對象的最后修改日期(按照 RFC 7231 中定義的“超文本傳輸協議日期”格式來表示)	Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT	Permanent
Link	用來表達與另一個資源之間的類型關系，此處所說的類型關系是在 RFC 5988 中定義的	Link: </feed>; rel="alternate"[27]	Permanent
Location	用來 進行 重定向 ，或者在創建了某個新資源時使用。	Location: http://www.w3.org/pub/WWW/People.html	Permanent
P3P	This field is supposed to set P3P policy, in the form ofP3P:CP="your_compact_policy". However, P3P did not take off,[28] most browsers have never fully implemented it, a lot of websites set this field with fake policy text, that was enough to fool browsers the existence of P3P policy and grant permissions for third party cookies.	P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."	Permanent
Pragma	與具體的實現相關，這些字段可能在請求/回應鏈中的任何時候產生多種效果。	Pragma: no-cache	Permanent
Proxy-Authenticate	要求在訪問代理時提供身份認證信息。	Proxy-Authenticate: Basic	Permanent
Public-Key-Pins[29]	用於緩解 中間人攻擊 ，聲明網站的認證用的 傳輸 層安全協議 證書的散列值	Public-Key-Pins: max-age=2592000; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";	Permanent
Refresh	Used in redirection, or when a new resource has been created. This refresh redirects after 5 seconds.	Refresh: 5; url=http://www.w3.org/pub/WWW/People.html	Proprietary and non-standard: a header extension introduced by Netscape and supported by most web browsers.
Retry-After	如果某個實體臨時不可用，則，此協議頭用來告知客戶端日后重試。其值可以是一個特定的時間段(以秒為單位)或一個超文本傳輸協議日期。 [30]	Example 1: Retry-After: 120 Example 2: Retry-After: Fri, 07 Nov 2014 23:59:59 GMT	Permanent
Server	服務器的名字	Server: Apache/2.4.1 (Unix)	Permanent
Set-Cookie	HTTP cookie	Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1	Permanent: standard
Status	通用網關接口 協議頭字段，用來說明當前這個超文本傳輸協議回應的 狀態 。普通的超文本傳輸協議回應，會使用單獨的“狀態行”（"Status-Line"）作為替代，這一點是在 RFC 7230 中定義的。  [31]	Status: 200 OK	Not listed as aregistered field name
Strict-Transport-Security	A HSTS Policy informing the HTTP client how long to cache the HTTPS only policy and whether this applies to subdomains.	Strict-Transport-Security: max-age=16070400; includeSubDomains	Permanent: standard
Trailer	The Trailer general field value indicates that the given set of header fields is present in the trailer of a message encoded with chunked transfer coding.	Trailer: Max-Forwards	Permanent
Transfer-Encoding	用來將實體安全地傳輸給用戶的編碼形式。 當前定義 的方法 包括： 分 塊 、壓縮（compress）、縮小（deflate）、壓縮（gzip）、實體（identity）。	Transfer-Encoding: chunked	Permanent
Upgrade	要求客戶端升級到另一個協議。	Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11	Permanent
Vary	告知下游的代理服務器，應當如何對未來的請求協議頭進行匹配，以決定是否可使用已緩存的回應內容而不是重新從原始服務器請求新的內容。	Vary: *	Permanent
Via	告知代理服務器的客戶端，當前回應是通過什么途徑發送的。	Via: 1.0 fred, 1.1 example.com (Apache/1.1)	Permanent
Warning	一般性的警告，告知在實體內容體中可能存在錯誤。	Warning: 199 Miscellaneous warning	Permanent
WWW-Authenticate	表明在請求獲取這個實體時應當使用的認證模式。	WWW-Authenticate: Basic	Permanent
X-Frame-Options[32]	Clickjacking protection: deny - no rendering within a frame,sameorigin - no rendering if origin mismatch, allow-from - allow from specified location, allowall - non-standard, allow from any location	X-Frame-Options: deny	Obsolete[33]

常見的非標准回應字段[編輯]

字段名	說明	示例
X-XSS-Protection[34]	跨站腳本攻擊 (XSS)過濾器	X-XSS-Protection: 1; mode=block
Content-Security-Policy,X-Content-Security-Policy,X-WebKit-CSP[35]	內容安全策略定義。	X-WebKit-CSP: default-src 'self'
X-Content-Type-Options[36]	The only defined value, "nosniff", prevents Internet Explorer from MIME-sniffing a response away from the declared content-type. This also applies to Google Chrome, when downloading extensions.[37]	X-Content-Type-Options: nosniff
X-Powered-By[38]	表明用於支持當前網頁應用程序的技術（例如PHP）（版本號細節通常放置在 X-Runtime 或 X-Version 中）	X-Powered-By: PHP/5.4.0
X-UA-Compatible[39]	Recommends the preferred rendering engine (often a backward-compatibility mode) to use to display the content. Also used to activate Chrome Frame in Internet Explorer.	X-UA-Compatible: IE=EmulateIE7 X-UA-Compatible: IE=edge X-UA-Compatible: Chrome=1
X-Content-Duration[40]	Provide the duration of the audio or video in seconds; only supported by Gecko browsers	X-Content-Duration: 42.666

參考文獻[編輯]