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).
Would really appreciate a proper machine based installation again, user-based installs are difficult to manage in corporate/enterprise environments & the psuedo machine install of redirecting install folder & creating new shortcuts isn't great, especially if as you mention yourself extensions wont work.
I understand the advantage of not needing admin rights to install programs, but surely most of the targeted audience for this application would either A) have admin rights, or B) be in a managed environment with deployment software in use (and potentially white-listing/App Control software preventing unauthorized apps to run anyway)
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
Currently by listening to FiddlerApplication.OnWebSocketMessage it's possible to modify the incoming & outgoing messages but it's not possible to send independent direct messages in or out. Adding the ability to send direct messages will give more freedom on injecting custom messages in both directions, repeating server response messages etc. Currently if you need to inject an outgoing message you need to wait for the client to generate a message and only then intercept, modify and forward it. Sometimes the client may wait longer times to respond and a direct message mechanism would be quite useful to generate quicker responses. From: How to send a new web socket message instead of modifying an existing one? (https://groups.google.com/forum/#!topic/httpfiddler/CC5XxiWfpuI) Related to: Add properties to WebSocket object (https://fiddler.ideas.aha.io/ideas/FID-I-146)
In my line of work (security research), WebSockets are becoming increasingly common as a way to mask malicious activity. Fiddler does allow you to view a WebSocket and display the blobs exchanged. However, I have ran into some issues when the data is compressed and there doesn't seem to be native support for decompression. A workaround was suggested here: https://fiddler.ideas.aha.io/ideas/FID-I-103 More generally, it would be a great feature to be able to replay a WebSocket in 'offline mode', similarly to how you can replay HTTP/S Sessions via AutoResponder.