HTTP/2 has been a standard since mid-2015. All major browsers support it, but adoption is slow because there no good debugging tools. I want to take advantage of pipelining, server push, etc that comes with HTTP/2 which makes it easier to adopt packages like gRPC. Having a good debugging story (both capture as well as insertion / modification) would make this more possible
When Telerik first acquired Fiddler, the community was afraid that Fiddler would become a paying tool. Telerik made an important statement: "Further, we have learned from the mistakes of others who have acquired free tools only to turn the tables on the developer community and monetize them at a later date." (source: https://www.telerik.com/about/press-releases/2012/09/10/telerik-announces-the-acquisition-of-fiddler). Recently, Telerik asked Chocolatey, a widely used Windows package management platform (https://chocolatey.org/) to remove Fiddler from the packages list. Whatever the reasons are, as a Chocolatey and Fiddler user, I am disappointed by that move. I am managing multiple machines, and Chocolatey helps me synchronize and accelerate new setups. Telerik just asked me to force manual installation of Fiddler, as well as manual upgrade (no, I don't want/need as many auto-update software as I have installed software). I see no value in doing so, except maybe forcing user registration (which is monetizing and breaks their promise) or for some legal reason. I would kindly ask Telerik to take a stance on what was communicated to the community, and allow Chocolatey to provide an easier way to get your tools installed on more machines. I'm filing this as a bug, since it was working, and it now is broken for me. Source: https://chocolatey.org/packages/fiddler4
I find myself applying the same filters again and again on each launch of Fiddler (I mean the filters listed below the list of requests). I think it would be really great if you could allow the restoration of previously applied filters (e.g. by having a save/load filters option). Also, allowing to filter out by "Request Method" would be great too. Congratulations on this tool, by the way. It is really great. :)
It's huge, doesn't have anything to do with Fiddler besides being a Telerik product, and I have no interest in it after having used previous Telerik toolkits. People already deal with ads when consuming content. Don't add them to shit we use when doing work.
I'm using v5.0.20181.13826 for .NET 4.6.1. I just upgraded today. I have a 4k display running at 3840 x 2160. I have the font scaling set to 200%. The previous version of Fiddler worked with these settings. I accepted the update when prompted today, but the Fiddler UI is no longer scaling the font. Many of the menus are inaccessible or unusable. I set my resolution to 1920 x 1080 with no scaling and the Fiddler UI was accessible. I was able to access the menus and set the Fiddler font to 16, and returned to my regular 4k display settings. Most of Fiddler was readable under this setting, but several areas don't appear to acknowledge this change. Screen shots attached.
Microsoft telemetry calls to v10.vortex-win.data.microsoft.com bypass the filters and add noise. If my filter says only show localhost, I don't expect to see calls to Microsoft.com.
Problem: Today you have to leave the application and discover Fiddler listening IPs using ipconfig or "netstat -na | findstr 8888". Having the IP address list that the tool is listening will allow a fiddler user to not leave the application to discover all the IP addresses that the tool is waiting connections. Specially useful when you need to configure the proxy settings on and Android or IOS device and need to know what IP address to point the HTTPS proxy. I'd expect to see all the bindings somewhere on the bottom toolbar. A nice addition would be also the URLs to Fiddler Echo service to be shared with users that need to install the root certificate on devices and use Fiddler as a proxy for troubleshooting.
Even after closing the Fiddler application, the instance of the process is still running and when I try to start Fiddler a second time, it shows prompt telling Fiddler is already running and do you want to start fiddler any way. If we choose Yes, then it will give another prompt telling port is in use and shall use random port. This issue is coming only after upgrading the Fiddler to the latest version from the site 4.6.3. Older versions were fine.
When viewing an average-size request (few dozens of KB, or hundrers of KB), display performance is just horrible. The Raw Inspectors take several seconds to display the request (plus they redraw multiple times uselessly, which slows down even more). This is extremely painful when scrolling thru a capture session, searching for or deleting items... a large request will sometimes get the focus and freeze Fiddler for several seconds. Given the number of times the UI is redrawn, it can easily take 20 or 30 seconds to skip a single request. Please improve display performance for average-size or large requests (or at the very least eliminate useless redraws, and make the slowdown asynchronous, so that the user can switch to another request if they clicked a large one by mistake).
Not much more to say. Fiddler on Windows is absolutely awesome, but nothing comes close on Max OS X. Please, please, please offer a native Mac OS X version. I'd hiply pay 4100 or more for it. I'd even pay that for an annual subscription.
Microsoft appears to have moved their web developer documentation from MSDN to MDN, making searches from Fiddler's toolbar return useless results. Please consider making the Search Cue text and Search URL configurable via a preference and set the defaults to "Search MDN" with a URL of https://developer.mozilla.org/en-US/search?q=$SEARCHTERMHERE&topic=apps&topic=html&topic=css&topic=js&topic=api&topic=canvas&topic=svg&topic=webgl&topic=mobile&topic=webdev&topic=http&topic=webext&topic=standards
I'm running the latest Fiddler's mono version and it would be great to be able to capture WebSockets traffic on this version. I know it is possible on the Windows version.
New compression from Google - better than gzip. Supported in Chrome and FF. See site https://www.netwarc.nl/ for an example. Fiddler is unable to decompress the response content. Also see http://www.omgchrome.com/brotli-http-compression-coming-to-chrome/ and https://textslashplain.com/2015/09/10/brotli/
Since more and more websites enforce you to use tls 1.2 (and don't support tls 1.0 any more), I suggest that the list of protocols is automatically extended with tls1.2 by a next fiddler update - or at least there should be a single-time question box with Yes-No-Cancel to extend it.
Also see reference at https://www.telerik.com/forums/some-https-sites-are-unaccessible-when-using-fiddler