一、打断点和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同时阻塞多个请求了~
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
