HTTP權威指南：第三章

HTTP報文概覽

本文主要對報文的流動及其內容的理解作了介紹。包括如下內容：

• 報文的流動

• 報文的組成部分（起始行、首部和實體的主體部分）

• 報文的區別（響應報文和請求報文之間）

• 方法介紹

• 狀態碼介紹

• HTTP首部做用

這裏要強調的是，這個最可能是我抄書的理解，並不全面。請你們看的時候還須要用慧眼進行鑑別。

---

1、報文的流動

HTTP報文是指在HTTP應用程序之間收發的數據塊。其以文本形式的元信息開頭，描述報文的內容和含義，然後接續可選部分。這裏有三個術語：

• 流入（inbound）

• 流出（outbound）

• 事務處理（transaction）

流入是指從客戶端到服務器的事務處理方向；而流出則是從服務器到客戶端的事務處理方向。但無論是哪一種流動，全部報文都向下（downstream）流動，而報文的發送者都在接受者的上游（upstream）。注意，這裏的上游和下游都只和發送者、接受者有關，而服務器和客戶端都是下游節點，因此咱們沒法區別報文的發送方向。

---

2、報文的組成部分

HTTP報文分請求報文和響應報文兩種，它們都由三個部分組成：

• 起始行：對報文進行描述。

• 首部：包含屬性

• 主體：可選的，包含數據。

起始行和首部是由行分隔的ASCII文本，都包括了一個回車符和一個換行符，可寫做CRLF。可是，因爲部分HTTP應用程序不老是發送CRLF，因此一個HTTP應用程序應該接受單個換行符做爲終止。主體能夠包含文本或者二進制數據，也能夠爲空。

1.語法

HTTP報文分爲兩類，而語法不一樣。請求報文的格式爲：

<method> <request-URL> <version>
    <headers>
    
    <entity-body>

而響應報文在格式上，只有起始行有別：

<version> <status> <reason-phrase>

接下來將對其中的大部份內容進行詳細介紹，而實體則在往後詳談。這裏簡述下實體<entity-body>：包含一個由任意數據組成的數據塊，是可選的。

2.起始行

起始行分爲請求行和響應行。

2.1.請求行

請求報文的起始行，包含一個方法和一個請求URL。方法描述須要執行的操做，而請求URL則描述操做對象。請求行還包含客戶端的HTTP協議版本。這些字段使用空格符" "分隔。注意，在HTTP/0.9不要求請求中包含HTTP版本號。

2.2.響應行

響應報文的起始行，包含響應報文使用的HTTP協議版本、數字狀態碼和緣由短語。全部字段使用空格符" "分隔。

2.3.方法

告知服務器要進行的操做。HTTP規範中描述了一組方法，而在HTTP規範以外的方法，則是擴展方法，是HTTP規範的拓展。經常使用HTTP方法有：

方法	描述	是否包含主體
GET	從服務器中獲取文檔	否
HEAD	從服務器獲取文檔首部	否
POST	向服務器發送須要處理的數據	是
PUT	將請求的主體存儲在服務器上	是
TRACE	對可能通過代理服務傳送到服務器上的報文進行追蹤	否
OPTIONS	查詢服務器支持的方法	否
DELETE	從服務器上刪除文檔	否

2.4.狀態碼

服務器對客戶端操做結果的迴應。狀態碼有五種分類，而當前HTTP版本只規定了其中一部分。若是接收到拓展的狀態碼，則會按照其所屬範圍進行分類，然後按照該分類中的普通成員處理。狀態碼分類以下：

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

後面會解釋當前使用的全部狀態碼，這裏按下不表。

2.5.緣由短語

與狀態碼同時出現，是其文本形式，可是HTTP規範對此並無任何規定,可是有推薦的文本內容。

2.6.版本號

以HTTPx.y出現,使得HTTP客戶端和服務器能夠了解雙方的能力和報文。注意，其版本號不會被看成小數處理，每個數字都會單獨比較。

3.首部

其做用是向報文添加附加信息，本質上是名/值對的列表，用冒號":"分開名與值，能夠分爲五種：通用首部、請求首部、響應首部、實體首部和擴展首部。首部的語法以下：
<headers>: (可選的空格)<value>\r\n
首部能夠有多行，爲了加強可讀性，從第二行開始要在前面加一個空格或者製表符。

4.實體的主體部分

是HTTP報文的符合，即其要傳輸的內容。HTTP報文能夠承載多種類型的數字數據，包括HTML文檔、圖片、視頻等。

5.HTTP0.9的報文

這是HTTP協議早期版本，由請求和響應構成，可是請求中只包含方法和請求URL，而響應中只包含實體。因爲其卻放靈活性，不能使用大部分提到的方法，可是在部分應用上仍舊使用，開發者應該清楚其侷限。

---

3、方法

這部分是對前面的基本方法的深刻探討。有如下幾點要注意：

• 並非每一個服務器實現了全部方法

• 服務器中部分方法的使用多是受限的，而限制則在服務器的配置中進行設置。

1.安全方法

這是由HTTP協議定義的，其中包括GET和HEAD方法。安全方法意味着不產生動做，但這由Web開發者決定。相對應的，使用不安全的方法時，會容許HTTP應用開發者通知用戶，這纔是目的。

2.GET方法

經常使用方法，用於請求服務器發送某個資源，在HTTP/1.1中，要求服務器實現該方法。

3.HEAD方法

相似GET方法，可是響應只返回首部。目的是容許客戶端對資源的首部進行檢查。該方法有如下做用：

• 不獲取資源的前提下了解資源狀況

• 查看對象是否存在

• 測試資源是否被修改

規範要求其返回的首部於GET方法得到的相同。

4.PUT方法

向服務器寫入文檔，其方法的語義即讓服務器用請求的主體部分（body）建立或者覆蓋所請求的URL命名的新文檔。因爲其容許用戶修改文件，一般要求進行密碼認證。該方法須要存儲資源。

5.POST方法

起初用來輸入數據，現多用來支持HTTP表單。表單體拿到的數據發送給服務器，再由服務器決定去向。該方法不須要存儲資源。

6.TRACE方法

在客戶端發起請求之後，當它穿過其餘應用程序的中間節點時可能被修改。而TRACE方法容許客戶端最後將請求發送給服務器。
該請求會進行「環回」診斷，即在服務器彈回一條攜帶收到的報文的TRACE響應，使得客戶端能查看原始報文的修改狀況。TRACE方法用於診斷，驗證請求是否穿過了請求/響應鏈，但因爲其假設中間應用程序對各類不一樣類型的請求的處理相同，因此其不能區別HTTP程序對不一樣方法的處理機制的差別。
TRACE請求中不能帶有實體的主體部分。響應主體則包含收到的請求主體的精確副本。

7.OPTIONS方法

請求Web服務器告知其支持的全部方法，這些方法是通用於服務器上全部資源的。這使得客戶端能夠斷定請求資源的最優方法。（就是優化）

8.DELETE方法

請求服務器刪除請求URL指定的資源，可是客戶端程序不保證刪除操做被執行。

9.拓展方法

因爲HTTP被設計爲字段可拓展的，新舊特性能夠兼容。而拓展方法指的是：沒有在HTTP/1.1規範中定義的方法。常見拓展方法實例以下：

方法	描述
LOCK	容許用戶「鎖定」資源，以防編輯時被其餘人修改。
MKCOL	容許用戶建立資源
COPY	複製服務器上的資源
MOVE	移動服務器的資源

上面的拓展方法是在WebDAV HTTP拓展中定義的拓展方法。要注意的是，並不是全部拓展方法均可以被理解或者應用，因此，最好對拓展方法寬容以待，只要不破壞端到端行爲，能夠傳遞給下游服務器；若是可能破壞，則傳遞501 Not Implemented進行響應。慣例是：「對發送的內容要求嚴格，對接受的內容要求寬鬆」。

---

4、狀態碼

目的是便利客戶端理解事務處理的結果，分爲五大類，而五大類中的每一個狀態碼都有一個HTTP/1.1推薦使用的緣由短語。

1.信息性狀態碼100~199

在HTTP/1.1中引入，存在爭論，受到限制。其主要內容以下：

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

在這裏，要對100狀態碼進行一個解釋。其針對的情境是：客戶端須要發送一個實體給服務器，但要在發送以前檢查一下服務器是否會接受該實體。而它在客戶端、服務器和代理之間是這樣通訊的：

客戶端與100狀態碼

客戶端能夠發送一個攜帶了值爲100Continue的Expect請求首部，從而能夠在發送實體以前等待100Continue的響應。這用於避免向服務器發送一個沒法處理的大實體。注意，若是等待超時，則客戶端應該直接發送實體；要應對非預期的響應。

服務器與100狀態碼

服務器在收到帶有值爲100Continue的Expect首部的請求時，應該用100Continue或者其餘錯誤狀態碼進行響應。可是，若是客戶端沒有要求，則服務器不該該發送該響應。
若是服務器在發送100Continue以前就收到部分實體，即客戶端已經超時了，服務器就不須要發送100狀態碼，可是讀完請求之後，應該發送一個最終狀態碼（可跳過100狀態碼）。

代理與100狀態碼

代理收到一個100Continue的Expect請求，則能作的分如下幾種狀況：

• 知道下一跳服務器是HTTP/1.1兼容（或者不知道），則將Except首部向下轉發

• 知道下一跳服務器只與HTTP/1.1以前兼容，則應該響應417Exception Failed錯誤（或者是先向客戶端返回100Continue，然後在向服務器轉發請求的時候，刪除Except首部）。

• 代理表明與HTTP/1.0或以前的版本兼容的客戶端，則能夠向請求中放入Except首部與100Continue值，可是不能向客戶端轉發該狀態碼。
  因此，代理維護下一跳服務器及其版本信息有優勢：更好地處理100Continue指望的請求。

2.成功狀態碼200~299

成功的請求有不一樣類型，因此下面有不一樣的表示成功的狀態碼。

狀態碼	緣由短語	含義
200	OK	請求沒問題，實體的主體部分包含請求的資源。
201	Created	對用於建立服務器對象的請求的響應。其實體的主體部分應該包含各類引用了已建立資源的URL，Location首部包含的是最具體的引用。
202	Accepeted	請求已被接受，可是未執行並不保證執行請求。服務器應該在實體的主體部分包含對請求狀態的描述，以及完成請求的時間的估算（或者能夠得到此信息位置的指針）。
203	Non-authoritative Information	實體首部包含的信息來自資源的副本（而非服務器）。在中間節點有資源副本，可是沒法或者沒有對它發送的與資源有關的首部進行驗證時，出現的狀況。
204	Not Content	響應報文包含首部和狀態行，可是沒有實體的主體部分。用於在瀏覽器不轉爲顯示新文檔的狀況下，對其進行更新。
205	Reset Content	用於瀏覽器，告知瀏覽器清楚當前頁面中全部HTML表單元素。
206	Partial Content	成功執行一個部分或者Range請求。其必須包含Content-Range\Date或者Content-Location首部。

3.重定向狀態碼300~399

告知用戶使用替代位置來訪問資源，或者提供一個替代的響應而不是資源內容。若是資源已移動，則能夠發送重定向狀態碼以及一個可選的Location首部來告知客戶端資源已被移動，以及當前位置。這樣瀏覽器能夠透明轉入新的位置。
也能夠經過重定向狀態碼驗證本地資源與服務器資源，用於查看服務器資源的修改，以及保持本地副本的及時性。
對包含了重定向狀態碼的非HEAD請求進行響應，則包含一個實體，並在實體中描述信息和指向（多個）重定向URL的鏈接。

狀態碼	緣由短語	含義
300	Multiple Choices	客戶端請求一個實際上指向多個資源的URL時返回。服務器在返回時，能夠在Location首部包含首選URL
301	Moved Permanently	在請求的URL已經移除時使用。響應的Location首部則包含資源的現URL
302	Found	相似301，可是Location首部給出的URL只能臨時定位資源，以後的請求應使用舊URL
303	See Other	告知客戶端應使用另外一個URL獲取資源。新URL位於Location首部，目的是容許POST請求的響應將客戶端重定向到某個資源上
304	Not Modified	客戶端能夠經過包含的請求首部，使其變爲有條件的。條件首部的內容能夠在後面看到。帶有該狀態碼的響應不包含實體的主體部分。
305	Use Proxy	說明該資源必須經過代理訪問。代理位置由Location首部指出。客戶端是相對某個特定資源解析該響應，而不是指定全部資源經過該代理進行。
307	Temporary Redirect	相似301。可是Location首部給出的URL只能臨時定位資源，以後的請求應使用舊URL

狀態碼30二、30三、307之間存在交叉和細微的差異，而其源於HTTP/1.0和HTTP/1.1應用程序之間的差異。
對於HTTP/1.0客戶端，發起POST請求並收到302響應時，會接受Location首部的重定向URL，併發送GET請求。
對HTTP/1.0服務器，要求客戶端像上面同樣作。
可是HTTP/1.1使用303狀態碼實現相同行爲，因此，對於HTTP/1.1客戶端，使用307狀態碼來代理302狀態碼，以免302狀態碼被覆蓋。

4.客戶端錯誤狀態碼400~499

服務器收到沒法處理的內容時的響應。

狀態碼	緣由短語	含義
401	Bad Request	告知客戶端發送了一個錯誤請求。
402	Unauthorized	與適當的首部一同返回，請求客戶端在獲取資源的訪問權之前，對本身進行認證。
403	Payment Required	未使用，可是保留到將來使用。
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，只是服務器曾經擁有該資源，用於站點的維護，能夠在服務器的資源被移除時通知客戶端。
411	Length Required	服務器的要求
412	Precondition Failed	發起條件請求，可是其中一個條件失敗時使用。
413	Request Entity Too Large	客戶端發送的實體主體部分大於服務器能處理的內容。
414	Request URI Too Long	URL實在太長。
415	Unsupported Media Type	服務器沒法理解或者沒法支持客戶端所發送的實體的內容類型時使用。
416	Requested Range Not Satisfiable	請求報文請求的是指定資源的某個範圍，可是該範圍無效或者沒法知足。
417	Expectation Failed	包含指望的請求沒法由服務器知足。若是代理或者中間程序有確切證聽說明服務器必然會產生一個失敗的指望，則能夠發送這個響應狀態碼。

有一個403Forbidden，好像是服務器拒絕處理請求，而且不說明緣由。

5.服務器錯誤狀態碼500~599

客戶端的請求有效，可是服務器出錯時，可使用，這是一般是代理與服務器交流的結果。

狀態碼	緣由短語	含義
500	Internal Server Error	服務器遇到一個妨礙它爲請求提供服務的時候使用。
501	Not Implemented	客戶端發起的請求超過服務器能力時使用
502	Bad Gateway	做爲代理或者網關使用的服務器從請求響應鏈的下一條鏈路上收到了一條僞響應時使用
503	Sevice Unavailable	用來講明服務器如今沒法爲請求提供服務，可是未來能夠啊（有種備胎的感受）
504	Gateway Timeout	相似408，可是該響應來自一個網關或者代理
505	HTTP Version Not Supported	收到的請求的版本不符。

---

5、首部

首部與方法配合使用，決定服務器和客戶端的動做。其有五種首部，在下面進行詳細論述。

1.通用首部

提供與報文相關的最基本的信息，能夠由兩種報文使用。信息性首部有：

首部	描述
Connection	容許客戶端和服務器指定與請求/響應鏈接相關的選項
Date	提供日期和時間標誌，說明報文建立的時間
MIME-Version	給出發送端使用的MIME版本
Trailer	報文采用了分塊傳輸編碼時，使用該首部列出位於報文拖掛（trailer）部分的首部集合。
Transfer-Encoding	告知報文采用的編碼方式
Update	給出發送端可能想要「升級」使用的新版本或者協議
Via	顯示報文通過的中間節點

而通用緩存首部則是在HTTP/1.0中引入的，容許HTTP應用程序緩存本地副本的首部，而不用直接從服務器中獲取。基本的緩存首部以下：

首部	描述
Cache-Control	用於隨報文傳送緩存指令
Pragma	另外一種隨報文傳送指令的方式，可是非專門用於緩存

2.請求首部

在請求報文中特有的內容。對服務器提供更詳細的有關客戶端的信息。其信息性首部有：

首部	描述
Client-IP	運行客戶端的機器的IP
From	客戶端用戶的郵箱地址
Host	請求的服務器主機名和端口號
Referer	包含當前請求URL的文檔的URL
UA-Color	提供了與客戶端顯示器對顏色的支持的有關信息
UA-CPU	提供了客戶端的CPU類型或製造商
UA-Disp	提供客戶端顯示器能力相關信息
UA-OS	提供客戶端操做系統信息——名稱及其版本
UA-Pixels	提供客戶端顯示器像素
User-Agent	將發起請求的應用程序名告知服務器

2.1.Accept首部

爲客戶端提供將器喜愛和能力告知服務器的方式，從而使得鏈接的兩端都得益。主要的Accept首部以下：

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

2.2.條件請求首部

爲請求加上限制，要求服務器在響應以前，確保條件爲真。

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

2.3.安全請求首部

對請求進行質詢後者響應認證。要求客戶端在獲取特定資源以前，對自身進行認證，從而提升事務安全性。

首部	描述
Authorization	包含客戶端提供給服務器，以便對其自身進行認證的數據
Cookie	傳遞給服務器的一個令牌，隱含安全功能
Cookie2	用來講明請求端支持的Cookie版本

2.4.代理請求首部

因爲代理的廣泛應用而來。

首部	描述
Max-Forward	在通往源服務器的路徑上，將請求轉發給其餘代理（網關）的最大次數，與TRACE一同使用
Proxy-Authorization	與同名首部功能相同，可是用於代理
Proxy-Connection	與同名首部功能相同，可是用於代理

3.響應首部

由響應報文使用，爲客戶端提供額外的信息，包括信息性首部、協商首部和安全響應首部。信息性首部以下：

首部	描述
Age	響應持續時間
Public	服務器爲資源提供的方法列表
Retry-After	資源不可用則在該日期或者時間重試
Server	服務器應用的名稱和版本
Title	HTML源端給定的標題
Warning	比緣由短語詳細的警告報文

而協商首部則是用來傳遞與可協商資源有關的信息。

首部	描述
Accept-Range	對該資源來講，服務器能夠接受的範圍類型
Vary	服務器查看的其餘首部的列表，可能使響應變化。即由服務器決定最適合的資源版本發送給客戶端

安全響應首部則是HTTP的質詢/響應認證機制的響應側。安全響應首部以下：

首部	描述
Procy-Authenticate	來自代理對客戶端的質詢列表
Set-Cookie	在客戶端設置令牌，標識客戶端
Set-Cookie2	相似上面
WWW-Authenticate	來自服務器的對客戶端的質詢列表

4.實體首部

能夠出如今兩種報文中，提供有關實體及其內容的大量信息，其信息性首部有：

首部	描述
Allow	列出對該實體能夠執行的請求方法
Location	告知客戶端實體的位置，用於定向到資源的位置

內容首部包含的是與實體內容有關的特定信息。

首部	描述
Content-Base	解析主體中相對URL時使用的基礎URL
Content-Encoding	對主體執行的編碼方式
Content-Language	理解主體適合的天然語言
Content-Length	長度
Content-Location	位置
Content-MD5	MD5校驗碼
Content-Range	該實體表示的字節範圍
Content-Type	對象類型

緩存首部則說明了被緩存的主體的信息。

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

---

這裏就是本章的所有內容，雖然有一些圖有所缺漏，可是至少看懂HTTP報文大概是怎麼回事應該沒問題了。