第 3 章 HTTP 報文內的 HTTP 信息

3.1 HTTP 報文 

http報文 用於 HTTP 協議交互的信息被稱爲 HTTP 報文。請求端(客戶端)的 HTTP 報文叫作請求報文,響應端(服務器端)的叫作響應報文。HTTP 報文自己是由多行(用 CR+LF 做換行符)數據構成的字符串文本。 

HTTP 報文大體可分爲報文首部和報文主體兩塊。二者由最初出現的空行(CR+LF)來劃分。一般,並不一定要有報文主體。 

 

3.2 請求報文及響應報文的結構 

  

請求報文和響應報文的首部內容由如下數據組成。如今出現的各類首部字段及狀態碼稍後會進行闡述。

請求行: 包含用於請求的方法,請求 URI 和 HTTP 版本。

狀態行: 包含代表響應結果的狀態碼,緣由短語和 HTTP 版本。
首部字段: 包含表示請求和響應的各類條件和屬性的各種首部。
  通常有 4 種首部,分別是:通用首部、請求首部、響應首部和實體首部。 其餘可能包含 HTTP 的 RFC 裏未定義的首部(Cookie 等)。 

3.3 編碼提高傳輸速率 

HTTP 在傳輸數據時能夠按照數據原貌直接傳輸,但也能夠在傳輸過程當中經過編碼提高傳輸速率。經過在傳 輸時編碼,能有效地處理大量的訪問請求。 

3.3.1 報文主體和實體主體的差別 

報文(message) :是 HTTP 通訊中的基本單位,由 8 位組字節流(octet sequence,其中 octet 爲 8 個比特)組成,經過 HTTP 通訊傳輸。

實體(entity) :做爲請求或響應的有效載荷數據(補充項)被傳輸,其內容由實體首部和實體主體組成。 

3.3.2 壓縮傳輸的內容編碼

發送郵件時咱們可使用ZIP進行壓縮 ,

HTTP協議中有一種被稱爲內容編碼的功能也能進行相似的操做。 

內容編碼指明應用在實體內容上的編碼格式,並保持實體信息原樣壓縮。內容編碼後的實體由客戶端接收並負責解碼。 

常見內容編碼:

• gzip
• compress(UNIX 系統的標準壓縮)
• deflate(zlib)
• identiy(不進行編碼)

3.3.3 分割發送的分塊傳輸編碼

在 HTTP 通訊過程當中,請求的編碼實體資源還沒有所有傳輸完成以前,瀏覽器沒法顯示請求頁面。 瀏覽器沒法顯示請求頁面。在傳輸大容 量數據時,經過把數據分割成多塊,可以讓瀏覽器逐步顯示頁面。 

分塊傳輸編碼會將實體主體分紅多個部分(塊)。每一塊都會用十六進制來標記塊的大小,而實體主體的最後一塊會使用「0(CR+LF)」來標記。 

3.4 發送多種數據的多部分對象集合 

HTTP 協議中採用MIME 機制, MIME會使用一種稱爲多部分對象集合(Multipart)的方法,來容納多份不一樣類型的數據 .

• multipart/form-data

Content-Type: multipart/form-data; boundary=AaB03x --AaB03x Content-Disposition: form-data; name="field1" Joe Blow --AaB03x Content-Disposition: form-data; name="pics"; filename="file1.txt" Content-Type: text/plain ...(file1.txt的數據)... --AaB03x--

• multipart/byteranges 

HTTP/1.1 206 Partial Content Date: Fri, 13 Jul 2012 02:45:26 GMT Last-Modified: Fri, 31 Aug 2007 02:02:20 GMT Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES --THIS_STRING_SEPARATES Content-Type: application/pdf Content-Range: bytes 500-999/8000 ...(範圍指定的數據)... --THIS_STRING_SEPARATES Content-Type: application/pdf Content-Range: bytes 7000-7999/8000 ...(範圍指定的數據)... --THIS_STRING_SEPARATES--

在 HTTP 報文中使用多部分對象集合時,須要在首部字段里加上 Content-type。 

使用 boundary 字符串來劃分多部分對象集合指明的各種實體。在 boundary 字符串指定的各個實體的起始行 以前插入「--」標記(例如:--AaB03x、--THIS_STRING_SEPARATES),而在多部分對象集合對應的字符串 的最後插入「--」標記(例如:--AaB03x--、--THIS_STRING_SEPARATES--)做爲結束。 

3.5 獲取部份內容的範圍請求 

在以往下載一個大圖片遇到網絡中斷,那麼就要從新開始.解決這個問題須要一種恢復機制.

要實現該功能須要指定下載的實體範圍。像這樣,指定範圍發送的請求叫作範圍請求(Range Request)。 對一份 10 000 字節大小的資源,若是使用範圍請求,能夠只請求 5001~10 000 字節內的資源。 

執行範圍請求時,會用到首部字段 Range 來指定資源的 byte 範圍。 

從一開始到 3000 字節和 5000~7000 字節的多重範圍

Range: bytes=-3000, 5000-7000

針對範圍請求,響應會返回狀態碼爲 206 Partial Content 的響應報文。另外,對於多重範圍的範圍請求,響 應會在首部字段 Content-Type 標明 multipart/byteranges 後返回響應報文。

若是服務器端沒法響應範圍請求,則會返回狀態碼 200 OK 和完整的實體內容。 

3.6 內容協商返回最合適的內容

當瀏覽器的默認語言爲英語或中文,訪問相同 URI 的 Web 頁面時,則會顯示對應的英語版或中文版的 Web 頁面。這樣的機制稱爲內容協商(Content Negotiation)。 

包含在請求報文中的某些首部字段(以下)就是判斷的基準。這些首部字段的詳細說明請參考下一章。

1 Accept 

2 Accept-Charset 

3 Accept-Encoding

 4 Accept-Language

 5 Content-Language 

服務器驅動協商(Server-driven Negotiation)

由服務器端進行內容協商。以請求的首部字段爲參考,在服務器端自動處理。但對用戶來講,以瀏覽器發送

的信息做爲斷定的依據,並不必定能篩選出最優內容。 

客戶端驅動協商(Agent-driven Negotiation) 由客戶端進行內容協商的方式。用戶從瀏覽器顯示的可選項列表中手動選擇。還能夠利用 JavaScript 腳本在Web 頁面上自動進行上述選擇。好比按 OS 的類型或瀏覽器類型,自行切換成 PC 版頁面或手機版頁面。

 透明協商(Transparent Negotiation) 是服務器驅動和客戶端驅動的結合體,是由服務器端和客戶端各自進行內容協商的一種方法。