HTTP協議詳解（深入理解）

著作權宣告：本文為CSDN博主「有抱負的小獅子」的原創文章，遵循 CC 4.0 BY-SA 著作權協議，轉載請附上原文出處鏈接及本宣告，
原文鏈接：https://blog.csdn.net/weixin_38087538/article/details/82838762

引入

超文本傳輸協議（HTTP，HyperText Transfer Protocol)是互聯網上應用最為廣泛的一種網路協議，所有的WWW檔案都必須遵守這個標準，設計HTTP最初的目的是為了提供一種發布和接收HTML頁面的方法，1960年美國人Ted Nelson構思了一種通過計算機處理文本資訊的方法，并稱之為超文本（hypertext）,這成為了HTTP超文本傳輸協議標準架構的發展根基，Ted Nelson組織協調萬維網協會（World Wide Web Consortium）和互聯網工程作業小組（Internet Engineering Task Force ）共同合作研究，最終發布了一系列的RFC，其中著名的RFC 2616定義了HTTP 1.1，

http協議的作用及特點
HTTP是一個客戶端和服務器端請求和應答的標準（TCP），客戶端是終端用戶，服務器端是網站，通過使用Web瀏覽器、網路爬蟲或者其它的工具，客戶端發起一個到服務器上指定埠（默認埠為80）的HTTP請求，（我們稱這個客戶端）叫用戶代理（user agent），應答的服務器上存盤著（一些）資源，比如HTML檔案和影像，（我們稱）這個應答服務器為源服務器（origin server），在用戶代理和源服務器中間可能存在多個中間層，比如代理，網關，或者隧道（tunnels），盡管TCP/IP協議是互聯網上最流行的應用，HTTP協議并沒有規定必須使用它和（基于）它支持的層， 事實上，HTTP可以在任何其他互聯網協議上，或者在其他網路上實作，HTTP只假定（其下層協議提供）可靠的傳輸，任何能夠提供這種保證的協議都可以被其使用，

通常，由HTTP客戶端發起一個請求，建立一個到服務器指定埠（默認是80埠）的TCP連接，HTTP服務器則在那個埠監聽客戶端發送過來的請求，一旦收到請求，服務器（向客戶端）發回一個狀態行，比如"HTTP/1.1 200 OK"，和（回應的）訊息，訊息的訊息體可能是請求的檔案、錯誤訊息、或者其它一些資訊，HTTP使用TCP而不是UDP的原因在于（打開）一個網頁必須傳送很多資料，而TCP協議提供傳輸控制，按順序組織資料，和錯誤糾正，

通過HTTP或者HTTPS協議請求的資源由統一資源標示符（Uniform Resource Identifiers）（或者，更準確一些，URLs）來標識，

1.基于請求/回應模型的協議，請求和回應必須成對，先有請求后有回應

2.http協議默認埠:80

3.簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑，請求方法常用的有GET、HEAD、POST，每種方法規定了客戶與服務器聯系的型別不同，由于HTTP協議簡單，使得HTTP服務器的程式規模小，因而通信速度很快，

4.靈活：HTTP允許傳輸任意型別的資料物件，正在傳輸的型別由Content-Type加以標記，

5.無連接：無連接的含義是限制每次連接只處理一個請求，服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接，采用這種方式可以節省傳輸時間，

6.無狀態：HTTP協議是無狀態協議，無狀態是指協議對于事務處理沒有記憶能力，缺少狀態意味著如果后續處理需要前面的資訊，則它必須重傳，這樣可能導致每次連接傳送的資料量增大，另一方面，在服務器不需要先前資訊時它的應答就較快，

協議功能
HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）是用于從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議，它可以使瀏覽器更加高效，使網路傳輸減少，它不僅保證計算機正確快速地傳輸超文本檔案，還確定傳輸檔案中的哪一部分，以及哪部分內容首先顯示(如文本先于圖形)等，

HTTP是客戶端瀏覽器或其他程式與Web服務器之間的應用層通信協議，在Internet上的Web服務器上存放的都是超文本資訊，客戶機需要通過HTTP協議傳輸所要訪問的超文本資訊，HTTP包含命令和傳輸資訊，不僅可用于Web訪問，也可以用于其他因特網/行內網應用系統之間的通信，從而實作各類應用資源超媒體訪問的集成，

我們在瀏覽器的地址欄里輸入的網站地址叫做URL (Uniform Resource Locator，統一資源定位符)，就像每家每戶都有一個門牌地址一樣，每個網頁也都有一個Internet地址，當你在瀏覽器的地址框中輸入一個URL或是單擊一個超級鏈接時，URL就確定了要瀏覽的地址，瀏覽器通過超文本傳輸協議(HTTP)，將Web服務器上站點的網頁代碼提取出來，并翻譯成漂亮的網頁，

http協議的版本
HTTP/1.0,發送請求，創建一次連接，獲得一個web資源，連接斷開

HTTP/1.1，發送請求，創建一次連接，獲得多個web資源，連接斷開

Http協議的組成
Http協議由Http請求和Http回應組成，當在瀏覽器中輸入網址訪問某個網站時， 你的瀏覽器會將你的請求封裝成一個Http請求發送給服務器站點，服務器接收到請  求后會組織回應資料封裝成一個Http回應回傳給瀏覽器，即沒有請求就沒有回應，

http請求包括:請求行、請求頭、空行、請求體

http回應包括:回應行、回應頭、空行、回應體

HTTP請求報文
HTTP請求報文由3部分組成（請求行+請求頭+空行+請求體）：

請求行：

例如：POST /chapter17/user.html HTTP/1.1

格式：請求方式 資源路徑 協議/版本

請求行必須在http請求格式的第一行，

get請求:

將請求引數追加在url后面，不安全

url長度限制get請求方式資料的大小

沒有請求體

一般的HTTP請求大多都是GET，

post請求：

請求引數在請求體處，較安全，

請求資料大小沒有顯示

只有表單設定為method=“post”才是post請求，其他都是get請求

常見get請求:地址欄直接訪問、<a href="">、<img src="">等

HEAD請求:

HEAD跟GET相似，不過服務端接收到HEAD請求時只回傳回應頭，不發送回應內容，所以，如果只需要查看某個頁面的狀態時，用HEAD更高效，因為省去了傳輸頁面內容的時間，

DELETE請求：

洗掉某一個資源，

OPTIONS請求：

用于獲取當前URL所支持的方法，若請求成功，會在HTTP頭中包含一個名為“Allow”的頭，值是所支持的方法，如“GET, POST”，

PUT請求：

把一個資源存放在指定的位置上，

本質上來講， PUT和POST極為相似，都是向服務器發送資料，但它們之間有一個重要區別，PUT通常指定了資源的存放位置，而POST則沒有，POST的資料存放位置由服務器自己決定，

TRACE請求：

回顯服務器收到的請求，主要用于測驗或診斷，

CONNECT請求：

CONNECT方法是HTTP/1.1協議預留的，能夠將連接改為管道方式的代理服務器，通常用于SSL加密服務器的鏈接與非加密的HTTP代理服務器的通信，

請求頭:

例如：Host: 39.108.107.149:8080

請求頭從第二行開始，到第一個空格結束，請求頭和請求體之間存在一個空格，也叫空行(如下)

1 POST http://39.108.107.149:8080/vk/app/rest/ddp/iModelServiceImpl/findModelByType HTTP/1.1
2 User-Agent: Fiddler
3 Host: 39.108.107.149:8080
4 Content-Length: 11
5  
6 name=城市

請求頭通常以鍵值對{key:value}方式傳遞資料，

key為規范的固定值

value為key對應的取值，通常是一個值，可能是一組，

HTTP請求報文頭屬性
常見請求頭

Referer:表示這個請求是從哪個url跳過來的,通過百度來搜索淘寶網,那么在進入淘寶網的請求報文中,Referer的值就是:www.baidu.com，如果是直接訪問就不會有這個頭，

常用于:防盜鏈，

Referrer Policy: no-referrer-when-downgrade

Accept:告訴服務端,該請求所能支持的回應資料型別,專業術語稱為MIME 型別(檔案型別的一種描述方式)

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

MIME格式：大型別/小型別[;引數]

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

例如:

text/html,html檔案

text/css,css檔案

text/javascript,js檔案

image/*，所有圖片檔案

if-Modified-Sincce:瀏覽器通知服務器，本地快取的最后變更時間，與另一個回應頭組合控制瀏覽器頁面的快取

Cokkie：客戶端的Cookie就是通過這個報文頭屬性傳給服務端的哦！

Cookie: JSESSIONID=15982C27F7507C7FDAF0F97161F634B5

這里就出了一個問題,網站A怎么保證自己請求體中保存的cookie就是網站A的cookie而不是網站B的cookie呢,這就和cookie里面的jsessionid有關系了，關于cookie,session,sessionid,jsessionid的區別聯系，可以參考這個博文:

http://www.cnblogs.com/fnng/archive/2012/08/14/2637279.html

User-Agent:瀏覽器通知服務器，客戶端瀏覽器與作業系統相關資訊

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36

Connection:表示客戶端與服務連接型別；Keep-Alive表示持久連接，close已關閉

Connection: keep-alive

Host:請求的服務器主機名

Host: sczpkj.f3322.net:3000

Content-Length:請求體的長度

POST http://39.108.107.149:8080/vk/app/rest/ddp/iModelServiceImpl/findModelByType HTTP/1.1
User-Agent: Fiddler
Host: 39.108.107.149:8080
Content-Length: 11

name=城市

Content-Type:請求的與物體對應的MIME資訊，如果是post請求,會有這個頭,默認值為application/x-www-form-urlencoded，表示請求體內容使用url編碼

Content-Type: application/x-www-form-urlencoded

Accept-Encoding：瀏覽器通知服務器，瀏覽器支持的資料壓縮格式，如GZIP壓縮

Accept-Encoding: gzip, deflate

Accept-Language：瀏覽器通知服務器，瀏覽器支持的語言，各國語言(國際化i18n)

Accept-Language: zh-CN,zh;q=0.9

Cache-Control：指定請求和回應遵循的快取機制

對快取進行控制，如一個請求希望回應回傳的內容在客戶端要被快取一年，或不希望被快取就可以通過這個報文頭達到目的，

Cache-Control: no-cache

更多請求頭屬性可以參考這篇文章:HTTP回應頭和請求頭資訊對照表

請求體

當請求方式是post的時，請求體會有請求的引數，格式如下：

username=zhangsan&password=123

POST http://39.108.107.149:8080/vk/app/rest/ddp/iModelServiceImpl/findModelByType HTTP/1.1
User-Agent: Fiddler
Host: 39.108.107.149:8080
Content-Length: 20

name=城市&status=1

HTTP回應報文
HTTP的回應報文也由三部分組成（回應行+回應頭+空行+回應體）

  示例：

 1 HTTP/1.1 200 OK
 2 Server: Apache-Coyote/1.1
 3 Set-Cookie: JSESSIONID=E1352C5CCEAD7EA9A6F8DA253395781C; Path=/vk
 4 Content-Type: application/json;charset=UTF-8
 5 Transfer-Encoding: chunked
 6 Date: Wed, 26 Sep 2018 03:24:59 GMT
 7 //此處有空格
 8 1dd0
 9 {"sessionToken":null,"code":"1","msg":null,"service":"iModelServiceImpl","method":"findModelByType","key":null,"paras":{},"result":{"pageInfo":{"pageNum":1,"numPerPage":20,"totalCount":28,"pageNumShown":2,"startNum":0,"endNum":20},"list":[{"id":1268735016960,"vkId":1098450468864,"name":"城市","status":"1","delStatus":"2","viewIndex":0,"remark":"","dataArea":"","tvName":"城市1.xlsx","resultLang":"","setLocal":"2","c":0,"cn":"","ct":1535351516000,"l":null,"ln":null,"ltt":1535351516000,"fullMapping":"1","vkdbName":"AQI城市","itemId":16694810509312},{"id":3843924426752,"vkId":84077923270656,"name":"AQI指數","status":"1","delStatus":"2","viewIndex":0,"remark":"","dataArea":"","tvName":"aqi_table","resultLang":"","setLocal":"2","c":0,"cn":"","ct":1534668644000,"l":null,"ln":null,"ltt":1534668644000,"fullMapping":"2","vkdbName":"電商交易分析","itemId":10106414563328},{"id":4039492239360,"vkId":84077923270656,"name":"市場廣告占有率","status":"1","delStatus":"2","viewIndex":null,"remark":null,"dataArea":null,"tvName":"advertising_share","resultLang":null,"setLocal":"2","c":null,"cn":null,"ct":1534668690000,"l":null,"ln":null,"ltt":1534668690000,"fullMapping":"2","vkdbName":"電商交易分析","itemId":10106414563328},{"id":4194551463936,"vkId":84077923270656,"name":"注冊客戶增長趨勢","status":"1","delStatus":"2","viewIndex":null,"remark":null,"dataArea":null,"tvName":"a_registered_customers_growth_trend","resultLang":null,"setLocal":"2","c":null,"cn":null,"ct":1534668727000,"l":null,"ln":null,"ltt":1534668727000,"fullMapping":"2","vkdbName":"電商交易分析","itemId":10106414563328},{"id":4435954630656,"vkId":84077923270656,"name":"新業務增長分析","status":"1","delStatus":"2","viewIndex":null,"remark":null,"dataArea":null,"tvName":"a_new_business_growth_analysis","resultLang":null,"setLocal":"2","c":null,"cn":null,"ct":1534668785000,"l":null,"ln":null,"ltt":1534668785000,"fullMapping":"2","vkdbName":"電商交易分析","itemId":10106414563328},{"id":4591269707776,"vkId":84077923270656,"name":"電商公司交易趨勢","status":"1","delStatus":"2","viewIndex":null,"remark":null,"dataArea":null,"tvName":"a_electricity_supplier_trading_trend","resultLang":null,"setLocal":"2","c":null,"cn":null,"ct":1534668822000,"l":null,"ln":null,"ltt":1534668822000,"fullMapping":"2","vkdbName":"電商交易分析","itemId":10106414563328},{"id":4742163988480,"vkId":84077923270656,"name":"預算開銷對比","status":"1","delStatus":"2","viewIndex":null,"remark":null,"dataArea":null,"tvName":"a_budget_overhead_comparison","resultLang":null,"setLocal":"2","c":null,"cn":null,"ct":1534668858000,"l":null,"ln":null,"ltt":1534668858000,"fullMapping":"2","vkdbName":"電商交易分析","itemId":10106414563328},{"id":4885466578944,"vkId":84077923270656,"name":"銷售瀑布","status":"1","delStatus":"2","viewIndex":null,"remark":null,"dataArea":null,"tvName":"a_selling_waterfalls","resultLang":null,"setLocal":"2","c":null,"cn":null,"ct":1534668892000,"l":null,"ln":null,"ltt":1534668892000,"fullMapping":"2","vkdbName":"電商交易分析","itemId":10106414563328},{"id":5021173284864,"vkId":84077923270656,"name":"自定義","status":"1","delStatus":"2","viewIndex":null,"remark":null,"dataArea":null,"tvName":null,"resultLang":"select * from zyy_emp","setLocal":"2","c":null,"cn":null,"ct":1535442352000,"l":null,"ln":null,"ltt":1535442352000,"fullMapping":"2","vkdbName":"電商交易分析","itemId":236090615136256},{"id":5831709949952,"vkId":84077923270656,"name":"zy_test","status":"1","delStatus":"2","viewIndex":null,"remark":null,"dataArea":null,"tvName":"zy_test","resultLang":null,"setLocal":"2","c":null,"cn":null,"ct":1535874061000,"l":null,"ln":null,"ltt":1535874061000,"fullMapping":"1","vkdbName":"電商交易分析","itemId":16694810509312},{"id":6901450407936,"vkId":5891063545856,"name":"zy-stu","status":"1","delStatus":"2","viewIndex":0,"remark":"","dataArea":"","tvName":"zy-test.xlsx","resultLang":"","setLocal":"2","c":0,"cn":"","ct":1534676773000,"l":null,"ln":null,"ltt":1534676773000,"fullMapping":"1","vkdbName":"四川省2018年電力總分析","itemId":16694810509312},{"id":11079988019200,"vkId":84077923270656,"name":"zy-自定義sql-903","status":"1","delStatus":"2","viewIndex":0,"remark":"","dataArea":"","tvName":"","resultLang":"SELECT * from zy_test t ;","setLocal":"2","c":0,"cn":"","ct":1535944882000,"l":null,"ln":null,"ltt":1535944882000,"fullMapping":"2","vkdbName":"電商交易分析","itemId":16694810509312},{"id":12502322642944,"vkId":2084980129792,"name":"zy-stu-excel-819","status":"1","delStatus":"2","viewIndex":null,"remark":null,"dataArea":null,"tvName":"stu.xlsx","resultLang":null,"setLocal":"2","c":null,"cn":null,"ct":1534680721000,"l":null,"ln":null,"ltt":1534680721000,"fullMapping":"1","vkdbName":"2018年計算機學員資訊","itemId":16694810509312},{"id":24037057101824,"vkId":22646536273920,"name":"學生資訊","status":"1","delStatus":"2","viewIndex":null,"remark":null,"dataArea":null,"tvName":"01.xlsx","resultLang":null,"setLocal":"2","c":null,"cn":null,"ct":1535080921000,"l":null,"ln":null,"ltt":1535080921000,"fullMapping":"2","vkdbName":"2018年軟體工程學生基本資訊","itemId":16694810509312},{"id":28477864542208,"vkId":84077923270656,"name":"自定義sql_3","status":"1","delStatus":"2","viewIndex":null,"remark":null,"dataArea":null,"tvName":null,"resultLang":"select d.*,e.*\nfrom zyy_dept d ,zyy_emp e\nwhere d.deptno = e.deptno","setLocal":"2","c":null,"cn":null,"ct":1535358003000,"l":null,"ln":null,"ltt":1535358003000,"fullMapping":"2","vkdbName":"電商交易分析","itemId":236090615136256},{"id":30036178501632,"vkId":42125932625920,"name":"lllll","status":"1","delStatus":"2","viewIndex":null,"remark":null,"dataArea":null,"tvName":"t_1","resultLang":null,"setLocal":"2","c":null,"cn":null,"ct":1534753815000,"l":null,"ln":null,"ltt":1534753815000,"fullMapping":"1","vkdbName":"2018年風力分析","itemId":28899207544832},{"id":52815678406656,"vkId":84077923270656,"name":"kfeng_test_mysql","status":"1","delStatus":"2","viewIndex":0,"remark":"","dataArea":"","tvName":"sys_dictonary","resultLang":"","setLocal":"1","c":0,"cn":"","ct":1535978623000,"l":null,"ln":null,"ltt":1535978623000,"fullMapping":"2","vkdbName":"電商交易分析","itemId":16694810509312},{"id":236320945340416,"vkId":84077923270656,"name":"單表本地化存盤","status":"1","delStatus":"2","viewIndex":null,"remark":null,"dataArea":null,"tvName":"a_budget_overhead_comparison","resultLang":null,"setLocal":"1","c":null,"cn":null,"ct":1534903707000,"l":null,"ln":null,"ltt":1534903707000,"fullMapping":"2","vkdbName":"電商交易分析","itemId":236090615136256},{"id":236841471049728,"vkId":236458682089472,"name":"excel本地化存盤","status":"1","delStatus":"2","viewIndex":null,"remark":null,"dataArea":null,"tvName":"學院專業資訊表1.xlsx","resultLang":null,"setLocal":"1","c":null,"cn":null,"ct":1534903831000,"l":null,"ln":null,"ltt":1534903831000,"fullMapping":"2","vkdbName":"學員資訊表","itemId":236090615136256},{"id":240781818331136,"vkId":84077923270656,"name":"自定義sql本地化存盤","status":"1","delStatus":"2","viewIndex":null,"remark":null,"dataArea":null,"tvName":null,"resultLang":"select d.*,e.*\nfrom zyy_dept d,zyy_emp e\nwhere d.deptno = e.deptno","setLocal":"1","c":null,"cn":null,"ct":1534904771000,"l":null,"ln":null,"ltt":1534904771000,"fullMapping":"2","vkdbName":"電商交易分析","itemId":236090615136256}],"businid":null},"page":null,"appName":null,"success":true,"model":"DEFAULT","files":null,"fail":false,"request":null,"response":null}
10 0

回應行：

①報文協議及版本；

例如：

HTTP/1.1 200 OK

②狀態碼及狀態描述；

狀態碼：由3位數字組成，第一個數字定義了回應的類別

1xx：指示資訊，表示請求已接收，繼續處理

2xx：成功，表示請求已被成功接受，處理，

200 OK：客戶端請求成功
204 No Content：無內容，服務器成功處理，但未回傳內容，一般用在只是客戶端向服務器發送資訊，而服務器不用向客戶端回傳什么資訊的情況，不會重繪頁面，
206 Partial Content：服務器已經完成了部分GET請求（客戶端進行了范圍請求），回應報文中包含Content-Range指定范圍的物體內容
3xx：重定向

301 Moved Permanently：永久重定向，表示請求的資源已經永久的搬到了其他位置，

302 Found：臨時重定向，表示請求的資源臨時搬到了其他位置

303 See Other：臨時重定向，應使用GET定向獲取請求資源，303功能與302一樣，區別只是303明確客戶端應該使用GET訪問

307 Temporary Redirect：臨時重定向，和302有著相同含義，POST不會變成GET

304 Not Modified：表示客戶端發送附帶條件的請求（GET方法請求報文中的IF…）時，條件不滿足，回傳304時，不包含任何回應主體，雖然304被劃分在3XX，但和重定向一毛錢關系都沒有

4xx：客戶端錯誤

400 Bad Request：客戶端請求有語法錯誤，服務器無法理解，
401 Unauthorized：請求未經授權，這個狀態代碼必須和WWW-Authenticate報頭域一起使用，
403 Forbidden：服務器收到請求，但是拒絕提供服務
404 Not Found：請求資源不存在，比如，輸入了錯誤的url
415 Unsupported media type：不支持的媒體型別
5xx：服務器端錯誤，服務器未能實作合法的請求，

500 Internal Server Error：服務器發生不可預期的錯誤，
503 Server Unavailable：服務器當前不能處理客戶端的請求，一段時間后可能恢復正常，
回應頭：

③回應報文頭，也是由多個屬性組成；

回應頭也是用鍵值對k：v

服務器通過回應頭來控制瀏覽器的行為，不同的頭瀏覽器操作不同

更多請求頭屬性可以參考這篇文章:HTTP回應頭和請求頭資訊對照表

回應體：

④回應報文體，服務器發送給瀏覽器的正文，即我們真正要的“干貨” ；

 回應體，回應體是服務器回寫給客戶端的頁面正文，瀏覽器將正文加載到記憶體，然后決議渲染     顯示頁面內容

Content-Type詳解
前段時間在作業中負責介面的開發,使用到postman工具除錯介面，發現對http理解一直不是很深入，下來又總結了一遍，發現很多東西確實是實踐出真知，

常見的Content-Type：

application/x-www-form-urlencoded 

最常見的post提交資料的方式，瀏覽器原生的form表單，如果不設定enctype屬性，那么最終就會以application/x-www-form-urlencoded 方式提交資料

示例：

 1 POST http://39.108.107.149:8080/vk/app/rest/ddp/iModelServiceImpl/findModelByType HTTP/1.1
 2 Content-Type: application/x-www-form-urlencoded
 3 cache-control: no-cache
 4 Postman-Token: 8e602802-b4f5-4d05-96d7-e1c7a1951719
 5 User-Agent: PostmanRuntime/7.1.1
 6 Accept: */*
 7 Host: 39.108.107.149:8080
 8 cookie: JSESSIONID=6CD80B7028062D9190717CEE001C3194
 9 accept-encoding: gzip, deflate
10 content-length: 32
11 Connection: keep-alive
12 
13 name=%E5%9F%8E%E5%B8%82&status=1

首先，Content-Type 被指定為 application/x-www-form-urlencoded；其次，提交的資料按照 key1=val1&key2=val2 的方式進行編碼，key 和 val 都進行了 URL 轉碼，大部分服務端語言都對這種方式有很好的支持，

很多時候，我們用 Ajax 提交資料時，也是使用這種方式，例如 JQuery 和 QWrap 的 Ajax，Content-Type 默認「application/x-www-form-urlencoded;charset=utf-8」， 

multipart/form-data 

這又是一個常見的 POST 資料提交的方式，我們使用表單上傳檔案時，必須讓 form 的 enctyped 等于這個值，

示例：

 1 POST http://39.108.107.149:8080/vk/app/rest/ddp/iDataSourcesBaseService/file HTTP/1.1
 2 Content-Type: multipart/form-data; boundary=--------------------------629236571647111133881449
 3 cache-control: no-cache
 4 Postman-Token: 2146b4b3-2d30-469c-bbcd-fbc4693934d9
 5 User-Agent: PostmanRuntime/7.1.1
 6 Accept: */*
 7 Host: 39.108.107.149:8080
 8 cookie: JSESSIONID=6CD80B7028062D9190717CEE001C3194
 9 accept-encoding: gzip, deflate
10 content-length: 435
11 Connection: keep-alive
12 
13 ----------------------------629236571647111133881449
14 Content-Disposition: form-data; name="file"; filename="test.txt"
15 Content-Type: text/plain
16 
17 test upload
18 ----------------------------629236571647111133881449
19 Content-Disposition: form-data; name="extCode"
20 
21 test
22 ----------------------------629236571647111133881449
23 Content-Disposition: form-data; name="extId"
24 
25 3306
26 ----------------------------629236571647111133881449-- //結束標識

首先生成了一個 boundary 用于分割不同的欄位，為了避免與正文內容重復，boundary 很長很復雜，然后 Content-Type 里指明了資料是以 mutipart/form-data 來編碼，本次請求的 boundary 是什么內容，

訊息主體里按照欄位個數又分為多個結構類似的部分，每部分都是以 --boundary 開始，緊接著內容描述資訊，然后是回車，最后是最后是欄位具體內容（文本或二進制），如果傳輸的是檔案，還要包含檔案名和檔案型別資訊，訊息主體最后以 --boundary-- 標示結束，

上面提到的這兩種 POST 資料的方式，都是瀏覽器原生支持的，而且現階段原生 form 表單也只支持這兩種方式，但是隨著越來越多的 Web 站點，尤其是 WebApp，全部使用 Ajax 進行資料互動之后，我們完全可以定義新的資料提交方式，給開發帶來更多便利， 

application/json 

application/json 這個 Content-Type 作為回應頭大家肯定不陌生，實際上，現在越來越多的人把它作為請求頭，用來告訴服務端訊息主體是序列化后的 JSON 字串，由于 JSON 規范的流行，除了低版本 IE 之外的各大瀏覽器都原生支持 JSON.stringify，服務端語言也都有處理 JSON 的函式，使用 JSON 不會遇上什么麻煩， JSON 格式支持比鍵值對復雜得多的結構化資料，這一點也很有用，

示例：

 1 POST http://39.108.107.149:8080/vk/app/rest/ddp/vkIndexsService/queryVkIndxs HTTP/1.1
 2 Content-Type: application/json
 3 cache-control: no-cache
 4 Postman-Token: 5014bc39-0777-49d5-bb8a-73db9a981e49
 5 User-Agent: PostmanRuntime/7.1.1
 6 Accept: */*
 7 Host: 39.108.107.149:8080
 8 cookie: JSESSIONID=6CD80B7028062D9190717CEE001C3194
 9 accept-encoding: gzip, deflate
10 content-length: 132
11 Connection: keep-alive
12 
13 {
14 "name":"828驗證繼承",
15 "getresultType":"2",
16 "createTime":"Tue Sep 11 2018 00:00:00 GMT+0800 (中國標準時間)"
17 }

這種方案，可以方便的提交復雜的結構化資料，特別適合 RESTful 的介面，各大抓包工具如 Chrome 自帶的開發者工具、Firebug、Fiddler，都會以樹形結構展示 JSON 資料，非常友好，

————————————————
著作權宣告：本文為CSDN博主「有抱負的小獅子」的原創文章，遵循 CC 4.0 BY-SA 著作權協議，轉載請附上原文出處鏈接及本宣告，
原文鏈接：https://blog.csdn.net/weixin_38087538/article/details/82838762

回應輸出到客戶端后，服務端通過該報文頭屬告訴客戶端如何控制回應內容的快取，常見的取值有常見的取值有private、public、no-cache、max-age，no-store，默認為private，快取時間為31536000秒（365天）

標籤：其他

上一篇：語法分析--自上而下分析的基本問題

下一篇：軟體設計模式修煉 -- 抽象工廠模式