0、寫在前面的話
以前看了阮一峯老師關於互聯網協議入門的博客,受益不淺,接着再去體會了下HTTP協議,就想着看實際網絡訪問中的那些HTTP請求頭和響應是什麼樣的。Chrome的調試工具的Network選項其實已經夠用了,可是其格式爲了方便觀看作了調整,我想看原生的,就從網友處得知了比較專業的抓包工具:Fiddler。
基本使用仍是比較簡單的,能夠直接參考博客《
Fiddler 教程》。這裏想要吐槽的是,本人電腦的不知道什麼環境致使的Fiddler沒法抓取網頁的https請求,這個設置是能夠直接在軟件上打開的,然而個人電腦始終開啓後不生效,各類谷歌各類調鼓搗了超過4h仍然無果!如今那麼多網站都開始用https,不能抓取https的抓包工具豈不是逐漸成爲一隻鹹魚了。而我在同事一樣的win10 x64電腦同版本Fiddler設置抓取https,只按照普通設置花了大概3min不到就OK了,個人心態是崩潰的,謝謝。
另外,本文涉及的如何讓手機端也能在電腦上經過Fiddler抓包分析,請參考連接《
fiddler 手機 https 抓包》,主要參考文中的代理設置部分,若是不是抓取https,其餘的如證書安裝能夠略過。
一、背景介紹
以前看到一篇博客關於Fiddler的好處在於能夠在實際線上環境調整腳本代碼,即攔截腳本,本地修改後返回,在真實的環境下去調試,從而最大限度的減小bug發生的可能性。沒想到,昨天晚上就給我遇到了,老大問我公衆號的微信綁定爲何點擊肯定按鈕以後沒有反應,最終定位發現綁定在後臺是生效了,Ajax反饋前端的響應前端也收到了,問題在於回調函數。
$(function(){
//綁定
$("#bound").click(function() {
var username = $("#username").val();
var password = $("#password").val();
if(username.trim() == "" || password.trim() == "") {
weui.topTips('用戶名或密碼不得爲空', 1500);
return;
}
$().invoke("/weChat/grading/do/checkDepartment.q", {username:username, password:password}, function(re) {
if(re == 'error') {
weui.topTips('用戶名或密碼錯誤', 1500);
} else {
weui.confirm('綁定考級點:' + re,
//肯定
function() {
$().invoke("/weChat/grading/do/bound.q", {username:username, password:password}, function(re) {
if('success' == re) {
weui.alert('綁定成功', function() {
wx.closeWindow();
});
} else {
weui.alert(re);
}
});
},
//取消
function() {
//none
});
}
});
});
});
二、方法1:Fiddler斷點抓包改響應
既然大概知道是回調函數出了問題,那麼先來判斷是回調函數沒有調用,仍是回調函數中的方法沒生效,仍是條件進入出現了問題。
Fiddler能夠在響應返回以前的「
請求以前」和「
請求以後」兩種狀態進行斷點,分別
能夠修改即將發送出去的請求和即將返回的響應,兩種方式在命令行的表示分別爲:
咱們要改返回的腳本,因此也就是「請求以後」,則在命令行輸入 bpafter {url}:
在進入綁定頁面的時候,能夠看到已經對該部分進行了攔截:
咱們直接在響應中修改代碼,增長兩行alert用以斷定函數失效的位置,修改完成後,直接點擊Run to Completion便可:
結果兩個alert都觸發了,那麼問題出在哪呢,顯然就是weui.alert的問題了:
weui.alert方法是微信官方提供的js文件,並且我在本地運行,經過微信測試號進行測試時是ok的,客戶的公衆號正式上線以後,也測試是ok的,如今忽然莫名其妙就不生效了,你說氣不氣?關鍵是我再次用測試號進行測試,仍是有效的,就是在正式環境不行,我不懂,不知道是服務器環境問題,仍是正式公衆號和測試公衆號有什麼區別。因此這就是能在所謂真實線上環境調試才能儘量減小bug的緣由吧,謎,得燒香。
接下來其實能夠繼續使用這個方法進行調試修改,爲了介紹另外一種方式,接下來的修改就採用自動攔截的方式,不過記得先清除以前的斷點攔截,輸入bpafter不帶url便可清除:
三、方法2:Fiddler自動攔截改響應
Fiddler能夠設置規則,自動對符合條件的url請求進行攔截,並返回指定的響應。這意味着咱們能夠把內容直接寫在本地的一個文件裏,自動攔截設置爲返回該文件,因此咱們每次調試代碼只須要修改本地文件便可,這樣一來:
- 環境仍然是真實的服務器環境
- 本地修改不會影響服務器的文件,也不會影響其餘人的請求
- 本地能夠修改存儲,比斷點修改調試要方便不少
先把代碼寫在本地的一個txt文件中,由於是做爲響應返回,因此不能單純是文件內容,還應該加上響應頭,文件內容只是做爲響應內容體:
接下來設置自動攔截響應:
- 找到AutoResponder頁面
- 點擊Add Rule添加攔截規則
- 編輯攔截規則,分別對應攔截的url和返回的響應內容
- 選擇啓用規則Enable rules
好了,接下來咱們直接修改本地文件的內容。既然weui.alert在線上有問題,那麼咱們用它其餘的api,好比weui.toast:
保存好文件,再次訪問頁面,能夠看到fiddler的響應中,確實返回的是咱們本地文件的內容:
發現weui.toast在線上能夠正常運行:
那麼調試ok之後,直接把服務器上的內容按調試後的代碼進行修改從新部署,就好了。
fiddler的兩種方式修改響應,是否是很方便呢?