一、打断点和AutoResponder返回404/502等状态码的不同

之前一直以为这两种方式没有区别，都是阻断了请求，改变了返回结果。但是今天在测一个问题时，恍然间明白了两者的不同。 
1、打断点，是阻塞了请求，一直没有结果返回，请求将在线程中一直存在，直到超时被踢出来。 
2、AutoResponder返回404/502，这种情况是有结果返回的，代表请求也结束了，不会在线程中一直存在。 
线程，细心的朋友可能发现了，线程，是的，在遇到线程相关的问题时，两者就明显的不同了。 
其实在发现两者在线程上的不同之后，再仔细思考这个问题，两者本质上是服务器是否响应的问题，是否有状态码的问题。打断点阻塞，没有状态码，服务器是没有响应。404/502是服务器有响应的。体现中线程中的不同，只是一个症状体现而已。

二、修改Response数据时要注意超时的问题

通过设置Rules -> Automatic Breakpoints ->After Response，之后再修改响应回来的数据，来实现修改response的内容。但是这样修改数据很容易造成另外一个问题，那就是请求超时导致客户端不对请求做处理。 
怎么理解呢？ 就是客户端发送一个请求出去，如果在指定的时间内请求没有返回，则认为该请求超时了，就算以后这个请求返回数据，则客户端也不再对请求做出响应。 
如果，修改内容的操作能够很快的进行，放行断点，在超时时间之内完成，那么修改之后的内容将会被客户端处理。 
如果，修改内容的操作大于超时时间，就算之后将断点放行，请求返回200，这个时候客户端是不做任何处理的，也可以理解为修改的内容没有产生效果。 
综合上述，一定要注意修改内容的操作时间和超时时间的关系。 
其实在修改数据的时候，不太容易去把控时间的长短，也很容易造成修改数据失误，那么怎么样才能很好的解决这个问题呢？ 
可以用AutoResponder自动响应数据，用本地文件替换服务器的返回数据。这样就不用在打断点之后急忙的修改数据，也不怕一不小心把数据修改错了。AutoResponder功能替换是一瞬间的事儿，也不用担心超时的问题，真的是一举两得啊。

三、重新认识Decode

在之前的认识中，知道有这样的Decode在工具栏中，也知道是解密的，但是在实践中并没有涉及到这块，今天就被我碰到了，而且自己也跳到坑里了，还好还好最后终于明白了。 
Decode在平时默认是被选中的，我不知道什么时候就给取消了。

今天的情况是这个样子的： 
客户端请求一个接口的数据是加密的，通过save -> response -> response body ,将返回结果保存下来，之后用这个本地文件替换服务器返回的数据。结果客户端接到数据之后，在后台报了一个错误，提示数据格式不对。 
正常的业务流程是客户端在接到数据之后，需要对数据进行解密。现在是在对数据解密的时候发现数据格式不对。 
保存下来的response body，如下所示：

服务端一阵排查问题，客户端一阵排查问题，没毛病啊！！！最后问我，你的本地文件内容是什么？我把内容贴出去之后，大家都是很疑问 6 、0 是怎么回事？ 
服务端说不是我们返回的，客户端说不是我们添加的。 
OH MY GOD ！ 我也急了，怎么可能是我这里的问题，平时都是这样用本地文件替换服务器文件的，没毛病啊！ 
后来仔细瞅了瞅，发现了 Response body is encoded ，Click to decode . 点了一下，哦~~~顿时豁然开朗。 
第一行和最后一行是数字，其实是对数据failed加的密，虽然看起来是明文，6是数据failed的长度。 
应该也看到Response body is encoded. Click to decode. understand ? 点击一下就可以解密了。 
解密之后的数据，如下所示：

这个时候再save -> response -> response body ,将返回结果保存下来，AutoResponder替换服务器文件，客户端就可以正常的解密运行了。 
问题虽然是解决了，但是得找到真正的原因啊？ 
提到解密，当然是第一时间想到了Decode，一看，居然没有被选中，突然间就明白了Decode的作用，如果返回的数据时加密的，就自动解密。 
为了验证，选中Decode，又重新请求了一次，结果你猜怎么着，还真的是这个道理。 
细节决定成败啊，任何一个小功能都不能被忽视啊！盆友们啊，都要慎重啊，慎重！

四、bpu 阻塞多个请求

背景： 
今天同事问我，bpu怎么同时阻塞多个请求呢? 
同事 : 
我是这样写的 bpu a b ,我这样写怎么实现不了同时阻塞a 和 b 请求呢？ 
我： 
我没有这样阻塞过，但是在我的理解里应该这样写，bpu a enter执行，bpu b enter执行，分开执行（因为我之前没有这样阻塞过，只是按照自己的理解这样认为的，接下来就打脸了，不都是你以为的就是你以为的啊，泪奔啊）。 
同事： 
我按照你说的方式做了，但是还是不可以啊。 
额~，好尴尬啊 
我只有默默的打开Fiddler，ctr+R打开脚本，ctr+F 输入关键字 bpu，找到bpu命令所在的核心代码 
case "bpu": 
var len = sParams.Length ; 
if(sParams.Length<2){ 
bpRequestURI=null; FiddlerObject.StatusText="bpRequestURI breakpoint cleared"; 
return false; 
} 
var len = sParams.Length ; 
bpRequestURI= sParams[1]; 
FiddlerObject.StatusText="RequestURI breakpoint for "+sParams[1]; 
return true; 
核心： bpRequestURI= sParams[1]; 只取了一个参数值。 
场景1解析（也就是同事的执行方法）： bpu /sdk /zwf ， 
使用空格隔开的，那么 
sParams[0] = “bpu” 
sParams[1] = “/sdk” 
sParams[2] = “/zwf” 
只取了sParams[1] = “/sdk”，所以只会阻塞包含/sdk的请求

场景2解析（也就是我认为的方法，允许我哭一会）： 
bpu /sdk 
bpu /zwf 
每次执行bpRequestURI，都会被赋新值，所以我阻塞包含/zwf 的请求 
我们怎么样才可以实现，阻塞多个请求呢？ 
让我沿着核心代码，顺藤抹瓜，ctr+F 输入关键字 bpRequestURI 查询，找到参数定义的地方

这个是定义变量的地方，是全局变量

//在main()方法中 // These static variables are used for simple breakpointing & other QuickExec rules     BindPref("fiddlerscript.ephemeral.bpRequestURI")
    public static var bpRequestURI:String = null;
找到使用此参数，bpRequestURI 不为null ，并且 请求的uri 包含bpRequestURI ，则阻断该请求 if ((null!=bpRequestURI) && oSession.uriContains(bpRequestURI)) {
    oSession["x-breakrequest"]="uri";
}

这样捋下来，就搞明白了，阻塞请求是怎么个原理了，是不是也很简单呢？！ 
接下来就是改造它来实现bpu 阻塞多个请求了。 
第一步： 
//在main()添加如下代码 
BindPref(“fiddlerscript.ephemeral.bpRequestURI”) 
//数组的长度10，10个阻塞的命令，内容为空格，和bpu命令用空格分割保持一致 
public static var bpRequestURIs:String[] = [” “,” “,” “,” “,” “,” “,” “,” “,” “,” “] ;

第二步：

   case "bpu":
                var len1 = sParams.Length ;
                var len2 = bpRequestURIs.Length;
                //每次赋值之前先恢复原始值                for(var i = 0; i< len2; i++){
                    bpRequestURIs[i]=" ";
                }
                if (len1 < 2) {bpRequestURI=null; FiddlerObject.StatusText="RequestURI breakpoint cleared"; return false;}


                var text = "";
                for(var i = 1; i < len1; i++){
                    bpRequestURIs[i-1] = sParams[i];
                    text += sParams[i] +" ";
                }
                FiddlerObject.StatusText="RequestURI breakpoint for " + text;
                return true;

第三步：

// 在OnBeforeRequest() 方法中 // 注释掉之前的方法 //  if ((null!=bpRequestURI) && oSession.uriContains(bpRequestURI)) { //      oSession["x-breakrequest"]="uri"; //  }        var len = bpRequestURIs.Length;
        for(var i = 0; i< len; i++){
            if(bpRequestURIs[i]!=null && bpRequestURIs[i]!= " "&& oSession.uriContains(bpRequestURIs[i]) ){
                    oSession["x-breakrequest"]="uri";
            }
        }

完成，这样就完成了bpu同时阻塞多个请求了！