Fiddler--基础操作_03---断点设置

https://www.cnblogs.com/yoyoketang/p/6778006.html

一，断点

1）Fiddler可以做到：

1. 修改HTTP请求头信息。例如修改请求头的UA, Cookie, Referer 信息，通过“伪造”相应信息达到达到相应的目的（调试，模拟用户真实请求等）。

2. 构造请求数据，突破表单的限制，随意提交数据。避免页面js和表单限制影响相关调试。

3. 拦截响应数据，修改响应实体。

为什么以上方法是重要的？假设js前端程序员和服务器程序员是分工合作的，js程序员想要调试Ajax请求的功能，这样便不必等待服务器端程序员开发好所有接口之后再开始开发js端的ajax请求功能，因为通过“模拟”真实的服务器端的响应，便可以保证功能的正确性，而服务器端开发程序员，只要保证最终的响应是符合规定的即可。这大大简化了程序开发的效率，当然也降低了不同业务线程序员联调的难度。

2）断点的设置方法：

1. fiddler菜单栏->rules->automatic Breakpoints->选择断点方式，这种方式下设定的断点会对之后的所有HTTP请求有效
2. 命令行下输入。Bpafter xxx或者bpv,bpu,bpm等设置断点。这种断点只针对特定类型的请求
3. Filters的断点设置
   
4. 用鼠标直接点击下方的这个红色小箭头区域，箭头向上是请求断点设置，箭头向下是响应断点设置，没有箭头图标，是没有设置任何断点
   

3）断点的终止方式：

1. 在inspector界面点击“run complete“即会终止本次HTTP请求的断点
2. 输入go命令，也会使得当前的请求跳过断点
3. 在rules->auto breakpoint中disabled断点即可
4. 直接用鼠标把下图中的断点图标点击到没有标识
   
   

二，请求断点

1）通过菜单栏中的Rules

这里设置的断点是全局断点，全部的请求都会被拦截

步骤：
1， 抓包，获取要修改的http请求的会话
2，点击rules->automatic breakpoints->before requests
3， 选中该请求，点击replay，再次发送请求
4， 修改请求的数据
5， 点击run to completion
请求断点：打在客户端发送数据之后，数据未到达服务端之前，fiddler停留在断点
先捕获请求会话，然后点击需要修改的会话，先选择请求断点，点Replay重新发送请求，修改数据，点击放行，记得要停止接着打断点，最下面那个小红色

举个栗子

2）QuickExec命令行设置断点，针对性断点

可以针对单一接口断点，也可以针对某个网站的断点，按照bpu 后面写的地址程度来判断
1，命令行输入：bpu XXXX（指定的地址）
2，刷新一次浏览器
3，操作修改数据
4，命令行输入：go
5，修改后的请求发送成功，查看返回的数据
6，命令行输入：bpu （关闭设置的断点）

三，响应断点

1）菜单栏中的Rules设置断点

步骤：
1， Rules->automatic breakpoints->after responses
2， 浏览器中刷新页面（客户端向服务端发起一次请求）
3， fiddler中选中要修改请求
4， 修改响应数据
5， 点击run to completion
响应断点：打在服务端返回数据之后，但未到达浏览器之前，fiddler停留在断点处

举个栗子：修改一下百度首页返回的title

1， Rules->automatic breakpoints->after responses
2， 浏览器中刷新页面（客户端向服务端发起一次请求）

3， fiddler中选中要修改请求
4， 修改响应数据
5， 点击run to completion

2）QuickExec命令行设置断点

上面同样的栗子用：可以指定哪个URL打断点
1，命令行输入：bpafter https://www.baidu.com
2，刷新一次浏览器
3，同样操作修改数据
4，命令行输入：go
5，浏览器页面修改成功
6，命令行输入：bpafter （关闭设置的断点）