HTTP實體實現(xiàn)目標(biāo) .可以被正確識別(通過Content-Type和Content-Launage)
.可以被正確解包(通過Content-Lenght首部和Content-Encoding首部)
.是最新的(通過實體驗證碼和緩存過期控制)
.符合用戶需要(基于Accept系列的內(nèi)容協(xié)商首部)
.在網(wǎng)絡(luò)上可以快速有效的傳輸(通過范圍請求、差異編碼以及其他數(shù)據(jù)壓縮方法)
.完整到達(dá)、未被篡改(通過傳輸編碼首部和Content-MD5校驗和首部)

一、報文是箱子，實體是貨物 1.HTTP基本實體首部
.Content-Type
實體所承載對象的類型
.Content-Length
實體主體的長度或大小
.Content-Launage
與所傳送實體最相配的語言
.Content-Encoding
實體數(shù)據(jù)是不是已經(jīng)被壓縮
.Content-Location
備用位置
.Content-Range
如果這是部分實體,則說明它是整體的哪部分
.Content-MD5
實體主體內(nèi)容的校驗和
.Last-Modified
所傳輸?shù)膬?nèi)容在服務(wù)器上創(chuàng)建或最后修改的日期
.Expires
實體數(shù)據(jù)將要失效的日期
.Allow
該資源所允許的各種請求方法,例如,GET、Post等
.ETag
這份文檔特定實例的唯一驗證碼
.Cache-Control
應(yīng)該如何緩存該文檔

2.實體主體

二、Content-Length:實體的大小 1.檢測截尾
客戶端需要通過Content-Length來檢測報文結(jié)尾以區(qū)分到底是報文結(jié)束時正常的連接關(guān)閉
還是報文傳輸時服務(wù)器崩潰而導(dǎo)致的連接關(guān)閉
緩存代理服務(wù)器不會為沒有Content-Length首部的HTTP主題作緩存
2.錯誤的Content-Length

3.Content-Length與持久連接
因為持久連接,客戶端無法通過連接關(guān)閉來判斷報文是否結(jié)束,故必須帶有Content-Length 首部.
但是當(dāng)分塊編碼時可以沒有Content-Length首部,因為數(shù)據(jù)分為一系列的塊來傳送,每塊都???? 有大小說明

4.內(nèi)容編碼
如果對主體進(jìn)行了內(nèi)容編碼(壓縮),則Content-Length就是編碼后的主體的長度

5.確定實體主體長度的規(guī)則
a.如果特定的HTTP報文類型不允許帶有主體,就忽略Content-Length首部 b.如果報文中含有描述傳輸編碼的Transfer-Encoding,那實體就由一個稱為零字節(jié)塊的
特殊模式結(jié)束
c.如果報文中含有Content-Length首部，而沒有Transfer-Encoding首部,那么Content- Length的值就是主體的長度，如果兩者皆有,則應(yīng)該忽略Content-Length的值 d.如果報文使用了multipart/byteranges媒體類型,并且沒有用Content-Length首部指定 實體主體長度,那么多部分報文的每個部分都要說明自己的大小? e.如果以上規(guī)則均無法匹配,則就在連接關(guān)閉的時候結(jié)束? ? ?
三、實體摘要? ?發(fā)送方在生成初始主體時,生成一個數(shù)據(jù)校驗和,接收方可以通過檢查這個校驗和來捕獲所有 意外的實體修改?? 服務(wù)器使用Content-MD5首部發(fā)送對實體主體運行MD5算法

四、媒體類型和字符集 Content-Type指明的是原始主體的媒體類型
1.文本的字符編碼
Content-Type:text/html; charset=xxxxx

2.多部分媒體類型

3.多部分表格提交
Content-Type:multipart/form-data; boundary=[abcdefg......]
boundary表明分隔主題中不同部分所用的字符串
4.多部分范圍響應(yīng)
Content-Type:multipart/byteranges

五、內(nèi)容編碼 1.過程
a.網(wǎng)站服務(wù)器生成原始響應(yīng)報文，其中有原始的Content-Type和Content-Length首部
b.內(nèi)容編碼服務(wù)器創(chuàng)建編碼后的報文,并增加Content-Encoding首部,以便接受的應(yīng)用程序 進(jìn)行解碼
c.接收程序得到編碼后的報文,進(jìn)行解碼,獲得原始報文

2.內(nèi)容編碼類型

3.Accept-Encoding首部
客戶端會把自己能夠識別的編碼列表放在Accept-Encoding首部里發(fā)出去,如果http請求中 沒有包含首部,則表示客戶端可以接受任何編碼方式

六、傳輸編碼和分塊編碼 傳輸編碼與內(nèi)容編碼的區(qū)別:
經(jīng)過內(nèi)容編碼的報文只是對報文的實體部分進(jìn)行編碼,而對于經(jīng)過傳輸編碼的報文，編碼
作用在整個報文上,報文自身的結(jié)構(gòu)發(fā)生了變化

使用傳輸編碼(Transfer-encoding)是為了改變報文中的數(shù)據(jù)在網(wǎng)絡(luò)上的傳輸方式

1.可靠傳輸
傳輸報文會引發(fā)的問題
.未知的尺寸
有些網(wǎng)關(guān)應(yīng)用程序或則內(nèi)容編碼器要想知道報文的大小,這時可以采用傳輸編碼來發(fā)
送數(shù)據(jù),并用特別的結(jié)束腳注表明數(shù)據(jù)結(jié)束
.安全性
可以用傳輸編碼把報文內(nèi)容擾亂，然后在共享的傳輸網(wǎng)絡(luò)上發(fā)送

2.Transfer-Encoding
.Transfer-Encoding： 告知接收方為了可靠的傳輸報文，已經(jīng)對其進(jìn)行了何種編碼
.TE:
用在請求首部，告知服務(wù)器可以使用哪些傳輸編碼

3.分塊編碼
.把報文分割為若干大小已知的塊,塊之間是緊挨著發(fā)送的
.分塊編碼是一種傳輸編碼,是報文的屬性,而不是主體的屬性
3.1.分塊與持久連接 .若客戶端與服務(wù)器不是持久連接,則服務(wù)端不需要知道它正在讀取的主體的長度,只需
要讀到服務(wù)器關(guān)閉主體連接為止
.服務(wù)器在寫主體之前必須知道主體的大小,如果服務(wù)器動態(tài)創(chuàng)建內(nèi)容,就無法知道長度, 分塊編碼只要服務(wù)器逐塊發(fā)出并且說明每塊大小即可,服務(wù)器可以用大小為0的塊作為
主體結(jié)束的信號
3.2.分塊報文的拖掛

4.內(nèi)容編碼與傳輸編碼的結(jié)合

5.傳輸編碼規(guī)則
.傳輸編碼集合中必須包含分塊,唯一的例外是使用關(guān)閉連接來結(jié)束報文
.當(dāng)使用分塊傳輸編碼時,它必須是最后一個作用在報文中主體之上的
.分塊傳輸編碼不能多次作用到一個報文主體之上
以上規(guī)則使得接收方能確定報文的長度

七、驗證碼與新鮮度 1.新鮮度
.服務(wù)器告知客戶端能夠?qū)?nèi)容緩存多長時間，在這個時間之內(nèi)是新鮮的
.可以用Expires首部或者Cache-Control

2.有條件的請求和驗證碼
有條件的請求:
.當(dāng)資源改變時才請求副本
.通過If-Modified-Since首部實現(xiàn)
驗證碼:
.弱驗證碼
.強(qiáng)驗證碼
強(qiáng)驗證碼能唯一標(biāo)識一個實例

八、范圍請求

總結(jié)

以上是生活随笔為你收集整理的Http协议(3)—HTTP实体和编码的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。