http學習 1-3 chapter3-報文

時間 2019-11-16

標籤 http 學習 chapter3 chapter 報文欄目 HTTP/TCP 简体版

原文原文鏈接

若是說HTTP是因特網的信使，那麼HTTP報文就是它用來搬東西的包裹了。html

報文是如何流動的。
HTTP報文的三個組成部分（起始行、首部和實體的主體部分）
請求和響應報文之間的區別
請求報文支持的各類功能（方法）
和響應報文一塊兒返回的各類狀態碼
各類各樣的HTTP首部都是用來作什麼的。

3.1 報文流

HTTP報文是HTTP應用程序之間的發送的數據塊。這些數據塊以一些文本形式的元信息（meta-information）開頭，這些信息描述了報文的內容及含義，後面跟着可選的數據部分。瀏覽器

3.1.1 報文流入源端服務器

HTTP使用屬於流入（inbound）和流出（outbound）來描述事務處理（transaction）的方向。報文流入源端服務器，工做完成後，會流回到用戶的Agent代理中。緩存

3.1.2 報文向下遊流動

全部報文都會向下遊（downsteam）流動，全部的報文發送者都在接受者的上游（upstream）。安全

3.2 報文的組成部分

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

起始行和首部就是由行分隔的ASCII文本。每行都已一個由兩個字符組成的航中智序列做爲結束，其中包括一個回城符（ASCII碼13）和一個換行符（ASCII碼 10）.CRLFcookie

實體的主體或報文的主體是一個可選的數據塊。與起始行和首部不一樣的是主體中能夠包含文本或二進制數據，也能夠爲空。測試

3.2.1 報文的語法

全部的HTTP報文均可以分爲兩類：請求報文（request message）和相應報文（response message）。優化

請求報文的格式：編碼

<method> <request-URL> <version>spa

<entity-body>

相應報文格式

<entity-body>

下面是對各部分的簡要描述：

方法(method)

客戶端但願服務器對資源執行的動做。是一個單獨的詞，GET HEAD POST

請求URL(request-URL)

命名了所請求資源、或URL路徑組件的完整URL。

版本(version)

報文所使用的HTTP版本，其格式看起來是這樣的：

HTTP/<major>.<minor>

主要版本號（major）次要版本號（minor）都是整數

狀態碼(status)

三位數字描述了請求過程當中所發生的狀況。每一個狀態碼的第一位數字都用於描述狀態的通常類別（「成功」，「出錯」）

緣由短語(reason-phase)

數字狀態嗎的可讀版本，包含行終止序列以前的全部文本。

首部(headers)

能夠偶零個或多個首部，沒個首部都包含了一個名字，後面跟着一個（：），而後是一個可選的空格，接着是一個值，最後是一個CRLF，首部是有一個空行額CRLF結束的。表示了首部列表的結束和實體主體部分的開始。

實體的主體部分(entity-body)

實體的主體部分包含一個由任意數據組成的數據塊，並非全部的報文都包含實體的主體部分。

3.2.2 起始行

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

1. 請求行

請求報文請求服務器對資源進行一些操做，包含了一個方法和一個請求URL，還包含了HTTP的版本。全部這些字段都由空格符分隔。

2. 響應行

相應保溫承載了狀態信息和操做產生的全部結果數據。包含了相應報文使用的HTTP版本、數字狀態嗎以及描述操做狀態的文本形式的緣由短語，都有空格分隔

3. 方法

請求起始行以方法做爲開始，方法用來告知服務器要作些什麼。

n GET 從服務器獲取一份文檔否

n HEAD 只從服務器獲取文檔的首部否

n POST 向服務器發送須要處理的數據是

n PUT 將請求的主體部分存儲在服務器上是

n TRACE 對可能通過代理服務器傳送到服務器上的報文進行追蹤否

n OPTIONS 決定能夠在服務器上執行哪些方法否

n DELETE 從服務器上刪除一份文檔否

4. 狀態碼

方法使用來告訴服務器作什麼，狀態碼則是用來告訴客戶端發生了什麼事情。

狀態碼是在每條相應報文中的起始行返回的。會返回一個數字狀態和一個可讀的狀態。數字嗎便於程序進行差錯處理，而緣由短語則跟他便於人們理解。

n 總體範圍已定義範圍分類

n 100 ~ 199 100 ~ 101 信息提示

n 200 ~ 299 200 ~206 成功

n 300 ~ 399 300 ~305 重定向

n 400 ~ 499 400 ~ 415 客戶端錯誤

n 500 ~ 599 500 ~505 服務器錯誤

常見狀態碼

200 OK 成功。請求的全部數據都在響應主體中

401 Unauthorized 須要輸入用戶名和密碼

404 Not Found 服務器沒法找到鎖清秋的URL對應的資源

5. 緣由短語

緣由短語和狀態碼是成對出現的。緣由短語是狀態碼的可讀版本，應用程序開發者將其傳送給用戶，用以說明在請求期間發生了什麼狀況。

6. 版本號

版本號說明了應用程序支持的最高HTTP笨笨。

注意：版本號不會被看成分數來處理，版本中的每一個數字都會被當作一個單獨的數字來處理。所以比較HTTP版本是，沒個數字必須單獨進行比較，以便肯定那個版本更高，好比： HTTP/2.22 就比 HTTP/2.3的版本要搞，由於 22比3大。

3.2.3 首部

跟在起始行的後面就是零個，一個或多個HTTP首部字段。

HTTP首部字段想請求和相應報文中添加了一些附加信息。本質上來講，他們只是一些名/值對的列表。

1.首部分類

HTTP規範定義了幾種首部字段。應用程序也能夠隨意發明本身所用的首部。HTTP首部能夠分爲一下幾類。

通用首部

既能夠出如今請求報文中，也能夠出如今響應報文中

請求首部

提供更多有關請求的信息

響應首部

提供更多有關相應的信息

實體首部

描述主體的長度和內容，或者資源自身

擴展首部

規範中沒有定義的新首部

每一個HTTP首部都有一種簡單的語法：名字後面跟着冒號（：），而後跟上可選的空格，再跟上字段值，最後是一個CRLF。

常見的首部實例：

Date: Tue,3Oct 1997 02:16:03 GMT 服務器產生響應的日期

Content-length:15040 實體的主體部分包含了15040字節的數據

Content-type:image/gif 實體的主體部分是一個GIF圖片

Accept:image/gif,image/jpeg,text/html 客戶端接GIF圖片和JPEG圖片以及HTML

2．首部延續行

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

3.2.4 實體的主體部分

HTTP報文能夠承載不少類型的數字數據：圖片、視頻、HTML文檔，軟件應用程序、信用卡事務，電子郵件等。

3.2.5 版本0.9的報文

HTTP版本0.9是HTTP協議的早期版本。是當今HTTP所擁有的請求及響應報文的鼻祖。

3.3 方法

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

3.3.1 安全方法

HTTP定義了一組被稱爲安全方法的方法，GET方法和HEAD方法都被認爲是安全的，這就意味着使用GET或者HEAD方法的HTTP請求都不會產生什麼動做。

不產生動做，在這裏意味着HTTP請求不會在服務器上產生什麼結果。使用安全方法的目的就是容許HTTP應用程序開發者通知用戶，何時會使用某個可能已發某些動做的不安全方法。

3.3.2 GET

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

3.3.3 HEAD

不會返回實體的主體部分，這就容許客戶端在未獲取司機資源的狀況下，對資源的首部進行檢查。使用HEAD，能夠：

在不獲取自願的狀況下列奧接資源的狀況；

經過查看響應中的狀態碼，看看某個對象是否存在。

經過查看首部，測試資源是否被修改了

3.3.4 PUT

餘GET從服務器讀取文檔相反，PUT方法會向服務器寫入文檔。由於PUT容許用戶對內容進行修改，因此不少Web服務器都要求在執行PUT以前，用密碼登陸。

3.3.5 POST

POST方法起初是用來向服務器輸入數據的，實際上，一般會用它來支持HTML的表單。

3.3.6 TRACE

客戶端發起一個請求是，這個請求可能要穿過防火牆，代理、網關或其它一些應用程序。沒箇中間節點均可能修改原始的HTTP請求，TRACE方法容許客戶端在最終將請求發送個服務器是，看看他變成了什麼樣子。

3.3.7 OPTIONS

OPTIONS方法請求Web服務器告知其支持的各類功能。能夠詢問服務器一般支持哪些方法，或者對某些特殊資源支持哪些方法。

3.3.8 DELETE

DELETE方法所作的事情就是請服務器傷處請求URL所指定的資源。可是客戶端應用程序沒法保證刪除操做必定會被執行，由於HTTP規範容許服務器在不通知客戶端的狀況下撤銷請求。

3.3.9 擴展方法

HTTP被設計成字段可擴展的，這樣新的特性就不會使老的軟件失效了。

在這些狀況下，最好對擴展方法寬容一些，若是可以在不破壞端到端行爲的狀況下將帶有位置方法的報文傳遞給下游服務器的話，代理會嘗試着傳遞這些報文的。不然，他們會議501NotImplement狀態碼進行相應。最好按慣例「對所發送的內容要求嚴一點，對所接受的內容寬容一些」來處理擴展方法。

3.4 狀態碼

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

3.4.1 100 ~199 – 信息性狀態碼

HTTP/1.1 向協議中引入了信息性狀態碼。

100 continue

101 Switching Protocols

1.客戶端與100 Continue

從不少方面來看，100 Continue都是一種優化。客戶端應用程序只有在避免向服務器發送一個服務器沒法處理或使用的大實體時，才應該使用100Continue。

2.服務器端與100Continue

若是服務器接收到了這個請求，會用100Continue響應或一條錯誤碼來進行響應。

出於某種緣由，服務器在有機會發送100Continue響應以前就收到了部分的實體，就說明客戶端已經決定了繼續發送數據了，這樣服務器就不須要發送這個狀態碼了。

3.代理與100Continue

代理須要做出根據自身的代理狀況做出判斷，處理100Continiue

代理維護一些有關嚇一跳服務器機器所支持的HTTP版本的狀態信息是有好處的，這樣他們就能夠更好地處理收到的那些帶有100Continue指望的請求了。

3.4.2 200 ~299---成功狀態碼

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

狀態碼緣由短語含義

200	OK	請求沒問題的，實體的主體部分包含了所請求的資源
201	Created	用於建立服務器對象的請求（好比:PUT）。響應的實體主體部分中應該包含各類引用了以建立的資源的URL，location首部包含的則是最具體的引用。服務器必須在發送這個狀態嗎以前建立好對象
202	Accepted	請求已被接受，單服務器還未對其執行任何動做。不能保證服務器會完成這個請求，這只是意味着接受請求時，他看起來是有效的。服務器應該在實體的主體部分包含對請求狀態的描述，或許還應該有對請求完成時間的估計。
203	Non-authoritative Information	實體首部包含的信息不是來自於源端服務器，而是來自資源的一份副本，若是中間節點上有一份資源副本，但沒法或者沒有對她所發送的與資源有關的元信息盡心驗證就會出現這種狀況。
204	No Content	響應報文中包含若干首部和一個狀態航，但沒有實體的主體部分，主要用於在瀏覽器不轉爲顯示新文檔的狀況下，對其進行更新
205	Reset Content	另外一個主要用於瀏覽器的代碼，負責告知瀏覽器清除當前頁面中的全部HTML表單元素
206	Partial Content	成功執行了一個部分或range請求，稍後咱們會看到，客戶端能夠經過一些特殊的首部來獲取部分或某個範圍內的文檔這個狀態碼就說明範文請求成功了

3.4.3 300~399 重定向狀態嗎

重定向狀態碼要門告知客戶端使用替代位置來訪問他們所感興趣的資源，要麼就提供一個替代的相應而不是資源的內容。

3.4.4 400~499 客戶端錯誤狀態嗎

有時客戶端會發送一些服務器沒法處理的東西，好比格式錯誤的請求報文，或者求常見的是，請求一個不存在的URL。

3.4.5 500~599

有事客戶端發送了一條有效請求，服務器自身卻出多了，這多是客戶端碰上了服務器的缺陷，或者服務器上的子元素，好比某個網關資源出了錯。

3.5首部

首部和方法配合工做，共同決定了客戶端和服務器能作什麼事情。在請求和相應報文中均可以用首部來提供信息，有些首部是某種報文專用的。有些瘦不則更通用一些，

通用首部
請求首部
相應首部
實體首部
擴展首部

3.5.1 通用首部

有些首部提供了與報文相關的最基本的信息。他們被稱爲通用首部。

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

通用緩存首部

HTTP/1.0 引入了第一個容許HTTP應用程序緩存對象本地副本的首部，這樣就不須要老是直接從源端服務器獲取了。

Cache-Control 用於隨報文傳送緩存指示

Pragma 另外一種隨報文傳送指示的方式，但並不專用於緩存

3.5.2 請求首部

請求首部是隻在請求報文中有意義的首部。用於說明是誰或什麼在發送請求，請求源自何處，或者客戶端的喜愛及能力。

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

1. Accept首部

Accept首部微客戶端提供了一種將其喜歡喝能力告知服務器的方式。

Accept 告訴服務器可以發送哪些媒體類型

Accept-Charset 告訴服務器可以發送那些字符集

Accept-Encoding 告訴服務器可以發送哪些編碼方式

Accept-Language 告訴服務器可以發送哪些語言

TE 告訴服務器可使用那些擴展傳輸編碼

2. 條件請求首部

有時客戶端但願爲請求加上某些限制。經過條件請求首部，客戶端就能夠爲請求加上這種限制，要求服務器在對請求進行響應以前確保某個條件爲真。

Expect 容許客戶端列出某請求做要求的服務器行爲

If-Match 若是實體標記與妥當當前的實體標記向匹配，就獲取這份文檔

If-Modified-Since 除非在某個指定的日期以後資源被修改過，不然就限制這個請求。

If-None-Match 若是提供的實體標記與當前文檔的實體標記不相符，就獲取文檔

If-Range 容許對穩膽的某個範圍進行條件請求

If-Unmodified-Since 除非在某個指定日期以後資源沒有被修改過，不然就限制這個請求

Range 若是服務器支持範圍請求，就請求資源的指定範圍

3. 安全請求首部

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

Authorization 包含了客戶端提供給服務器，一邊對其自身進行認證的數據

Cookie 客戶端用它向服務器傳送一個令牌---它並非真正的安全首部，隱含了安全功能

Cookie2 用來講明請求段支持的cookie版本

4. 代理請求首部

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

Max-Forward 在通往源端服務器的路徑上，經請求轉發給其餘代理或網關的最大次數—與TRACE方法一同使用

Proxy-Authorization 與Authorization首部相同，單這個手部是在與代理進行認證是使用的。

Proxy-Connection 與Connection首部相同，但這個首部是在與代理創建鏈接時使用的。

3.5.3 響應首部

相應保溫有本身的相應瘦不及。相應首部微客戶端提供了一些額外信息，好比誰在發送相應相應這的功能。甚至與相應相關的一些特殊指令。這些受不有助於客戶端處理響應。殯改未來發起更好地請求。

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