HTTP報文詳解

HTTP報文:它是HTTP應用程序之間發送的數據塊。這些數據塊以一些文本形式的元信息開頭,這些信息描述了報文的內容及含義,後面跟着可選的數據部分。這些報文都是在客戶端、服務器和代理之間流動。緩存

 

HTTP報文的流動方向:一次HTTP請求,HTTP報文會從「客戶端」流到「代理」再流到「服務器」,在服務器工做完成以後,報文又會從「服務器」流到「代理」再流到「客戶端」服務器

 

報文的語法:全部的HTTP報文均可以分爲兩類,請求報文和響應報文。請求和響應報文的基本報文結構大體是相同的,只有起始行的語法有所不一樣。cookie

請求報文:它會向Web服務器請求一個動做測試

請求報文的格式:編碼

起始行: <method> <request-URL> <version>spa

頭部:   <headers>操作系統

主體:   <entity-body>代理

 

響應報文:它會將請求的結果返回給客戶端。code

響應報文的格式:視頻

起始行:  <version> <status> <reason-phrase>

頭部:    <headers>

主體:    <entity-body>

 

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

一、方式(method)客戶端但願服務器對資源執行的動做,是一個單獨的詞,好比,GETPOSTHEAD

 

二、請求URL(request-URL)要直接與服務器進行對話,只要請求URL是資源的絕對路徑就能夠了,服務器能夠假定本身是URL的主機/端口

 

三、版本(version)報文所使用的HTTP版本。其格式:HTTP/<主要版本號>.<次要版本號>

 

四、狀態碼(status-code)狀態碼是三位數字,描述了請求過程當中所發生的狀況。每一個狀態碼的第一位數字都用於描述狀態的通常類別(好比,「成功」、「出錯」等等)

 

五、緣由短語(reason-phrase)數字狀態碼的可讀版本,包含行終止序列以前的全部文本。緣由短語只對人類有意義,所以,儘管響應行HTTP/1.0 200 NOT OKHTTP/1.0 200 OK中緣由短語的含義不一樣,但一樣都會被看成成功指示處理

 

六、頭部(header)能夠有零個或多個頭部,每一個首部都包含一個名字,後面跟着一個冒號(:),而後是一個可選的空格,接着是一個值,最後是一個CRLF首部是由一個空行(CRLF)結束的,表示了部列表的結束和實體主體部分的開始

 

七、實體的主體部分(entity-body)實體的主體部分包含一個由任意數據組成的數據塊,並非全部的報文都包含實體的主體部分,有時,報文只是以一個CRLF結束。

 

展現一些假想的請求和響應報文:

 

HTTP報文的組成部分:對報文進行描述的起始行、包含屬性的頭部塊、可選的,包含數據的主體部分

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

請求報文的起始行:該行包含了一個方法和一個請求的URL,還包含HTTP 的版本。

響應報文的起始行:該行包含了響應報文使用的HTTP版本、數字狀態碼、緣由短語。

 

二、頭部:HTTP首部字段向請求和響應報文中添加了一些附加信息。本質上來講,它們只是一些名/值對的列表。頭部和協議配合工做,共同決定了客戶端和服務器能作什麼事情

頭部的分類:

通用頭部:既能夠出如今請求報文中,也能夠出如今響應報文中,它提供了與報文相關的最基本的信息

Connection容許客戶端和服務器指定與請求/響應鏈接有關的選項

Date提供日期和時間標誌,說明報文是什麼時間建立的

MIME-Version給出了發送端使用的MIME版本

Trailer若是報文采用了分塊傳輸編碼方式,就能夠用這個首部列出位於報文拖掛部分的首部集合

Transfer-Encoding告知接收端爲了保證報文的可靠傳輸,對報文采用了什麼編碼方式

Update給出了發送端可能想要「升級」使用的新版本或協議

Via顯示了報文通過的中間節點(代理、網關)

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

 

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

Client-IP提供了運行客戶端的機器的IP地址

From提供了客戶端用戶的E-mail地址

Host給出了接收請求的服務器的主機名和端口號

Referer提供了包含當前請求URI的文檔的URL

UA-Color提供了與客戶端顯示器的顯示顏色有關的信息

UA-CPU給出了客戶端CPU的類型或製造商

UA-OS給出了運行在客戶端機器上的操做系統名稱及版本

UA-Pixels提供了客戶端顯示器的像素信息

User-Agent將發起請求的應用程序名稱告知服務器       

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

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

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

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

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

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

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

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

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

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

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

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

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

Cookie客戶端用它向服務器傳送數據

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

Max-Forward在通往源端服務器的路徑上,將請求轉發給其餘代理或網關的最大次數

Proxy-Authorization這個首部在與代理進行認證時使用的

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

 

響應頭部響應頭部爲客戶端提供了一些額外信息,好比誰在發送響應、響應者的功能,甚至與響應相關的一些特殊指令

Age(從最初建立開始)響應持續時間

Public服務器爲其資源支持的請求方法列表

Retry-After若是資源不可用的話,在此日期或時間重試

Server服務器應用程序軟件的名稱和版本

TitleHTML文檔來講,就是HTML文檔的源端給出的標題

Warning比緣由短語更詳細一些的警告報文

Accept-Ranges對此資源來講,服務器可接受的範圍類型

Vary服務器會根據這些首部的內容挑選出最適合的資源版本發送給客戶端

Proxy-Authenticate來自代理的對客戶端的質詢列表

Set-Cookie在客戶端設置數據,以便服務器對客戶端進行標識

Set-Cookie2Set-Cookie相似

WWW-Authenticate來自服務器的對客戶端的質詢列表

 

實體首部:描述主體的長度和內容,或者資源自身

Allow列出了能夠對此實體執行的請求方法

Location告知客戶端實體實際上位於何處,用於將接收端定向到資源的位置(URL)上去

Content-Base解析主體中的相對URL時使用的基礎URL

Content-Encoding對主體執行的任意編碼方式

Content-Language理解主體時最適宜使用的天然語言

Content-Length主體的長度

Content-Location資源實際所處的位置

Content-MD5主體的MD5校驗和

Content-Range在整個資源中此實體表示的字節範圍

Content-Type這個主體的對象類型

ETag與此實體相關的實體標記

Expires實體再也不有效,要從原始的源端再次獲取實體的日期和時間

Last-Modified這個實體最後一次被修改的日期和時間

 

擴展首部:規範中沒有定義的新首部,開發者能夠自定義一個首部的值/

 

3實體的主體部分:該部分其實就是HTTP要傳輸的內容,是可選的。HTTP報文能夠承載不少類型的數字數據,好比,圖片、視頻、HTML文檔電子郵件、軟件應用程序等等。

 

HTTP方法:並非每一個服務器都實現了全部的方法。即便服務器實現了全部這些方法,這些方法的使用極可能也是受限的。例如,支持DELETE方法或PUT方法的服務器可能並不但願任何人都可以刪除或存儲資源,這些限制一般都是在服務器的配置中進行設置的。

經常使用的HTTP方法:

GET方法:一般用於請求服務器發送某個資源。不包含主體

HEAD方法:GET方法相似,但服務器在響應中只返回首部,使用HEAD方法能夠,在不獲取資源的狀況下了解資源的狀況(好比,判斷其類型);經過查看響應中的狀態碼,看看某個對象是否存在;經過查看首部,測試資源是否被修改了;不包含主體

POST方法:該方法是用來向服務器發送數據的,經常使用於HTML表單,包含主體

PUT方法:該方法的語義就是讓服務器用請求的主體部分來建立一個由所請求的URL命名的新文檔,若是那個URL已經存在的話,就用這個主體來替代它。包含主體

TRACE方法:主要用於驗證請求是否如願穿過了請求/響應鏈,不包含主體

OPTIONS方法:決定能夠在服務器上執行那些方法,不包含主體

DELETE方法:該方法就是請服務器刪除請求URL所指定的資源,可是客戶端應用程序沒法保證刪除操做必定會被執行,由於HTTP規範容許服務器在不通知客戶端的狀況下撤銷請求,不包含主體

擴展方法:指的是沒有在HTTP/1.1規範中定義的方法,這些方法爲開發者提供了一種擴展這些HTTP服務能力的手段。

 

狀態碼:HTTP狀態碼被分紅了五大類。狀態碼爲客戶端提供了一種理解事務處理結果的便捷方式。

1100~199(信息性狀態碼)HTTP/1.1向協議中引入了信息性狀態碼

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

3300~399(重定向狀態碼)重定向狀態碼要麼告知客戶端使用替代位置來訪問他們所感興趣的資源,要麼就提供一個替代的響應而不是資源的內容

4400~499(客戶端錯誤狀態碼)有時客戶端會發送一些服務器沒法處理的東西。瀏覽網頁時,咱們都看到過臭名昭著的404 Not Found錯誤碼,這只是服務器在告訴咱們,它對咱們請求的資源一無所知

5500~599(服務器錯誤狀態碼)有時客戶端發送了一條有效請求,服務器自身卻出錯了,這些會返回5xx狀態碼

相關文章
相關標籤/搜索