ttpbin:測試 HTTP 請求及響應(yīng)的網(wǎng)站.http://httpbin.org
httpbin這個網(wǎng)站能測試 HTTP 請求和響應(yīng)的各種信息,比如 cookie、ip、headers 和登錄驗證等,且支持
GET、POST 等多種方法,對 web 開發(fā)和測試很有幫助。
一個http請求包括三個部分,為別為請求行,請求報頭,消息主體,類似以下這樣:
請求行
請求報頭
消息主體
HTTP協(xié)議規(guī)定post提交的數(shù)據(jù)必須放在消息主體中,但是協(xié)議并沒有規(guī)定必須使用什么編碼方式。服務(wù)端通過是
根據(jù)請求頭中的Content-Type字段來獲知請求中的消息主體是用何種方式進行編碼,再對消息主體進行解析,也就
是說提交的數(shù)據(jù)格式要和Content-Type字段規(guī)定的一致。具體的編碼方式包括:
application/x-www-form-urlencoded
最常見post提交數(shù)據(jù)的方式,以form表單形式提交數(shù)據(jù)。
application/json
以json串提交數(shù)據(jù)。
multipart/form-data
一般使用來上傳文件。
以form形式發(fā)送post請求
Reqeusts支持以form表單形式發(fā)送post請求,只需要將請求的參數(shù)構(gòu)造成一個字典,然后傳給requests.post( )的
data 參數(shù)即可。
可以看到,請求頭中的Content-Type字段已設(shè)置為application/x-www-form-urlencoded.
且 d = {'key1': 'value1', 'key2': 'value2'} 以form表單的形式提交到服務(wù)端,服務(wù)端返回的form字段即是
提交的數(shù)據(jù)。
以json形式發(fā)送post請求
可以將一json串傳給requests.post()的data參數(shù)
以multipart形式發(fā)送post請求
Requests也支持以multipart形式發(fā)送post請求,只需將一文件傳給requests.post()的 files 參數(shù)即可。
文本文件report.txt的內(nèi)容只有一行:Hello world!,從請求的響應(yīng)結(jié)果可以看到數(shù)據(jù)已上傳到服務(wù)端中。
boundary 用于分割不同的字段 類似于查詢字符串中的&。不是HTML產(chǎn)生的,可以自己指定。
對于學(xué)習(xí)python的學(xué)習(xí)路線,學(xué)習(xí)方法,系統(tǒng)學(xué)習(xí)規(guī)劃有任何問題,可以關(guān)注我的頭條號,私信給我”python“會自動回復(fù)python系統(tǒng)學(xué)習(xí)交流群,群里有學(xué)習(xí)路線以及詳細的規(guī)劃,我做web開發(fā)十年的時間,希望幫助新手少走彎路。
. 體系結(jié)構(gòu) 萬維網(wǎng)(WWW)服務(wù)是分布式的客戶/服務(wù)器服務(wù),客戶使用瀏覽器能夠得到服務(wù)器提供的服務(wù),這種服務(wù)的提供是分布在許多網(wǎng)站中的,如下圖所示:
圖13-1 分布式的服務(wù)
每一個網(wǎng)站保存有一個或多個文檔,叫做萬維網(wǎng)頁面。在圖12-1所示的例子中,客戶需要查看網(wǎng)站A的某些信息。瀏覽器用來讀取萬維網(wǎng)上的文檔。它向網(wǎng)站A發(fā)送一個請求,這個請求包含了網(wǎng)站A和網(wǎng)站中萬維網(wǎng)頁面的地址,這個地址叫做統(tǒng)一資源定位符(URL)。網(wǎng)站A收到請求后,將指定的文檔發(fā)送給這個客戶。它用同樣的方法與網(wǎng)站B通信。1. 客戶(瀏覽器) 許多廠商提供商用瀏覽器,可以解釋和顯示萬維網(wǎng)頁面。每一個瀏覽器通常由3個部分組成:控制程序、客戶程序及解釋程序。控制程序從鍵盤或鼠標(biāo)接收輸入,使用客戶程序訪問要瀏覽的文檔。在文檔找到后,控制程序就使用解釋程序(可以是HTML、Java或JavaScript等)中的一個,把文檔顯示在屏幕上。2. 服務(wù)器 萬維網(wǎng)頁面存儲在服務(wù)器上。每當(dāng)有客戶請求到達時,對應(yīng)的文檔就發(fā)送給客戶。為了提高效率,服務(wù)器通常在其高速緩存中存儲被請求過的文檔;對高速緩存進行訪問要比磁盤快得多。通過多線程或多進程可使服務(wù)器的效率更加提高,服務(wù)器在同一時間可回答多個請求。3. 統(tǒng)一資源定位符(URL) 客戶要訪問萬維網(wǎng)頁面就需要這個頁面地址。為了方便地訪問文檔,HTTP協(xié)議使用統(tǒng)一資源定位符(URL)。URL是Internet上指定信息的標(biāo)準(zhǔn)。URL由4部分組成:協(xié)議、主機、端口和路徑,如下圖所示:
圖13-2 URL
協(xié)議:協(xié)議指定了用這個URL的客戶/服務(wù)器程序。例如,HTTP協(xié)議、FTP協(xié)議和TELNET協(xié)議等。 主機:主機指明了信息所存放的地址,可以是邏輯地址也可以是相應(yīng)的域名。存放萬維網(wǎng)頁面的計算機通常使用以字符"WWW"開始的域名,但這不是強制性的。 端口:端口指定了使用主機的某個端口,端口是可選的。如果包含了端口,那么端口就插入在主機和路徑之間,和主機用冒號分隔開。 路徑:路徑指定了文件存放的位置。路徑本身可以包含斜線,用于將目錄與子目錄和文件分隔開。二. 萬維網(wǎng)文檔 萬維網(wǎng)文檔可分為3類:靜態(tài)文檔、動態(tài)文檔和活動文檔。這種分類是基于文檔內(nèi)容被確定的時間。1. 靜態(tài)文檔 靜態(tài)文檔是固定內(nèi)容的文檔,它由服務(wù)器創(chuàng)建,并存儲在服務(wù)器中。客戶只能得到文檔的一個副本。換言之,文件的內(nèi)容是在文件被創(chuàng)建時就確定的,而不是在它被使用時。當(dāng)然,在服務(wù)器中的內(nèi)容是可以改變的,但用戶不能改變它。當(dāng)客戶訪問文檔時,文檔的一個副本就被發(fā)送出去。用戶可以使用瀏覽程序顯示這個文檔,如下圖所示:
圖13-3 靜態(tài)文檔
2. 動態(tài)文檔 動態(tài)文檔是在瀏覽器請求該文檔時才由萬維網(wǎng)服務(wù)器創(chuàng)建出來。當(dāng)請求到達時,萬維網(wǎng)服務(wù)器就運行創(chuàng)建動態(tài)文檔的應(yīng)用程序。服務(wù)器返回這個程序或腳本的輸出,把它作為對請求該文檔的瀏覽器的響應(yīng)。因為對每一個請求都創(chuàng)建出新的文檔,因此每一個請求得到的動態(tài)文檔的內(nèi)容就會不同。3. 活動文檔 對于許多應(yīng)用,需要程序能夠在客戶端運行,這就叫做活動文檔。當(dāng)瀏覽器請求活動文檔時,服務(wù)器就發(fā)送這個文檔的一個副本或腳本。然后這個文檔就在客戶(瀏覽器)端運行。
三. HTTP協(xié)議簡介四. HTTP報文格式
三. HTTP協(xié)議簡介 HTTP(超文本傳輸協(xié)議)主要用于訪問萬維網(wǎng)上的數(shù)據(jù)。協(xié)議以普通文本、超文本、音頻、視頻等格式傳輸數(shù)據(jù)。之所以稱為超文本協(xié)議,原因是在應(yīng)用環(huán)境中,它可以快速的在文檔之間跳轉(zhuǎn)。HTTP在熟知端口80上使用TCP服務(wù)。四. HTTP報文格式 HTTP報文有兩種一般的類型:請求和響應(yīng)。這兩種類型的報文格式幾乎是相同的。報文格式如下圖所示:
圖13-4 HTTP報文格式
五. HTTP方法
五. HTTP方法 HTTP報文中的方法是客戶端向服務(wù)器端發(fā)出的實際命令和請求。常用HTTP方法如下表所示:
表13-1 HTTP方法
六. HTTP狀態(tài)碼
六. HTTP狀態(tài)碼 在響應(yīng)報文中,請求行被替換為狀態(tài)行,由3位數(shù)字組成,表示請求是否被理解或被滿足。HTTP協(xié)議的狀態(tài)碼如下表所示:
表13-2 HTTP狀態(tài)碼
七. 持久與非持久連接 1. 非持久連接 2. 持久連接
七. 持久與非持久連接 在版本1.1以前的HTTP協(xié)議默認是非持久連接的,而在版本1.1中,持久連接是默認的連接。1. 非持久連接 在非持久連接中,對每一個請求/響應(yīng)都要建立一次TCP連接。非持久連接的步驟如下: ● 客戶打開TCP連接,并發(fā)送請求。 ● 服務(wù)器發(fā)送響應(yīng),并關(guān)閉連接。 ● 客戶讀取數(shù)據(jù),直到它遇到文件結(jié)束標(biāo)記;然后它關(guān)閉連接。 使用非持久連接時,對于在不同文件中的N個不同圖片的請求,連接必須打開和關(guān)閉N次。非持久連接策略給服務(wù)器造成了很大的開銷,因為服務(wù)器需要N個不同的緩存,而每次打開連接時都要使用慢開始過程。2. 持久連接 HTTP版本1.1指明持久連接是默認的策略。在使用持久連接時,服務(wù)器在發(fā)送響應(yīng)后,讓連接繼續(xù)為一些請求打開。服務(wù)器可以在客戶發(fā)送關(guān)閉請求時等待或關(guān)閉這個連接。發(fā)送端通常在每一個響應(yīng)中都發(fā)送數(shù)據(jù)長度。但是,有時發(fā)送端并不知道數(shù)據(jù)的長度(例如動態(tài)文檔或活動文檔),這時服務(wù)器就把長度不知道這件事通知客戶,并在發(fā)送數(shù)據(jù)后關(guān)閉這個連接,這樣客戶就知道數(shù)據(jù)結(jié)束的地方已經(jīng)到了。
八. HTTP代理服務(wù)器
八. HTTP代理服務(wù)器 HTTP支持代理服務(wù)器(proxy server)。代理服務(wù)器保留對最近請求的響應(yīng)的副本。在有代理服務(wù)器的情況下,HTTP客戶把請求發(fā)送給代理服務(wù)器。代理服務(wù)器檢查它的高速緩存。如果在高速緩存中有這個響應(yīng),代理服務(wù)器就直接應(yīng)答客戶的請求;反之,如果在高速緩存中沒有這個響應(yīng),代理服務(wù)器就把請求發(fā)送給相應(yīng)的HTTP服務(wù)器,當(dāng)HTTP服務(wù)器的響應(yīng)到達代理服務(wù)器時,代理服務(wù)器將該響應(yīng)轉(zhuǎn)發(fā)給客戶,同時將該響應(yīng)存儲到高速緩存中,以便以后為其它客戶的請求使用。 代理服務(wù)器減少了原始服務(wù)器的負荷,減小了通信量,也減小了延時。但是,由于使用了代理服務(wù)器,客戶必須配置成接入到代理服務(wù)器而不是那個目標(biāo)服務(wù)器。
頁面訪問
各主機打開工具區(qū)的"拓撲驗證工具",選擇相應(yīng)的網(wǎng)絡(luò)結(jié)構(gòu),配置網(wǎng)卡后,進行拓撲驗證,如果通過拓撲驗證,關(guān)閉工具繼續(xù)進行實驗,如果沒有通過,請檢查網(wǎng)絡(luò)連接。 本練習(xí)一人一組,現(xiàn)僅以主機A為例,其它主機參考主機A的操作。1. 主機A清空IE緩存。2. 主機A啟動協(xié)議分析器開始捕獲數(shù)據(jù),并設(shè)置過濾條件(提取HTTP協(xié)議)。3. 主機A啟動IE瀏覽器,在"地址"框中輸入http://服務(wù)器的ip/experiment,并連接,服務(wù)器IP默認為172.16.0.253。4. 主機A停止捕獲數(shù)據(jù),分析捕獲到的數(shù)據(jù),并回答以下問題: ● 本練習(xí)使用HTTP協(xié)議的哪種方法?簡述這種方法的作用。 ● 根據(jù)本練習(xí)的報文內(nèi)容,填寫下表。
表13-3 實驗結(jié)果
● 參考"會話分析"視圖顯示結(jié)果,繪制此次訪問過程的報文交互圖(包括TCP協(xié)議)。 ● 簡述TCP協(xié)議和HTTP協(xié)議之間的關(guān)系。
頁面提交
本練習(xí)一人一組,現(xiàn)僅以主機A為例,其它主機參考主機A的操作。1. 主機A啟動協(xié)議分析器開始捕獲數(shù)據(jù),并設(shè)置過濾條件(提取HTTP協(xié)議)。2. 主機A啟動IE瀏覽器,在"地址"框中輸入"http://服務(wù)器的ip/experiment/post.html",并連接,服務(wù)器IP默認為172.16.0.253。在返回頁面中,填寫"用戶名"和"密碼",點擊[確定]按鈕。3. 主機A停止捕獲數(shù)據(jù),分析捕獲到的數(shù)據(jù),并回答以下問題: ● 本練習(xí)的提交過程使用HTTP協(xié)議的哪種方法?簡述這種方法的作用。 ● 此次通信分幾個階段?每個階段完成什么工作? ● 參考"會話分析"視圖顯示結(jié)果,繪制此次提交過程的報文交互圖(包括TCP協(xié)議)。
獲取頁面信息
本練習(xí)一人一組,現(xiàn)僅以主機A為例,其它主機參考主機A的操作。1. 主機A啟動實驗平臺工具欄中的"TCP工具"。2. 主機A啟動協(xié)議分析器開始捕獲數(shù)據(jù),并設(shè)置過濾條件(提取HTTP協(xié)議)。3. 主機A在"TCP工具"上,選中"客戶端"單選框,設(shè)置"IP地址"為服務(wù)器IP(172.16.0.253);設(shè)置"端口"為80;單擊[連接]按鈕來和服務(wù)器建立連接。4. 主機A在"TCP工具"上,設(shè)置"發(fā)送數(shù)據(jù)(文本)"為以下內(nèi)容: HEAD /experiment/ HTTP/1.1<CRLF> Host: 172.16.0.253<CRLF> <CRLF> 點擊[發(fā)送]按鈕。 (注:<CRLF>是回車換行) 點擊[斷開]按鈕,斷開TCP連接(由于不同http版本所遵循的規(guī)范不同,有些HTTP服務(wù)器不需要斷開操作)。 5. 主機A在"TCP工具"上的"顯示數(shù)據(jù)(文本)"中察看服務(wù)器返回信息。6. 主機A停止捕獲數(shù)據(jù),分析捕獲到的數(shù)據(jù)。
較復(fù)雜的頁面訪問
本練習(xí)一人一組,現(xiàn)僅以主機A為例,其它主機參考主機A的操作。1. 本練習(xí)中要求各主機設(shè)置DNS服務(wù)器地址(DNS服務(wù)器的IP地址即主控中心平臺的IP地址),其IP地址以172.16.0.253為例。2. 主機A使用"ipconfig /flushdns"命令清空DNS高速緩存。3. 主機A啟動協(xié)議分析器開始捕獲數(shù)據(jù)并設(shè)置過濾條件(提取DNS、HTTP協(xié)議)。4. 主機A啟動IE瀏覽器,在地址框中輸入http://JServer.NetLab/complexpage.htm。5. 主機A停止捕獲數(shù)據(jù),察看相關(guān)會話,分析捕獲到的數(shù)據(jù),并回答以下問題: ● 結(jié)合本次實驗結(jié)果,簡述瀏覽器是如何處理一個訪問請求的。6. 恢復(fù)網(wǎng)絡(luò)環(huán)境,將"首選DNS服務(wù)器"清空。
1. 一個主頁是否只有一個連接?
1. 同時打開多個瀏覽器窗口并訪問一個WEB站點的不同頁面時,系統(tǒng)是根據(jù)什么把返回的頁面正確地顯示到相應(yīng)窗口的?
1. 為什么HTTP不保持與客戶端的TCP連接?
,一般現(xiàn)在流傳的HTTP請求:GET和POST的比較是這樣的:
GET和POST是HTTP的兩個常用方法。
什么是HTTP?
超文本傳輸協(xié)議(HyperText Transfer Protocol -- HTTP)是一個設(shè)計來使客戶端和服務(wù)器順利進行通訊的協(xié)議。
HTTP在客戶端和服務(wù)器之間以request-responseprotocol(請求-回復(fù)協(xié)議)工作。
GET- 從指定的服務(wù)器中獲取數(shù)據(jù)
POST- 提交數(shù)據(jù)給指定的服務(wù)器處理
GET方法:
使用GET方法時,查詢字符串(鍵值對)被附加在URL地址后面一起發(fā)送到服務(wù)器:
/test/demo_form.jsp?name1=value1&name2=value2
特點:
· GET請求能夠被緩存
· GET請求會保存在瀏覽器的瀏覽記錄中
· 以GET請求的URL能夠保存為瀏覽器書簽
· GET請求有長度限制
· GET請求主要用以獲取數(shù)據(jù)
POST方法:
使用POST方法時,查詢字符串在POST信息中單獨存在,和HTTP請求一起發(fā)送到服務(wù)器:
POST/test/demo_form.jsp HTTP/1.1
Host:w3schools.com
name1=value1&name2=value2
特點:
· POST請求不能被緩存下來
· POST請求不會保存在瀏覽器瀏覽記錄中
· 以POST請求的URL無法保存為瀏覽器書簽
· POST請求沒有長度限制
GET和POST的區(qū)別:
其他HTTP請求方式
二,本質(zhì)上,這些并不是HTTP的GET和POST兩者請求的區(qū)別,這些區(qū)別是建立在HTML標(biāo)準(zhǔn)對于HTTP協(xié)議的用法的約定之上的。
1. GET和POST與數(shù)據(jù)如何傳遞沒有關(guān)系
GET和POST是由HTTP協(xié)議定義的。在HTTP協(xié)議中,Method和Data(URL, Body, Header)是正交的兩個概念,也就是說,使用哪個Method與應(yīng)用層的數(shù)據(jù)如何傳輸是沒有相互關(guān)系的。
HTTP沒有要求,如果Method是POST數(shù)據(jù)就要放在BODY中。也沒有要求,如果Method是GET,數(shù)據(jù)(參數(shù))就一定要放在URL中而不能放在BODY中。
那么,網(wǎng)上流傳甚廣的這個說法是從何而來的呢?我在HTML標(biāo)準(zhǔn)中,找到了相似的描述。這和網(wǎng)上流傳的說法一致。但是這只是HTML標(biāo)準(zhǔn)對HTTP協(xié)議的用法的約定。怎么能當(dāng)成GET和POST的區(qū)別呢?
而且,現(xiàn)代的Web Server都是支持GET中包含BODY這樣的請求。雖然這種請求不可能從瀏覽器發(fā)出,但是現(xiàn)在的Web Server又不是只給瀏覽器用,已經(jīng)完全地超出了HTML服務(wù)器的范疇了。
2. HTTP協(xié)議對GET和POST都沒有對長度的限制
HTTP協(xié)議明確地指出了,HTTP頭和Body都沒有長度的要求。而對于URL長度上的限制,有兩方面的原因造成:
1. 瀏覽器。據(jù)說早期的瀏覽器會對URL長度做限制。據(jù)說IE對URL長度會限制在2048個字符內(nèi)(流傳很廣,而且無數(shù)同事都表示認同)。但我自己試了一下,我構(gòu)造了90K的URL通過IE9訪問live.com,是正常的。網(wǎng)上的東西,哪怕是Wikipedia上的,也不能信。
2. 服務(wù)器。URL長了,對服務(wù)器處理也是一種負擔(dān)。原本一個會話就沒有多少數(shù)據(jù),現(xiàn)在如果有人惡意地構(gòu)造幾個幾M大小的URL,并不停地訪問你的服務(wù)器。服務(wù)器的最大并發(fā)數(shù)顯然會下降。另一種攻擊方式是,把告訴服務(wù)器Content-Length是一個很大的數(shù),然后只給服務(wù)器發(fā)一點兒數(shù)據(jù),嘿嘿,服務(wù)器你就傻等著去吧。哪怕你有超時設(shè)置,這種故意的次次訪問超時也能讓服務(wù)器吃不了兜著走。有鑒于此,多數(shù)服務(wù)器出于安全啦、穩(wěn)定啦方面的考慮,會給URL長度加限制。但是這個限制是針對所有HTTP請求的,與GET、POST沒有關(guān)系。
*請認真填寫需求信息,我們會在24小時內(nèi)與您取得聯(lián)系。