HttpWatch安裝與開啟
1.下載HttpWatch PRo,將專業版的許可文件.lic和安裝程序置于同一文件夾。運行安裝程序,點擊【Next】完成安裝。
2.打開IE瀏覽器,建議使用最新的IE11瀏覽器。默認HttpWatch已經開啟并顯示在頁面下方,如果關掉了可以使用快捷鍵【Shift+F2】開啟或者【菜單欄->查看->瀏覽器欄->HttpWatch Professional】。

HttpWatch實例講解以下用登錄我的郵箱mail.163.com例子來展示Httpwatch:
點擊“Record”后,在IE打開需要錄制的網址,mail.163.com,輸入用戶名,密碼后完成登錄操作

1. 3.1 Overview(概要)
表示選定某個信息顯示其概要信息

如上圖紅框所示:
URL: http://mimg.163.com/external/closea_d.js
Result:200
請求的URL是http://mimg.163.com/external/closea_d.js ,返回的Htpp狀態代碼結果200,表示成功;
Resync URL Browser requested refresh if changed - http://mimg.163.com/external/closea_d.js
瀏覽器請求的URL
Started At 2008-Jan-04 09:21:09.422 (local time)
請求開始時間(實際記錄的是本機的時間)
Connect Connect to ip address '218.107.55.86'
請求的網址的IP地址
Http Request Unconditional request sent for http://mimg.163.com/external/closea_d.js
Http請求,當瀏覽器向Web服務器發出請求時,它向服務器傳遞了一個數據塊,也就是請求信息
Http Response Headers and content returned
Http響應,當瀏覽器接受到web服務器返回的信息時
2. 3.2 Header(報頭)
表示從Web服務器發送和接受的報頭信息;
http://g1a90.mail.163.com/a/p/main.htm?sid=UBDCcOJJDknBulMFzSJJipPzfROMNqHO

如上圖紅框所示:
Http請求頭發送信息
Headers Sent value
Request-Line GET /external/closea_d.js HTTP/1.1
以上代碼中“GET”代表請求方法,“closea_d.js”表示URI,“HTTP/1.1代表協議和協議的版本。
Accept **表示所有
Accept-Encoding gzip, deflate
Accept-Encoding表明了瀏覽器可接受的除了純文本之外的內容編碼的類型,比如gzip壓縮還是deflate壓縮內容。
Accept-Language zh-cn
表示能夠接受的返回數據的語言
Connection Keep-Alive
保持Tcp請求連接
備注:在HTTP工作開始之前,Web瀏覽器首先要通過網絡與Web服務器建立連接,該連接是通過TCP來完成的,該協議與IP協議共同構建Internet,即著名的TCP/IP協議族,因此Internet又被稱作是TCP/IP網絡。HTTP是比TCP更高層次的應用層協議,根據規則,只有低層協議建立之后才能,才能進行更層協議的連接,因此,首先要建立TCP連接,一般TCP連接的端口號是80
Cookie vjuids=-1b9063da8.1173d33f879.0.9aab8b85a459d; vjlast=1199406314; _ntes_nnid=a1e69963f40453af8a9ad171cc4cd8da,0|tech|; NTES_UFC=3000000100000000000000000000000000000000000000000000000000000000; Province=021;
City=021; ntes_mail_firstpage=normal; NTES_SESS=68LUOUH9ewcCBFyN5OXZ_0qf._
IOMCkFscaGYrooXpjtVF7r8Vx7jAzg7HGdWo00GQEn1ZmrZcX7FMAXnb052r8XOFZZYk.hN;
NETEASE_SSN=mayingbao2002; NETEASE_ADV=11&23&1199409658752;
Coremail=VDeAMrrrDFaTa%XCVwJiXXsRLSLkbLhZXXZGqPJkEXFKNt
Cookie沒什么說的就是客戶端記錄相關信息
Host mimg.163.com
請求連接的主機名稱’
Referer Http://g1a114.mail.163.com/a/p/main.htm?sid=XCVwJiXXsRLSLkbLhZXXZGqPJkEXFKNt
包含一個URL,用戶從該URL代表的頁面出發訪問當前請求的頁面
User-Agent Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
客戶端標識瀏覽器類型
Http請求頭返回信息
Headers Received Value
Status-Line Http/1.0 200 ok
表示Http服務端響應返回200
Accept-Ranges bytes
Http請求范圍的度量單位
Age 117
表示Http接受到請求操作響應后的緩存時間
Cache-Control max-age=3600
一個用于定義緩存指令的通用頭標
Connection keep-alive
保持Tcp請求連接
Content-Type application/x-javascript
標明發送或者接收的實體的MIME類型
Date Fri, 04 Jan 2008 01:12:26 GMT
發送HTTP消息的日期
Etag "10f470-734-b32eb00"
一種實體頭標,它向被發送的資源分派一個唯一的標識符
Expires Fri, 04 Jan 2008 02:12:26 GMT
指定實體的有效期
Last-Modified Fri, 04 Jan 2008 01:01:00 GMT
指定被請求資源上次被修改的日期和時間
Server Apache
一種標明Web服務器軟件及其版本號的頭標
X-Cache HIT from mimg68.nets.com
表示你的 http request 是由 proxy server 回的
3. 3.3 Cookies
顯示Cookies信息

如上圖所示City=021,其實是我163郵箱中設置城市信息值,在Cookies中記錄為021(代表上海這個城市)

備注:
什么是cookie?Cookie是一種在客戶端保持HTTP狀態信息的技術,Cookie是在瀏覽器訪問WEB服務器的某個資源時,由WEB服務器在HTTP響應消息頭中附帶傳送給瀏覽器的一片數據,WEB服務器傳送給各個客戶端瀏覽器的數據是可以各不相同的。
瀏覽器可以決定是否保存這片數據,一旦WEB瀏覽器保存了這片數據,那么它在以后每次訪問該WEB服務器時,都應在HTTP請求頭中將這片數據回傳給WEB服務器。
顯然,Cookie最先是由WEB服務器發出的,是否發送Cookie和發送的Cookie的具體內容,完全是由WEB服務器決定的。
Cookie在瀏覽器與WEB服務器之間傳送的過程如圖7.1所示。


4. 3.4 Cache(緩存)
顯示在請求完成前后的瀏覽器緩存里URL地址欄里的詳細信息

5. 3.5 Query String(查詢字符串)
顯示查詢字符串被用在是傳遞參數url中
如下圖所示:
http://reg.yodao.com/setcookie.jsp?username=mayingbao2002&domain=yodao.com&loginCookie=
uaLr3t2p5wKi_ku90vYy04gK1MamttMzYGFxdsppqrz3ZhjsWZ8jzDlVjmxEIpSSx2hn__
w3ZsoBSFu6gKRZyRUdIgZYzVciX&clearPersistCookie=

如上面的紅框中顯示的mayingbao2002字符串,是存在于請求的URL傳遞的參數
6. 3.6 POST Data
顯示通過Post方式數據信息
以下是mail.163.com登錄過程中POST Data,如下圖所示:
https://reg.163.com/logins.jsp?type=1&url=http://fm163.163.com/coremail/fcg/ntesdoor2?lightweight=1&verifycookie=1&language=-1&style=-1
上面的紅框:application/x-www-form-urlencoded表示,post方式默認提交數據編碼
備注:以下為Post方式提交數據編碼幾種方式:
| text/plain | 以純文本的形式傳送 |
| application/x-www-form-urlencoded | 默認的編碼形式,即URL編碼形式 |
| multipart/form-data | MIME編碼,上傳文件的表單必須選擇該 |
Mime Type指的是如text/html,text/xml等類型
MIME(Multipurpose Internet Email Extension),意為多用途Internet郵件擴展,它是一種多用途網際郵件擴充協議,在1992年最早應用于電子郵件系統,但后來也應用到瀏覽器。服務器會將它們發送的多媒體數據的類型告訴瀏覽器,而通知手段就是說明該多媒體數據的MIME類型,從而讓瀏覽器知道接收到的信息哪些是MP3文件,哪些是JPEG文件等等。當服務器把把輸出結果傳送到瀏覽器上的時候,瀏覽器必須啟動適當的應用程序來處理這個輸出文檔。在HTTP中,MIME類型被定義在部分的Content-Type中。
| 數據類型 | MIME類型 |
| 超文本標記語言文本 .htm,.html文件 | text/html(數據類別是text,種類是html,下同) |
| 純文本,.txt文件 | text/plain |
| RTF文本,.rtf文件 | application/rtf |
| GIF圖形,.gif文件 | image/gif |
| JPEG圖形,.jpeg, .jpg文件 | image/jpeg |
| au聲音,.au文件 | audio/basic |
| MIDI音樂,mid,.midi文件 | audio/midi,audio/x-midi |
| RealAudio音樂,.ra, .ram文件 | audio/x-pn-realaudio |
| MPEG,.mpg,.mpeg文件 | video/mpeg |
| AVI,.avi文件 | video/x-msvideo |
| GZIP,.gz文件 | application/x-gzip |
| TAR,.tar文件 | application/x-tar |
如上圖紅圈所表示,可以看到POST Data 中的passWord和username數據;

備注:get方法和Post方法區別
GET方法
GET方法是默認的HTTP請求方法,我們日常用GET方法來提交表單數據,然而用GET方法提交的表單數據只經過了簡單的編碼,同時它將作為URL的一部分向Web服務器發送,因此,如果使用GET方法來提交表單數據就存在著安全隱患上。例如
Http://127.0.0.1/login.jsp?Name=zhangshi&Age=30&Submit=�%E+��
從上面的URL請求中,很容易就可以辯認出表單提交的內容。(?之后的內容)另外由于GET方法提交的數據是作為URL請求的一部分所以提交的數據量不能太大
POST方法
POST方法是GET方法的一個替代方法,它主要是向Web服務器提交表單數據,尤其是大批量的數據。POST方法克服了GET方法的一些缺點。通過POST方法提交表單數據時,數據不是作為URL請求的一部分而是作為標準數據傳送給Web服務器,這就克服了GET方法中的信息無法保密和數據量太小的缺點。因此,出于安全的考慮以及對用戶隱私的尊重,通常表單提交時采用POST方法。
7. 3.7 Content
統計顯示收到的Http響應信息
如下圖所示:可以查看

https://reg.163.com/logins.jsp?type=1&url=http://fm163.163.com/coremail/fcg/ntesdoor2?lightweight=1&verifycookie=1&language=-1&style=-1
頁響應具體內容:
8. 3.8 Stream
顯示客戶端發送的數據,然后服務器端返回的數據
客戶端發送總數據:901 bytes sent to 218.107.55.86:80
客戶端接受到服務器端返回總數據:247 bytes received by 192.168.52.188.10720
以下用請求一個mail.163.com中的Logo圖標為例說明:

http://mimg.163.com/logo/163logo.gif
左邊:客戶端向服務器端發送數據流
1 GET /logo/163logo.gif HTTP/1.1
以上代碼中“GET”代表請求方法,“closea_d.js”表示URI,“HTTP/1.1代表協議和協議的版本。
2 Accept: **表示所有
3 Referer: http://g1a114.mail.163.com/a/f/js3/0712240954/index_v6.htm
包含一個URL,用戶從該URL代表的頁面出發訪問當前請求的頁面
4 Accept-Language: zh-cn
表示能夠接受的返回數據的語言
5 Accept-Encoding: gzip, deflate
Accept-Encoding表明了瀏覽器可接受的除了純文本之外的內容編碼的類型,比如gzip壓縮還是deflate壓縮內容。
6 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
客戶端標識瀏覽器類型
7 Host: mimg.163.com
訪問地址主機標識地址
8 Connection: Keep-Alive
保持Tcp連接(前臺已有備注,這里不做說明)
9Cookie: vjuids=-1b9063da8.1173d33f879.0.9aab8b85a459d; vjlast=1199406314; _ntes_nnid=a1e69963f40453af8a9ad171cc4cd8da,0|tech|; NTES_UFC=3000000100000000000000000000000000000000000000000000000000000000; Province=021;
City=021; ntes_mail_firstpage=normal; NTES_SESS=68LUOUH9ewcCBFyN5OXZ_0qf._
IOMCkFscaGYrooXpjtVF7r8Vx7jAzg7HGdWo00GQEn1ZmrZcX7FMAXnb052r8XOFZZYk.hN;
NETEASE_SSN=mayingbao2002; NETEASE_ADV=11&23&1199409658752;
Coremail=VDeAMrrrDFaTa%XCVwJiXXsRLSLkbLhZXXZGqPJkEXFKNt; wmsvr_domain=g1a114.mail.163.com
Cookies沒什么說的,前面已列舉了
右邊:服務器端向客戶端返回數據流
1 HTTP/1.0 304 Not Modified
服務器告訴客戶,原來緩沖的文檔還可以繼續使用。
2 Date: Mon, 31 Dec 2007 21:42:27 GMT
發送HTTP消息的日期
3 Content-Type: image/gif
服務器返回請求類型是image/gif
4 Expires: Wed, 30 Jan 2008 21:42:27 GMT
指定實體的有效期
5 Last-Modified: Wed, 19 Apr 2006 03:46:16 GMT
指定被請求資源上次被修改的日期和時間
6 Age: 5607
表示Http接受到請求操作響應后的緩存時間
7 X-Cache: HIT from mimg68.nets.com
表示你的 http request 是由 proxy server 回的
8 Connection: keep-alive
保持Tcp請求連接狀態
9. 3.9 HttpWatch請求信息框
菜單區如上圖紅框所示:

Started: 表示開始記錄請求一個URL時間
Time: 表示記錄請求耗費的時間
Sent: 表示客戶端向服務器端發送請求字節大小
Reveived:表示客戶端收到服務端發送請求字節大小
Method: 表示請求URL方式
Result: 表示服務器返回到客戶端結果
以下是Httpwatch中http狀態碼列表
| 200 | OK/Success status code |
| 302 | Moved temporarily status code |
| 304 | Not modified status code |
| 401 | access denied status code |
| 404 | Page or file not found |
| Aborted | Internet Explorer aborted the HTTP request before a response was received |
| (Cache) | Content read from cache without sending an HTTP request to the server |
| ERROR_* | An error occurred such as ERROR_INTERNET_NAME_NOT_RESOLVED |
| 2xx | Successful HTTP status code |
| 3xx | Redirection HTTP status code |
| 4xx | Client error HTTP status code |
| 5xx | Server error HTTP status code |
詳細Http狀態查詢,可以參考這個
| 態代碼 | 狀態信息 | 含義 |
| 100 | Continue | 初始的請求已經接受,客戶應當繼續發送請求的其余部分。(HTTP 1.1新) |
| 101 | Switching Protocols | 服務器將遵從客戶的請求轉換到另外一種協議(HTTP 1.1新) |
| 200 | OK | 一切正常,對GET和POST請求的應答文檔跟在后面。 |
| 201 | Created | 服務器已經創建了文檔,Location頭給出了它的URL。 |
| 202 | Accepted | 已經接受請求,但處理尚未完成。 |
| 203 | Non-Authoritative Information | 文檔已經正常地返回,但一些應答頭可能不正確,因為使用的是文檔的拷貝(HTTP 1.1新)。 |
| 204 | No Content | 沒有新文檔,瀏覽器應該繼續顯示原來的文檔。如果用戶定期地刷新頁面,而Servlet可以確定用戶文檔足夠新,這個狀態代碼是很有用的。 |
| 205 | Reset Content | 沒有新的內容,但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容(HTTP 1.1新)。 |
| 206 | Partial Content | 客戶發送了一個帶有Range頭的GET請求,服務器完成了它(HTTP 1.1新)。 |
| 300 | Multiple Choices | 客戶請求的文檔可以在多個位置找到,這些位置已經在返回的文檔內列出。如果服務器要提出優先選擇,則應該在Location應答頭指明。 |
| 301 | Moved Permanently | 客戶請求的文檔在其他地方,新的URL在Location頭中給出,瀏覽器應該自動地訪問新的URL。 |
| 302 | Found | 類似于301,但新的URL應該被視為臨時性的替代,而不是永久性的。注意,在HTTP1.0中對應的狀態信息是“Moved Temporatily”。 出現該狀態代碼時,瀏覽器能夠自動訪問新的URL,因此它是一個很有用的狀態代碼。 注意這個狀態代碼有時候可以和301替換使用。例如,如果瀏覽器錯誤地請求http://host/~user(缺少了后面的斜杠),有的服務器返回301,有的則返回302。 嚴格地說,我們只能假定只有當原來的請求是GET時瀏覽器才會自動重定向。請參見307。 |
| 303 | See Other | 類似于301/302,不同之處在于,如果原來的請求是POST,Location頭指定的重定向目標文檔應該通過GET提取(HTTP 1.1新)。 |
| 304 | Not Modified | 客戶端有緩沖的文檔并發出了一個條件性的請求(一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔)。服務器告訴客戶,原來緩沖的文檔還可以繼續使用。 |
| 305 | Use Proxy | 客戶請求的文檔應該通過Location頭所指明的代理服務器提取(HTTP 1.1新)。 |
| 307 | Temporary Redirect | 和302(Found)相同。許多瀏覽器 |
新聞熱點
疑難解答