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.
In autoresponder tab the rules could be grouped by project like the attachment . It may facilitate to users administrate your projects
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.
My Surface is work on 150% DPI , The App looks unclear. THX
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.
This is a feature that's present in both the Firefox and Chrome dev tools, and it's incredibly useful. Fiddler is already great, and that would make it so much better :-)
I find having Capture on when you start Fiddler a pain since almost always one of the first things I have to do is turn it off. I'd like the option to just have it off on startup.
Ensure that traffic from the Brave web browser is properly categorized by the traffic filtering system in the status bar.
Fiddler's "Web Browsers" filter does not include msedge.exe as a web browser. This is the executable name of the new Chromium-based version of Edge that Microsoft is now working on.
This should be a one-line fix and very much appreciated by the many thousands of Fiddler+Edge users.
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.
https://twitter.com/ericlaw/status/1232024946030862336
Today, Fiddler's AutoResponder only automatically replies to a HTTPS CONNECT with a HTTP/200 OK if the capture contains such a response, or if the "Unmatched requests passthrough" box is unchecked. Otherwise, the CONNECT request will pass or fail based on whether the real server is reachable.
This is confusing, and almost never what the user really wants to have happen.
We should add a new checkbox to the AutoResponder titled "Accept all CONNECTs" that when checked, sets a hidden rule equivalent to this rule which can be created manually
method:CONNECT
*ReplyWithTunnel
Otherwise, users will be sad when AutoResponder doesn't do what they hope, and they'll wonder why they are getting ERR_TUNNEL_CONNECTION_FAILED error messages in their browser when they have AutoResponder rules for HTTPS requests that they expect to fire.
I am not sure if it is possible or not but it would be great to be able to use Fiddler on Mac too. Mac users have very few and expensive choices when it comes to proxy tools.
The handler for the "M" key in the AutoResponder needs to suppress the keypress. Right now, if you have a rule in the "If request matches" column that starts with "M" and you select a different rule, hit "M" to add a comment to it, then Windows automatically focuses the list item that starts with "M", then Fiddler invokes the "Add Comment" action on that rule instead of the one originally selected.
https://bugs.chromium.org/p/chromium/issues/detail?id=653691 (https://bugs.chromium.org/p/chromium/issues/detail?id=653691#c5) Chrome 57 won't accept certificate chains that contain SHA-1 within them, so we need to be sure that Fiddler/FiddlerCore default to SHA-256 everywhere. We also might consider whether we should detect that the user has old Fiddler-generated SHA-1 certificates cached and if so, clean those up and generate a fresh cert using SHA-256.
User interface display problems, on the windows 10 with 4k display. After applying the-dpiaware parameter, the interface shows the disorder. Screenshot reference Attachment.
I'm trying many times this shortcut but it's doesn't work. When i'm try to copy Single Header with CTRL + C it's work but when i'm try to copy single header's value with CTRL + SHIFT + C shortcut it's didn't work.
The bug I'm reporting is sometimes the Session.HostnameIs() will return true even if the supplied hostname does not match Session.hostname and a port was passed by the client in the Host header.
HostnameIs function is documented as "This method compares the supplied hostname to the hostname of the request, returning true if a case-insensitive match is found."
What I think is happening is that rather than use Session.hostname for comparison Fiddler instead uses the Session.host (ie what was passed by the client in the Host header) and if a port is present maybe it incorrectly extracts out the hostname. Here is an example that shows the bug and why I think that.
In OnBeforeRequest add this code, which should only show an alert box if the hostname is test:
if(oSession.HostnameIs("test")) {
FiddlerObject.alert(oSession.hostname);
}
Now in a browser try going to http://t:81/ and you will see it shows the alert box, in other words a match. Why? Well, I will guess based on my testing that your code in HostnameIs gets the index of the colon in the host t:81, which is 1, and then compares only that number of characters. So it's doing whatever is the javascript equivalent of !strnicmp("t", "test", 1).
This manifests itself through CONNECT as well, and probably more likely, since the standard ports are used in the Host header (IE might be an exception to this). For example, let's say you go to https://t/ in Firefox or Chrome and HTTPS decrypt is enabled. The Host passed by the client for the CONNECT is t:443 and so it's the same problem, !strnicmp("t", "test", 1).
This is not a theoretical issue for me, I was testing something earlier today where I had to treat a hostname that ended in .co different from the same hostname that ended in .com and it turned out the test I was doing applied to both of them because of this bug.
There may be very good reason to not use Session.hostname for the comparison, I don't know, but the likely extraction from Session.host is not done properly.If fiddler was to honor the preference setting, people would have more faith in the correctness of the coding.