http協議content-encoding & transfer-encoding

HTTP 1.1中有兩個實體頭(Entity-Header)直接與編碼相關,分別爲Content-Encoding和Transfer-Encoding. 先說Content-Encoding, 該頭表示實體已經採用了的編碼方式.Content-Encoding是請求URL對應實體(Entity)自己的一部分.好比請求URL爲http://host/image.png.gz時,可能會獲得的Content-Encoding爲gzip.Content-Encoding的值是不區分大小寫的,目前HTTP1.1標準中已包括的有gzip/compress/deflate/identity等. 與Content-Encoding頭對應,HTTP請求中包含了一個Accept-Encoding頭,該頭用來講明用戶代理(User-Agent,通常也就是瀏覽器)能接受哪些類型的編碼. 若是HTTP請求中不存在該頭,服務器能夠認爲用戶代理能接受任何編碼類型. 接下來重點描述Transfer-Encoding, 該頭表示爲了達到安全傳輸或者數據壓縮等目的而對實體進行的編碼. Transfer-Encoding與Content-Encoding的不一樣之處在於: 1, Transfer-Encoding只是在傳輸過程當中纔有的,並不是請求URL對應實體的自己特性.  2, Transfer-Encoding是一個"跳到跳"頭,而Content-Encoding是"端到端"頭.  該頭的用途舉例如,請求URL爲http://host/abc.txt,服務器發送數據時認爲該文件可用gzip方式壓縮以節省帶寬,接收端看到Transfer-Encoding爲gzip首先進行解碼而後才能獲得請求實體. 此外多個編碼可能同時對同一實體使用,因此Transfer-Encoding頭中編碼順序至關重要,它表明瞭解碼的順序過程.一樣,Transfer-Encoding的值也是不區分大小寫的,目前HTTP1.1標準中已包括的有gzip/compress/deflate/identity/chunked等. Transfer-Encoding中有一類特定編碼:chunked編碼.該編碼將實體分塊傳送並逐塊標明長度,直到長度爲0塊表示傳輸結束, 這在實體長度未知時特別有用(好比由數據庫動態產生的數據). HTTP1.1標準規定,只要使用了Transfer-Encoding的地方就必須使用chunked編碼,而且chunked必須爲最後一層編碼.任何HTTP 1.1應用都必須能處理chunked編碼. 與Transfer-Encoding對應的請求頭爲TE,它主要表示請求發起者願意接收的Transfer-Encoding類型. 若是TE爲空或者不存在,則表示惟一能接受的類型爲chunked. 其餘與Transfer-Encoding相關的頭還包括Trailer,它與chunked編碼相關,就不細述了. 顧名思義,Content-Length表示傳輸的實體長度,以字節爲單位(在請求方法爲HEAD時表示會要發送的長度,但並不實際發送.).Content-Length受Transfer-Encoding影響很大,只要Transfer-Encoding不爲identity,則實際傳輸長度由編碼中的chunked決定,Content-Length即便存在也被忽略. 關於HTTP Message Body的長度 在HTTP中有消息體(Message body)和實體(Entity body)之分,簡單說來在沒有Transfer-Encoding做用時,消息體就是實體,而應用了Transfer-Encoding後,消息體就是編碼後的實體,以下: Message body = Transfer-Encoding encode(Entity body) 如何肯定消息體的長度? HTTP 1.1標準給出了以下方法(按照優先級依次排列): 1, 響應狀態(Response Status)爲1xx/204/304或者請求方法爲HEAD時,消息體長度爲0. 2, 若是使用了非"identity"的Transfer-Encoding編碼方式,則消息體長度由"chunked"編碼決定,除非該消息以鏈接關閉爲結束. 3, 若是存在"Content-Length"實體頭,則消息長度爲該數值. 3, 若是消息使用關閉鏈接方式表明消息體結束,則長度由關閉前收到的長度決定. 該條對HTTP Request包含的消息體不適用.