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: user@example.com	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

參考文獻[編輯]