記錄 ---- HTTP報文

HTTP報文

報文是如何流動的

HTTP報文是在HTTP應用程序之間發送的數據塊。這些數據塊以一些文本形式的元信息(meta-information)開頭，這些信息描述了報文的內容及含義，後面跟着可選的數據部分。這些報文在客戶端、服務器和代理之間流動。術語"流入"、"流出"、"上游"及"下游"都是用來描述報文方向的。

HTTP使用術語流入(inbound)和流出(outbound)來描述事務處理(transaction)的方向。報文流入源端服務器，工做完成以後，會流回用戶的Agent代理中。無論是請求報文仍是響應報文，全部報文都會向下游(downstream)流動。全部報文的發送者都在接收者的上游(upstream)。

HTTP報文的語法和組成部分

HTTP報文是簡單的格式化數據塊。每條報文都包含一條來自客戶端的請求，或者一條來自服務器的響應。它們由三個部分組成：對報文進行描述的起始行(start line)、包含屬性的首部(header)塊，以及可選的、包含數據的主體(body)部分。

起始行和首部就是由行分隔的ASCII文本。每行都以一個由兩個字符組成的行終止序列做爲結束，其中包括一個回車符和一個換行符。這個行終止序列能夠寫作CRLF。須要指出的是，儘管HTTP規範中說明應該用CRLF來表示行終止，但穩健的應用程序也應該接受單個換行符做爲行的終止。有些老的，或不完整的HTTP應用程序並不老是既發送回車符，又發送換行符。實體的主體或報文的主體(或者就稱爲主體)是一個可選的數據塊。與起始行和首部不一樣的是，主體中能夠包含文本或二進制數據，也能夠爲空。

語法

請求和響應報文之間的區別：全部的HTTP報文均可以分爲兩類：請求報文(request message)和響應報文(response message)。請求報文會向Web服務器請求一個動做。響應報文會將請求的結果返回給客戶端。請求和響應報文的基本報文結構相同。

# 請求報文
<method> <request-URL> <version>
<headers>

<entity-body>

# 響應報文
<version> <status> <reason-phrase>
<headers>

<entity-body>

# 只有起始行的語法有所不一樣

• 方法(method)：客戶端但願服務器對資源執行的動做。是一個單獨的詞，好比GET、HEAD或POST等。
• 請求URL(request-URL)：命名了所請求資源，或者URL路徑組件的完整URL。若是直接與服務器進行對話，只要URL的路徑組件是資源的絕對路徑，一般就不會有什麼問題——服務器能夠假定本身是URL的主機 / 端口。
• 版本(version)：報文所使用的 HTTP 版本，其中主要版本號(major)和次要版本號(minor)都是整數。
• 狀態碼(status-code)：這三位數字描述了請求過程當中所發生的狀況。每一個狀態碼的第一位數字都用於描述狀態的通常類別("成功"、"出錯"等)。
• 緣由短語(reason-phrase)：數字狀態碼的可讀版本，包含行終止序列以前的全部文本。緣由短語只對人類有意義，所以，好比說，儘管響應行"HTTP/1.0 200 NOT OK"和"HTTP/1.0 200 OK"中緣由短語的含義不一樣，但一樣都會被看成成功指示處理。
• 首部(header)：能夠有零個或多個首部，每一個首部都包含一個名字，後面跟着一個冒號(:)，而後是一個可選的空格，接着是一個值，最後是一個CRLF。首部是由一個空行(CRLF)結束的，表示了首部列表的結束和實體主體部分的開始。有些 HTTP 版本，好比HTTP/1.1，要求有效的請求或響應報文中必須包含特定的首部。
• 實體的主體部分(entity-body)：實體的主體部分包含一個由任意數據組成的數據塊。並非全部的報文都包含實體的主體部分，有時，報文只是以一個CRLF結束。

注意：一組HTTP首部老是應該以一個空行(僅CRLF)結束，甚至即便沒有首部和實體的主體部分也應如此。但因爲歷史緣由，不少客戶端和服務器都在沒有實體的主體部分時，(錯誤地)省略了最後的CRLF。爲了與這些流行但不符合規則的實現進行互通，客戶端和服務器都應該接受那些沒有最後那個CRLF的報文。

起始行

全部的HTTP報文都以一個起始行做爲開始。請求報文的起始行說明了要作些什麼。響應報文的起始行說明發生了什麼。

• 請求行：請求報文請求服務器對資源進行一些操做。請求報文的起始行，或稱爲請求行，包含了一個方法和一個請求URL，這個方法描述了服務器應該執行的操做，請求URL描述了要對哪一個資源執行這個方法。請求行中還包含 HTTP 的版本，用來告知服務器，客戶端使用的是哪一種HTTP。全部這些字段都由空格符分隔。在 HTTP/1.0 以前，並不要求請求行中包含 HTTP 版本號。
• 響應行：響應報文承載了狀態信息和操做產生的全部結果數據，將其返回給客戶端。響應報文的起始行，或稱爲響應行，包含了響應報文使用的HTTP版本、數字狀態碼，以及描述操做狀態的文本形式的緣由短語。全部這些字段都由空格符進行分隔。在 HTTP/1.0 以前，並不要求在響應中包含響應行。
• 方法：請求的起始行以方法做爲開始，方法用來告知服務器要作些什麼。HTTP規範中定義了一組經常使用的請求方法。好比，GET方法負責從服務器獲取一個文檔，POST方法會向服務器發送須要處理的數據，OPTIONS方法用於肯定Web服務器的通常功能，或者Web服務器處理特定資源的能力。注意，有些方法的請求報文中有主體，有些則是無主體的請求。並非全部服務器都實現了全部的7種方法。並且，因爲HTTP設計得易於擴展，因此除了這些方法以外，其餘服務器可能還會實現一些本身的請求方法。這些附加的方法是對 HTTP 規範的擴展，所以被稱爲擴展方法。
• 狀態碼：方法是用來告訴服務器作什麼事情的，狀態碼則用來告訴客戶端，發生了什麼事情。狀態碼位於響應的起始行中。客戶端向一個HTTP服務器發送請求報文時，會發生不少事情。幸運的話，請求會成功完成。但你不會老是那麼幸運的。服務器可能會告訴你沒法找到所請求的資源，你沒有訪問資源的權限，或者資源被移到了其餘地方。狀態碼是在每條響應報文的起始行中返回的。會返回一個數字狀態和一個可讀的狀態。數字碼便於程序進行差錯處理，而緣由短語則更便於人們理解。能夠經過三位數字代碼對不一樣狀態碼進行分類。200到299之間的狀態碼錶示成功。300到399之間的代碼表示資源已經被移走了。400到499之間的代碼表示客戶端的請求出錯了。500到599之間的代碼表示服務器出錯了。當前的HTTP版本只爲每類狀態定義了幾個代碼。隨着協議的發展，HTTP規範中會正式地定義更多的狀態碼。若是收到了不認識的狀態碼，多是有人將其做爲當前協議的擴展定義的。能夠根據其所處範圍，將它做爲那個類別中一個普通的成員來處理。
• 緣由短語：緣由短語是響應起始行中的最後一個組件。它爲狀態碼提供了文本形式的解釋。緣由短語和狀態碼是成對出現的。緣由短語是狀態碼的可讀版本，應用程序開發者將其傳送給用戶，用以說明在請求期間發生了什麼狀況。HTTP規範並無提供任何硬性規定，要求緣由短語以何種形式出現。
• 版本號：版本號會以"HTTP/x.y"的形式出如今請求和響應報文的起始行中。爲HTTP應用程序提供了一種將本身所遵循的協議版本告知對方的方式。使用版本號的目的是爲使用HTTP的應用程序提供一種線索，以便互相瞭解對方的能力和報文格式。在與使用"HTTP 1.1"的應用程序進行通訊的"HTTP 1.2"應用程序應該知道，它不能使用任何新的1.2特性，由於使用老版本協議的應用程序極可能沒法實現這些特性。版本號說明了應用程序支持的最高HTTP版本。但"HTTP/1.0"應用程序在解釋包含"HTTP/1.1"的響應時，會認爲這個響應是個1.1響應，而實際上這只是響應應用程序所使用的協議等級，在這些狀況下，版本號會在應用程序之間形成誤解 。

首部

跟在起始行後面的就是零個、一個或多個HTTP首部字段。HTTP首部字段向請求和響應報文中添加了一些附加信息。本質上來講，它們只是一些鍵/值對的列表。

首部分類：HTTP規範定義了幾種首部字段。應用程序也能夠隨意發明本身所用的首部。每一個HTTP首部都有一種簡單的語法：名字後面跟着冒號(:)，而後跟上可選的空格，再跟上字段值，最後是一個CRLF。HTTP 首部能夠分爲如下幾類。

• 通用首部：既能夠出如今請求報文中，也能夠出如今響應報文中。
• 請求首部：提供更多有關請求的信息。
• 響應首部：提供更多有關響應的信息。
• 實體首部：描述主體的長度和內容，或者資源自身。
• 擴展首部：規範中沒有定義的新首部。

首部延續行：將長的首部行分爲多行能夠提升可讀性，多出來的每行前面至少要有一個空格或製表符(tab)。

實體的主體部分

HTTP報文的第三部分是可選的實體主體部分。實體的主體是HTTP報文的負荷。就是HTTP要傳輸的內容。HTTP報文能夠承載不少類型的數字數據：圖片、視頻、HTML文檔、軟件應用程序、信用卡事務、電子郵件等。

請求報文支持的各類功能(方法)

方法	描述	是否包含主體
GET	從服務器獲取一份文檔	否
HEAD	只從服務器獲取文檔的首部	否
POST	向服務器發送須要處理的數據	是
PUT	將請求的主體部分存儲在服務器上	是
TRACE	對可能通過代理服務器傳送到服務器上去的報文進行追蹤	否
OPTIONS	決定能夠在服務器上執行哪些方法	否
DELETE	從服務器上刪除一份文檔	否

注意：並非每一個服務器都實現了全部的方法。若是一臺服務器要與"HTTP 1.1"兼容，那麼只要爲其資源實現GET方法和HEAD方法就能夠了。即便服務器實現了全部這些方法，這些方法的使用極可能也是受限的。例如，支持 DELETE 方法或 PUT 方法的服務器可能並不但願任何人都可以刪除或存儲資源。這些限制一般都是在服務器的配置中進行設置的，所以會隨着站點和服務器的不一樣而有所不一樣。

安全的方法：HTTP 定義了一組被稱爲安全方法的方法。GET方法和HEAD方法都被認爲是安全的，這就意味着使用GET或HEAD方法的HTTP請求都不會產生什麼動做。不產生動做，在這裏意味着HTTP請求不會在服務器上產生什麼結果。安全方法並不必定是什麼動做都不執行的(實際上，這是由Web開發者決定的)。使用安全方法的目的就是當使用可能引起某一動做的不安全方法時，容許HTTP應用程序開發者通知用戶。

• GET：GET是最經常使用的方法。一般用於請求服務器發送某個資源。

• HEAD：HEAD方法與GET方法的行爲很相似，但服務器在響應中只返回首部。不會返回實體的主體部分。這就容許客戶端在未獲取實際資源的狀況下，對資源的首部進行檢查。服務器開發者必須確保返回的首部與GET請求所返回的首部徹底相同。使用HEAD，能夠：

  • 在不獲取資源的狀況下了解資源的狀況（好比，判斷其類型）；
  • 經過查看響應中的狀態碼，看看某個對象是否存在；
  • 經過查看首部，測試資源是否被修改了。
• PUT：與GET從服務器讀取文檔相反，PUT方法會向服務器寫入文檔。有些發佈系統容許用戶建立Web頁面，並用PUT直接將其安裝到Web服務器上去。PUT方法的語義就是讓服務器用請求的主體部分來建立一個由所請求的URL命名的新文檔，或者，若是那個URL已經存在的話，就用這個主體來替代它。由於PUT容許用戶對內容進行修改，因此不少Web服務器都要求在執行PUT以前，用密碼登陸。
• POST：POST方法起初是用來向服務器輸入數據的。實際上，一般會用它來支持HTML的表單。表單中填好的數據一般會被送給服務器，而後由服務器將其發送到它要去的地方(好比，送到一個服務器網關程序中，而後由這個程序對其進行處理)。
• TRACE：客戶端發起一個請求時，這個請求可能要穿過防火牆、代理、網關或其餘一些應用程序。每一箇中間節點均可能會修改原始的HTTP請求。TRACE方法容許客戶端在最終將請求發送給服務器時，看看它變成了什麼樣子。TRACE請求會在目的服務器端發起一個"環回"診斷。行程最後一站的服務器會彈回一條TRACE響應，並在響應主體中攜帶它收到的原始請求報文。這樣客戶端就能夠查看在全部中間HTTP應用程序組成的請求/響應鏈上，原始報文是否，以及如何被毀壞或修改過。TRACE方法主要用於診斷；也就是說，用於驗證請求是否如願穿過了請求/響應鏈。它也是一種很好的工具，能夠用來查看代理和其餘應用程序對用戶請求所產生效果。儘管TRACE能夠很方便地用於診斷，但它確實也有缺點，它假定中間應用程序對各類不一樣類型請求(不一樣的方法——GET、HEAD、POST等)的處理是相同的。不少HTTP應用程序會根據方法的不一樣作出不一樣的事情——好比，代理可能會將POST請求直接發送給服務器，而將GET請求發送給另外一個HTTP應用程序(好比Web緩存)。TRACE並不提供區分這些方法的機制。一般，中間應用程序會自行決定對TRACE請求的處理方式。TRACE請求中不能帶有實體的主體部分。TRACE響應的實體主體部分包含了響應服務器收到的請求的精確副本。
• OPTIONS：OPTIONS方法請求Web服務器告知其支持的各類功能。能夠詢問服務器一般支持哪些方法，或者對某些特殊資源支持哪些方法。(有些服務器可能只支持對一些特殊類型的對象使用特定的操做)。這爲客戶端應用程序提供了一種手段，使其不用實際訪問那些資源就能斷定訪問各類資源的最優方式。
• DELETE：顧名思義，DELETE方法所作的事情就是請服務器刪除請求URL所指定的資源。可是，客戶端應用程序沒法保證刪除操做必定會被執行。由於HTTP規範容許服務器在不通知客戶端的狀況下撤銷請求。

擴展方法：HTTP被設計成字段可擴展的，這樣新的特性就不會使老的軟件失效了。擴展方法指的就是沒有在"HTTP/1.1"規範中定義的方法。服務器會爲它所管理的資源實現一些HTTP服務，這些方法爲開發者提供了一種擴展這些HTTP服務能力的手段。並非全部的擴展方法都是在正式規範中定義的，認識到這一點很重要。若是你定義了一個擴展方法，極可能大部分HTTP應用程序都沒法理解。一樣，你的HTTP應用程序也可能會遇到一些其餘應用程序在用的，而它並不理解的擴展方法。在這些狀況下，最好對擴展方法寬容一些。若是可以在不破壞端到端行爲的狀況下將帶有未知方法的報文傳遞給下游服務器的話，代理應嘗試傳遞這些報文。若是可能破壞端到端行爲，則應以"501 Not Implemented(沒法實現)"狀態碼進行響應。最好按慣例"對所發送的內容要求嚴一點，對所接收的內容寬容一些"來處理擴展方法(以及通常的HTTP擴展)。

和響應報文一塊兒返回的各類狀態碼

總體範圍	已定義範圍	分類
100～199	100～101	信息提示
200～299	200～206	成功
300～399	300～305	重定向
400～499	400～415	客戶端錯誤
500～599	500～505	服務器錯誤

HTTP狀態碼被分紅了五大類。狀態碼爲客戶端提供了一種理解事務處理結果的便捷方式。儘管並無實際的規範對緣由短語的確切文本進行說明。

100～199 --- 信息性狀態碼

HTTP/1.1 向協議中引入了信息性狀態碼。這些狀態碼相對較新，關於其複雜性和感知價值存在一些爭議。

狀態碼	緣由短語	含義
100	Continue	說明收到了請求的初始部分，請客戶端繼續。發送了這個狀態碼以後，服務器在收到請求以後必須進行響應。
101	Switching Protocols	說明服務器正在根據客戶端的指定，將協議切換成Update首部所列的協議

"100 Continue"狀態碼尤爲讓人糊塗。它的目的是對這樣的狀況進行優化：HTTP客戶端應用程序有一個實體的主體部分要發送給服務器，但但願在發送以前查看一下服務器是否會接受這個實體。這可能會給HTTP程序員帶來一些困擾，所以在這裏進行了比較詳細(它如何與客戶端、服務器和代理進行通訊)的討論。

• 客戶端與"100 Continue"：若是客戶端在向服務器發送一個實體，而且願意在發送實體以前等待"100 Continue"響應，那麼，客戶端就要發送一個攜帶了值爲"100 Continue"的""Expect"請求首部。若是客戶端沒有發送實體，就不該該發送"100 Continue Expect"首部，由於這樣會使服務器誤覺得客戶端要發送一個實體。從不少方面來看，"100 Continue"都是一種優化。客戶端應用程序只有在避免向服務器發送一個服務器沒法處理或使用的大實體時，才應該使用"100 Continue"。因爲起初對"100 Continue"狀態存在一些困惑，所以發送了值爲"100 Continue"的"Expect"首部的客戶端不該該永遠在那兒等待服務器發送"100 Continue"響應。超時必定時間以後，客戶端應該直接將實體發送出去。實際上，客戶端程序的實現者也應該作好應對非預期"100 Continue"響應的準備。有些出錯的 HTTP 應用程序會不合時宜地發送這個狀態碼。
• 服務器與"100 Continue"：若是服務器收到了一條帶有值爲"100 Continue"的"Expect"首部的請求，它會用"100 Continue"響應或一條錯誤碼來進行響應。服務器永遠也不該該向沒有發送"100 Continue"指望的客戶端發送"100 Continue"狀態碼。但如前所述，有些出錯的服務器可能會這麼作。若是出於某種緣由，服務器在有機會發送"100 Continue"響應以前就收到了部分(或所有)的實體，就說明客戶端已經決定繼續發送數據了，這樣，服務器就不須要發送這個狀態碼了。但服務器讀完請求以後，仍是應該爲請求發送一個最終狀態碼(它能夠跳過"100 Continue"狀態)。最後，若是服務器收到了帶有"100 Continue"指望的請求，並且它決定在讀取實體的主體部分以前(好比，由於出錯而)結束請求，就不該該僅僅是發送一條響應並關閉鏈接，由於這樣會妨礙客戶端接收響應。
• 代理與"100 Continue"：若是代理從客戶端收到了一條帶有"100 Continue"指望的請求，它須要作幾件事情。若是代理知道下一跳服務器是"HTTP/1.1"兼容的，或者並不知道下一跳服務器與哪一個版本兼容，它都應該將"Expect"首部放在請求中向下轉發。若是它知道下一跳服務器只能與"HTTP/1.1"以前的版本兼容，就應該以"417 Expectation Failed"錯誤進行響應。若是代理決定表明與"HTTP/1.0"或以前版本兼容的客戶端，在其請求中放入"Expect"首部和"100 Continue"值，那麼，(若是它從服務器收到了"100 Continue"響應)它就不該該將"100 Continue"響應轉發給客戶端，由於客戶端可能不知道該拿它怎麼辦。代理維護一些有關下一跳服務器及其所支持的HTTP版本的狀態信息(至少要維護那些最近收到過請求的服務器的相關狀態)是有好處的，這樣它們就能夠更好地處理收到的那些帶有"100 Continue"指望的請求了。

200～299 --- 成功狀態碼

客戶端發起請求時，這些請求一般都是成功的。服務器有一組用來表示成功的狀態碼，分別對應於不一樣類型的請求。

狀態碼	緣由短語	含義
200	OK	請求沒問題，實體的主體部分包含了所請求的資源。
201	Created	用於建立服務器對象的請求(好比，PUT)。響應的實體主體部分中應該包含各類引用了已建立的資源的URL，Location首部包含的則是最具體的引用。服務器必須在發送這個狀態碼以前建立好對象。
202	Accepted	請求已被接受，但服務器還未對其執行任何動做。不能保證服務器會完成這個請求；這只是意味着接受請求時，它看起來是有效的。服務器應該在實體的主體部分包含對請求狀態的描述，或許還應該有對請求完成時間的估計(或者包含一個指針，指向能夠獲取此信息的位置)。
203	Non-Authoritative Information	實體首部包含的信息不是來自於源端服務器，而是來自資源的一份副本。若是中間節點上有一份資源副本，但沒法或者沒有對它所發送的與資源有關的元信息(首部)進行驗證，就會出現這種狀況。 這種響應碼並非非用不可的；若是實體首部來自源端服務器，響應爲200狀態的應用程序就能夠將其做爲一種可選項使用。
204	No Content	響應報文中包含若干首部和一個狀態行，但沒有實體的主體部分。主要用於在瀏覽器不轉爲顯示新文檔的狀況下，對其進行更新(好比刷新一個表單頁面)。
205	Reset Content	另外一個主要用於瀏覽器的代碼。負責告知瀏覽器清除當前頁面中的全部HTML表單元素。
206	Partial Content	成功執行了一個部分或Range(範圍)請求。客戶端能夠經過一些特殊的首部來獲取部分或某個範圍內的文檔——這個狀態碼就說明範圍請求成功了。206響應中必須包含Content-Range、Date以及ETag或Content-Location首部。

300～399 --- 重定向狀態碼

重定向狀態碼要麼告知客戶端使用替代位置來訪問他們所感興趣的資源，要麼就提供一個替代的響應而不是資源的內容。若是資源已被移動，可發送一個重定向狀態碼和一個可選的Location首部來告知客戶端資源已被移走，以及如今能夠在哪裏找到它。這樣，瀏覽器就能夠在不打擾使用者的狀況下，透明地轉入新的位置了。能夠經過某些重定向狀態碼對資源的應用程序本地副本與源端服務器上的資源進行驗證。好比，HTTP 應用程序能夠查看其資源的本地副本是否仍然是最新的，或者在源端服務器上資源是否被修改過。總之，在對那些包含了重定向狀態碼的非 HEAD 請求進行響應時，最好要包含一個實體，並在實體中包含描述信息和指向(多個)重定向URL的連接。

狀態碼	緣由短語	含義
300	Multiple Choices	客戶端請求一個實際指向多個資源的URL時會返回這個狀態碼，好比服務器上有某個HTML文檔的英語和法語版本。返回這個代碼時會帶有一個選項列表；這樣用戶就能夠選擇他但願使用的那一項了。有多個版本可用時，客戶端須要溝通解決。服務器能夠在Location首部包含首選URL。
301	Moved Permanently	在請求的URL已被移除時使用。響應的Location首部中應該包含資源如今所處的URL。
302	Found	與301狀態碼相似；可是，客戶端應該使用Location首部給出的URL來臨時定位資源。未來的請求仍應使用老的URL。
303	See Other	告知客戶端應該用另外一個URL來獲取資源。新的URL位於響應報文的Location首部。其主要目的是容許POST請求的響應將客戶端定向到某個資源上去。
304	Not Modified	客戶端能夠經過所包含的請求首部，使其請求變成有條件的。若是客戶端發起了一個條件GET請求，而最近資源未被修改的話，就能夠用這個狀態碼來講明資源未被修改。帶有這個狀態碼的響應不該該包含實體的主體部分。
305	Use Proxy	用來講明必須經過一個代理來訪問資源；代理的位置由Location首部給出。很重要的一點是，客戶端是相對某個特定資源來解析這條響應的，不能假定全部請求，甚至全部對持有所請求資源的服務器的請求都經過這個代理進行。若是客戶端錯誤地讓代理介入了某條請求，可能會引起破壞性的行爲，並且會形成安全漏洞。
307	Temporary Redirect	與301狀態碼相似；但客戶端應該使用Location首部給出的URL來臨時定位資源。未來的請求應該使用老的URL。

30二、303和307狀態碼之間存在一些交叉。這些狀態碼的用法有着細微的差異，大部分差異都源於"HTTP/1.0"和"HTTP/1.1"應用程序對這些狀態碼處理方式的不一樣。當"HTTP/1.0"客戶端發起一個POST請求，並在響應中收到302重定向狀態碼時，它會接受Location首部的重定向URL，並向那個URL發起一個GET請求(而會像原始請求中那樣發起POST請求)。"HTTP/1.0"服務器但願"HTTP/1.0"客戶端這麼作——若是"HTTP/1.0"服務器收到來自"HTTP/1.0"客戶端的POST請求以後發送了302狀態碼，服務器就指望客戶端可以接受重定向URL，並向重定向的URL發送一個GET請求。問題出在"HTTP/1.1"。"HTTP/1.1"規範使用303狀態碼來實現一樣的行爲(服務器發送303狀態碼來重定向客戶端的POST請求，在它後面跟上一個GET請求)。爲了避開這個問題，"HTTP/1.1"規範指出，對於"HTTP/1.1"客戶端，用307狀態碼取代302狀態碼來進行臨時重定向。這樣服務器就能夠將302狀態碼保留起來，爲"HTTP/1.0"客戶端使用了。這樣一來，服務器要選擇適當的重定向狀態碼放入重定向響應中發送，就須要查看客戶端的HTTP版本了。

400～499 --- 客戶端錯誤狀態碼

有時客戶端會發送一些服務器沒法處理的東西，好比格式錯誤的請求報文，或者最多見的是，請求一個不存在的URL。瀏覽網頁時，咱們都看到過臭名昭著的"404 Not Found"錯誤碼——這只是服務器在告訴咱們，它對咱們請求的資源一無所知。不少客戶端錯誤都是由瀏覽器來處理的，甚至不會打擾到你。只有少許錯誤，好比 404，仍是會穿過瀏覽器來到用戶面前。

狀態碼	緣由短語	含義
400	Bad Request	用於告知客戶端它發送了一個錯誤的請求。
401	Unauthorized	與適當的首部一同返回，在這些首部中請求客戶端在獲取對資源的訪問權以前，對本身進行認證。
403	Forbidden	用於說明請求被服務器拒絕了。若是服務器想說明爲何拒絕請求，能夠包含實體的主體部分來對緣由進行描述。但這個狀態碼一般是在服務器不想說明拒絕緣由的時候使用的。
404	Not Found	用於說明服務器沒法找到所請求的URL。一般會包含一個實體，以便客戶端應用程序顯示給用戶看。
405	Method Not Allowed	發起的請求中帶有所請求的URL不支持的方法時，使用此狀態碼。應該在響應中包含Allow首部，以告知客戶端對所請求的資源可使用哪些方法。
406	Not Acceptable	客戶端能夠指定參數來講明它們願意接收什麼類型的實體。服務器沒有與客戶端可接受的URL相匹配的資源時，使用此代碼。一般，服務器會包含一些首部，以便客戶端弄清楚爲何請求沒法知足。
407	Proxy Authentication Required	與401狀態碼相似，但用於要求對資源進行認證的代理服務器。
408	Request Timeout	若是客戶端完成請求所花的時間太長，服務器能夠回送此狀態碼，並關閉鏈接。超時時長隨服務器的不一樣有所不一樣，但一般對全部的合法請求來講，都是夠長的。
409	Conflict	用於說明請求可能在資源上引起的一些衝突。服務器擔憂請求會引起衝突時，能夠發送此狀態碼。響應中應該包含描述衝突的主體。
410	Gone	與404相似，只是服務器曾經擁有過此資源。主要用於Web站點的維護，這樣服務器的管理者就能夠在資源被移除的狀況下通知客戶端了。
411	Length Required	服務器要求在請求報文中包含Content-Length首部時使用。
412	Precondition Failed	客戶端發起了條件請求，且其中一個條件失敗了的時候使用。客戶端包含了Expect首部時發起的就是條件請求。
413	Request Entity Too Large	客戶端發送的實體主體部分比服務器可以或者但願處理的要大時，使用此狀態碼。
414	Request URI Too Long	客戶端所發請求中的請求URL比服務器可以或者但願處理的要長時，使用此狀態碼。
415	Unsupported Media Type	服務器沒法理解或沒法支持客戶端所發實體的內容類型時，使用此狀態碼。
416	Requested Range Not Satisfiable	請求報文所請求的是指定資源的某個範圍，而此範圍無效或沒法知足時，使用此狀態碼
417	Expectation Failed	請求的Expect請求首部包含了一個指望，但服務器沒法知足此指望時，使用此狀態碼。若是代理或其餘中間應用程序有確切證聽說明源端服務器會爲某請求產生一個失敗的指望，就能夠發送這個響應狀態碼。

500～599 --- 服務器錯誤狀態碼

有時客戶端發送了一條有效請求，服務器自身卻出錯了。這多是客戶端碰上了服務器的缺陷，或者服務器上的子元素，好比某個網關資源，出了錯。代理嘗試着表明客戶端與服務器進行交流時，常常會出現問題。代理會發布5XX服務器錯誤狀態碼來描述所遇到的問題。

狀態碼	緣由短語	含義
500	Internal Server Error	服務器遇到一個妨礙它爲請求提供服務的錯誤時，使用此狀態碼。
501	Not Implemented	客戶端發起的請求超出服務器的能力範圍(好比，使用了服務器不支持的請求方法)時，使用此狀態碼。
502	Bad Gateway	做爲代理或網關使用的服務器從請求響應鏈的下一條鏈路上收到了一條僞響應(好比，它沒法鏈接到其父網關)時，使用此狀態碼。
503	Service Unavailable	用來講明服務器如今沒法爲請求提供服務，但未來能夠。若是服務器知道何時資源會變爲可用的，能夠在響應中包含一個Retry-After首部。
504	Gateway Timeout	與狀態碼408相似，只是這裏的響應來自一個網關或代理，它們在等待另外一服務器對其請求進行響應時超時了。
505	HTTP Version Not Supported	服務器收到的請求使用了它沒法或不肯支持的協議版本時，使用此狀態碼。有些服務器應用程序會選擇不支持協議的早期版本。

各類各樣的HTTP首部都是用來作什麼的

首部和方法配合工做，共同決定了客戶端和服務器能作什麼事情。在請求和響應報文中均可以用首部來提供信息，有些首部是某種報文專用的，有些首部則更通用一些。能夠將首部分爲五個主要的類型。

• 通用首部：這些是客戶端和服務器均可以使用的通用首部。能夠在客戶端、服務器和其餘應用程序之間提供一些很是有用的通用功能。
• 請求首部：請求首部是請求報文特有的。它們爲服務器提供了一些額外信息，好比客戶端但願接收什麼類型的數據。
• 響應首部：響應報文有本身的首部集，以便爲客戶端提供信息(好比，客戶端在與哪一種類型的服務器進行交互)。
• 實體首部：實體首部指的是用於應對實體主體部分的首部。好比，能夠用實體首部來講明實體主體部分的數據類型。
• 擴展首部：擴展首部是非標準的首部，由應用程序開發者建立，但還未添加到已批准的 HTTP 規範中去。即便不知道這些擴展首部的含義，HTTP 程序也要接受它們並對其進行轉發。

通用首部

有些首部提供了與報文相關的最基本的信息，它們被稱爲通用首部。不論報文是何類型，都爲其提供一些有用信息。

• 通用的信息性首部

首部	描述
Connection	容許客戶端和服務器指定與請求/響應鏈接有關的選項
Date	提供日期和時間標誌，說明報文是什麼時間建立的
MIME-Version	給出了發送端使用的MIME版本
Trailer	若是報文采用了分塊傳輸編碼(chunked transfer encoding)方式，就能夠用這個首部列出位於報文拖掛(trailer)部分的首部集合
Transfer-Encoding	告知接收端爲了保證報文的可靠傳輸，對報文采用了什麼編碼方式
Update	給出了發送端可能想要"升級"使用的新版本或協議
Via	顯示了報文通過的中間節點(代理、網關)

• 通用緩存首部："HTTP/1.0"引入了第一個容許HTTP應用程序緩存對象本地副本的首部，這樣就不須要老是直接從源端服務器獲取了。最新的HTTP版本有很是豐富的緩存參數集。

首部	描述
Cache-Control	用於隨報文傳送緩存指示
Pragma	另外一種隨報文傳送指示的方式，但並不專用於緩存

請求首部

請求首部是隻在請求報文中有意義的首部。用於說明是誰或什麼在發送請求、請求源自何處，或者客戶端的喜愛及能力。服務器能夠根據請求首部給出的客戶端信息，試着爲客戶端提供更好的響應。

• 請求的信息性首部

首部	描述
Client-IP	提供了運行客戶端的機器的IP地址
From	提供了客戶端用戶的E-mail地址
Host	給出了接收請求的服務器的主機名和端口號
Referer	提供了包含當前請求URI的文檔的URL
UA-Color	提供了與客戶端顯示器的顯示顏色有關的信息
UA-CPU6	給出了客戶端CPU的類型或製造商
UA-Disp	提供了與客戶端顯示器(屏幕)能力有關的信息
UA-OS	給出了運行在客戶端機器上的操做系統名稱及版本
UA-Pixels	提供了客戶端顯示器的像素信息
User-Agent	將發起請求的應用程序名稱告知服務器

• Accept首部：Accept首部爲客戶端提供了一種將其喜愛和能力告知服務器的方式，包括它們想要什麼，可使用什麼，以及最重要的，它們不想要什麼。這樣，服務器就能夠根據這些額外信息，對要發送的內容作出更明智的決定。Accept 首部會使鏈接的兩端都受益。客戶端會獲得它們想要的內容，服務器則不會浪費其時間和帶寬來發送客戶端沒法使用的東西。

首部	描述
Accept	告訴服務器可以發送哪些媒體類型
Accept-Charset	告訴服務器可以發送哪些字符集
Accept-Encoding	告訴服務器可以發送哪些編碼方式
Accept-Language	告訴服務器可以發送哪些語言
TE	告訴服務器可使用哪些擴展傳輸編碼

• 條件請求首部：有時客戶端但願爲請求加上某些限制。好比，若是客戶端已經有了一份文檔副本，就但願只在服務器上的文檔與客戶端擁有的副本有所區別時，才請求服務器傳輸文檔。經過條件請求首部，客戶端就能夠爲請求加上這種限制，要求服務器在對請求進行響應以前，確保某個條件爲真。

首部	描述
Expect	容許客戶端列出某請求所要求的服務器行爲
If-Match	若是實體標記與文檔當前的實體標記相匹配，就獲取這份文檔
If-Modified-Since	除非在某個指定的日期以後資源被修改過，不然就限制這個請求
If-None-Match	若是提供的實體標記與當前文檔的實體標記不相符，就獲取文檔
If-Range	容許對文檔的某個範圍進行條件請求
If-Unmodified-Since	除非在某個指定日期以後資源沒有被修改過，不然就限制這個請求
Range	若是服務器支持範圍請求，就請求資源的指定範圍

• 安全請求首部：HTTP自己就支持一種簡單的機制，能夠對請求進行質詢 / 響應認證。這種機制要求客戶端在獲取特定的資源以前，先對自身進行認證，這樣就可使事務稍微安全一些。

首部	描述
Authorization	包含了客戶端提供給服務器，以便對其自身進行認證的數據
Cookie	客戶端用它向服務器傳送一個令牌——它並非真正的安全首部，但確實隱含了安全功能
Cookie2	用來講明請求端支持的cookie版本

• 代理請求首部：隨着因特網上代理的廣泛應用，人們定義了幾個首部來協助其更好地工做。

首部	描述
Max-Forward	在通往源端服務器的路徑上，將請求轉發給其餘代理或網關的最大次數——與TRACE方法一同使用
Proxy-Authorization	與Authorization首部相同，但這個首部是在與代理進行認證時使用的
Proxy-Connection	與Connection首部相同，但這個首部是在與代理創建鏈接時使用的

響應首部

<p>響應報文有本身的響應首部集。響應首部爲客戶端提供了一些額外信息，好比誰在發送響應、響應者的功能，甚至與響應相關的一些特殊指令。這些首部有助於客戶端處理響應，並在未來發起更好的請求。</p>

• 響應的信息性首部

首部	描述
Age	響應持續時間(從最初建立開始)
Public	服務器爲其資源支持的請求方法列表
Retry-After	若是資源不可用的話，在此日期或時間重試
Server	服務器應用程序軟件的名稱和版本
Title	對HTML文檔來講，就是HTML文檔的源端給出的標題
Warning	比緣由短語中更詳細一些的警告報文

• 協商首部：若是資源有多種表示方法——好比，若是服務器上有某文檔的法語和德語譯稿，"HTTP/1.1"能夠爲服務器和客戶端提供對資源進行協商的能力。

首部	描述
Accept-Ranges	對此資源來講，服務器可接受的範圍類型
Vary	服務器查看的其餘首部的列表，可能會使響應發生變化；也就是說，這是一個首部列表，服務器會根據這些首部的內容挑選出最適合的資源版本發送給客戶端

• 安全響應首部：本質上這裏說的就是HTTP的質詢/響應認證機制的響應側。

首部	描述
Proxy-Authenticate	來自代理的對客戶端的質詢列表
Set-Cookie	不是真正的安全首部，但隱含有安全功能；能夠在客戶端設置一個令牌，以便服務器對客戶端進行標識
Set-Cookie2	與Set-Cookie相似，""RFC 2965"Cookie定義
WWW-Authenticate	來自服務器的對客戶端的質詢列表

實體首部

<p>有不少首部能夠用來描述HTTP報文的負荷。因爲請求和響應報文中均可能包含實體部分，因此在這兩種類型的報文中均可能出現這些首部。實體首部提供了有關實體及其內容的大量信息，從有關對象類型的信息，到可以對資源使用的各類有效的請求方法。總之，實體首部能夠告知報文的接收者它在對什麼進行處理。</p>

• 實體的信息性首部

首部	描述
Allow	列出了能夠對此實體執行的請求方法
Location	告知客戶端實體實際上位於何處；用於將接收端定向到資源的(多是新的)位置(URL)上去

• 內容首部：內容首部提供了與實體內容有關的特定信息，說明了其類型、尺寸以及處理它所需的其餘有用信息。好比，Web 瀏覽器能夠經過查看返回的內容類型，得知如何顯示對象。

首部	描述
Content-Base	解析主體中的相對URL時使用的基礎URL
Content-Encoding	對主體執行的任意編碼方式
Content-Language	理解主體時最適宜使用的天然語言
Content-Length	主體的長度或尺寸
Content-Location	資源實際所處的位置
Content-MD5	主體的MD5校驗和
Content-Range	在整個資源中此實體表示的字節範圍
Content-Type	這個主體的對象類型

• 實體緩存首部：通用的緩存首部說明了如何或何時進行緩存。實體的緩存首部提供了與被緩存實體有關的信息——好比，驗證已緩存的資源副本是否仍然有效所需的信息，以及更好地估計已緩存資源什麼時候失效所需的線索。

首部	描述
ETag	與此實體相關的實體標記
Expires	實體再也不有效，要從原始的源端再次獲取此實體的日期和時間
Last-Modified	這個實體最後一次被修改的日期和時間