Fiddler 是目前最强大最好用的 Web 调试工具之一,它能记录所有客户端和服务器的http和https请求, 允许你监视,设置 CGI 请求的断点,甚至修改输入输出数据。同类的工具还有httpwatch,firebug,wireshark,google审查元素。与这些基于网页浏览 器的工具不同,fiddler是一个富客户端桌面工具,不仅能监听浏览器对网页的请求和对浏览器的响应(http和https请求), 而且可以监听其他程序(比如java桌面应用)的http请求(当然需要额外的设置,在此不赘述)。另外,值得一提的是,即便在浏览器的调试中,它也能胜 任其他工具,比如IE浏览器,当我们需要弹出一个模式对话框(modalDialog)时,这些浏览器监听插件就派不上用场了,还得fiddler出场。
fiddler 和常见的底层抓包(网卡)工具不一样(如wincap、wireshark),它是在 web server 和 web browser 之间搭了一层 proxy,所有的请求都会经过它,如下图所示
fiddler在客户浏览器及web服务器之间充当了一个请求及响应的代理角色,它会在本地建立一个默认代理服务,端口为8888,为此我们访问一下此端口,可见如下效果:
第一种:打开Fiddler 点击Rules-> Automatic Breakpoint ->Before Requests(这种方法会中断所有的会话)
如何消除命令呢? 点击Rules-> Automatic Breakpoint ->Disabled
第二种: 在命令行中输入命令:bpu www.baidu.com(这种方法只会中断www.baidu.com)
如何消除命令呢? 在命令行中输入命令bpu
第一种:打开Fiddler 点击Rules-> Automatic Breakpoint ->After Response (这种方法会中断所有的会话)
如何消除命令呢? 点击Rules-> Automatic Breakpoint ->Disabled
第二种: 在命令行中输入命令: bpafter www.baidu.com(这种方法只会中断www.baidu.com)
如何消除命令呢? 在命令行中输入命令bpafter,
创建重定向规则,例如将目标请求是这个js的HTTP请求重定向到本地文件
请参考阿里 UED 的这篇:使用Fiddler提高前端工作效率 (实例篇)
假设我们发现某个页面有问题,需要修改所引用的js文件(http://www.aliued.cn/wp-includes/js/comment-reply.js?ver=20090102)。
tip: 最好是没有缓存的返回内容(Result Code是200),这样可以进行下一步的保存。不是200也没关系,你只要本地硬盘上有这个文件就好了。
在这个js session上右键点击,选择“Save – Response –Response Body…”,将js文件的内容保存到本地。记住存的位置,下面我们会用到这个保存下来的文件。
打开AutoResponder标签设置。有没有看到界面上有两个复选框?第一个的作用是开启或禁用自动重定向功能,我们就可以在下面添加重定向规则了。第二个复选框框勾上时,不影响那些没满足我们处理条件的请求。
我们可以通过“Add…”按钮手动添加规则,不过这个URL已经出现在我们的session列表中,可以直接拖动过来。在左侧的Session列表中选择第一步找到的session,拖动到AutoResponse标签中。这样就创建了一个针对这个URL的规则。
Fiddler帮我们生成的规则是:
我们需要修改这个规则,
选择“Find a file…”,就可以选择本地的文件作为返回的body内容。
选择我们刚刚保存下来的文件。
刷新一下浏览器页面,看一下session列表,如果像下面这样,这个session的底色是灰色的,那么恭喜你,你已经成功将这个请求重定向到本地文件了!
tip: 如果浏览器用的是Firefox,记得先清一下临时文件缓存,因为Firefox是真正的缓存,当判断文件的缓存还未过期时,就不会再发请求出来,Fiddler就获取不到了。
我们在本地的js文件中加一句alert(‘hello’)
刷新浏览器,看看效果,如果alert出来,那就成功了。
继续修改这个文件并测试,成功修复问题后,我们就可以发布修改后的文件了。
小结:自动重定向功能是Fiddler最实用的功能,这里的Rule可以自由地设定,可以使用搜索(默认)、精确匹配(EXACT)、正则表达式匹配(REGEX)。处理方式可以选择使用文件,也可以选择合适的时间暂停数据流(*bpu、*bpafter),人工干预。通过以上几个步骤,我们演示了怎样将HTTP请求重定向到本地的文件,进行web调试。这种调试方式不需要发布到线上再验证,避免了修改不成功、对用户造成影响的风险,而且不需要搭建复杂的开发服务器等开发环境,非常适合快速web调试。
比如你可能在debug某些网页时,会遇到上百个请求,看的你眼花缭乱,这是你可以启用 fiddler 强大的过滤机制:
fiddler安装之后,默认会在IE浏览器中安装一个fiddler的插件,所以它对IE及国内基于IE内核的各类浏览器都能实现监听,但其他内核的浏览器无法被监听。
解决办法:禁用chrome和firefox中具有代理 功能的插件,比如我的chrome安装了switchSharp,禁用它或选择“使用系统代理设置”,或在switchSharp中新配置一个代理项(比 如名为fiddler,用于指向代理127.0.0.1,端口8888,如下图),即可实现监听。
使用fiddler的时候,我们更多的是基于本地程序的调试,可惜fiddler捕捉不了本地(localhost或127.0.0.1)的http请求。难道fiddler就束手无策了吗?当然不是。
一般我们访问安装在本地的服务器程序时,使用的localhost或127.0.0.1,默认会绕过代理,直接访问目标服务器,通过fiddler特有的请求方式,可以使本地请求及响应都被fiddler拦截。
方法一:在localhost后增加.fiddler
比如请求http://localhost:8080改为http://localhost.fiddler:8080即可
方法二:更简单,在localhost或127.0.0.1后增加一个点即可
比如http://localhost.:8080
https://www.cdsy.xyz/computer/soft/net/240620/cd61922.html
http://stackoverflow.com/questions/8549749/how-to-capture-https-with-fiddler-in-java
为什么想来总结一下呢,是因为最近有个测试需 求,需要检测某个网页指定的 url 请求个数,测试的同学还为此专门用 JPCAP 开发了一个系统来监听指定的网卡,抓包、解包,分析请求的数据包,然后得出指定 url 的个数。感觉这个有点大材小用了,呵呵。因为这个 fiddler 就已经可以搞定了,然后 ctrl - a、ctrl - c 即可满足需求了,只是没有完全自动化而已,呵呵。
最后题外话一下有关JPCAP 的东西:
众所周知,JAVA语言虽然在TCP/UDP传输方面给予了良好的定义,但对于网络层以下的控制,却是无能为力的。JPCAP扩展包弥补了这一点。
JPCAP实际上并非一个真正去实现对数据链路层的控制,而是一个中间件,JPCAP调用wincap/libpcap,而给JAVA语言提供一个公 共的接口,从而实现了平台无关性。在官方网站上声明,JPCAP支持FreeBSD 3.x, Linux RedHat 6.1, Fedora Core 4, Solaris, and Microsoft Windows 2000/XP等系统。JPCAP的整个结构大体上跟wincap/libpcap是很相像的,例如NetworkInterface类对应wincap 的typedef struct _ADAPTERADAPTER,getDeviceList()对应pcap_findalldevs()等等。使用 JPCAP 实现监听利用的是所谓的“ARP欺骗”技术。具体请参考:
https://www.cdsy.xyz/computer/programme/java/240621/cd61923.html