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.
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
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.
When crawling a site using Wget and Fiddler as a proxy, the hyperlinks created in the raw inspector are not correct, they include the HTTP/1.1 in the URL GET http://www.telerik.com/aspnet-mvc HTTP/1.1 Referer: http://www.telerik.com/ User-Agent: Wget/1.19.1 (mingw32) Accept: */* Accept-Encoding: identity Host: www.telerik.com Connection: Keep-Alive ... The HEX view looks good and there's a space between the URL and HTTP/1.1 To demonstrate the bug I ran this WGET command against telerik site to reproduce the error on a public site wget -r -p -k -e use_proxy=on -e http_proxy=127.0.0.1:8888 -e https_proxy=127.0.0.1:8888 https://www.telerik.com When clicking on the URL in the raw inspector I get GET http://www.telerik.com/aspnet-mvc%20HTTP/1.1 HTTP/1.1 going to this page http://www.telerik.com/aspnet-mvc in Chrome directly also gives the same result in the raw inspector. See the screenshots attached.
I'm a software tester. I often use composer to test HTTP requests.But composer needs to fill in the standard head, which is troublesome.Fiddler may enhance composer and add the standard HTTP header selection box. The history module adds some columns, such as name, URL, method, etc.I hope Fiddler is getting stronger and stronger.
I develop a lot of extensions for Fiddler. Some of them are public (http://github.com/vcsjones/FiddlerCert) , others are private to my organization. Currently Fiddler4 is built against the .NET Framework 4.0. I don't want my extensions to depend on a different version of the .NET Framework than what Fiddler requires, which lowers the burden of distributing them. If Fiddler runs, then I can be sure my 4.0 extension will too. It would be handy if Fiddler updated the .NET Framework version requirement. It would 1) give you guys more Framework to work with, and 2) allow me to up the framework requirement of my extension while still meeting the bare minimum that Fiddler itself requires. There is a considerable amount of new cryptographic faculties in the .NET Framework 4.6.1 that would be handy for my uses.
I use multiple computers. Being able to have a "sign-in" to fiddler similar to google chrome, all my settings, scripts, previous request builder scripts being accessible across these multiple computers would be a huge timesaver
Since fiddler can capture any network. But its a complicated. I just have android phone and netbook, it very difficult to intercept android if i don't have other connection via dsl or dial up. So how if Telerik make fiddler for android. Because a lot of network capture apk, just only capturing and reading data. Packet Capture by Grey Shirt or Debug Proxy or Proxydroid. All of these cannot modify or make autorespond or filtre or any great feature in Fiddler. No problem if we need you buy some coffee to coding fiddler.apk :)
We love the log requests history option in the composer and over time we build up several hundred items. It would be great if there was a simple text search of urls and content to find logged requests we want to tweak or rerun. Less important we would love the ability to drag a request from the capture listing to the log request history to use later
To my knowledge, a Fiddler extension has no means of getting the raw TLS handshake data. This would be extremely useful for some extensions I develop. Two use cases are, first, getting the TLS extensions. The primary motivation for this is to extract SCTs from the signed_certificate_timestamp extension. But I am sure there are other cases where I'll need more. The second being getting the certificate in the case of a blind tunnel when HTTPS interception is disabled, then the certificate chain could still be obtained from the ServerHello.
i would like a feature to be added to fiddler, when you replay a request/response if you could set a time delay in numbers of minutes/seconds from the next replayed request/response is sent 🤔 its so so that replays don't issue too quickly.
Now Fiddler has a limitation about maintaining its own cookie jar. When I use Composer to do a POST request simulation, if this request get a 302 response and Set-Cookies, Fiddler will automaticly redirected to the next page, but the cookies are all lost. And PostMan works well in this situation. Refer to Google Group to see the details of this issue: https://groups.google.com/forum/?fromgroups=#!topic/httpfiddler/vn1du8QdAVk
When I try to use the latest (as on Sep 10 2017) FiddlerCertMaker with Fiddler v4.6.20172.34691 it throws the below error: See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box. ************** Exception Text ************** System.TypeLoadException: Could not load type 'Fiddler.ICertificateProvider4' from assembly 'Fiddler, Version=4.6.20172.34691, Culture=neutral, PublicKeyToken=null'. at System.Reflection.RuntimeAssembly.GetExportedTypes(RuntimeAssembly assembly, ObjectHandleOnStack retTypes) at System.Reflection.RuntimeAssembly.GetExportedTypes() at Fiddler.CertMaker.() in C:\JenkinsHome\jobs\FiddlerReleaseBuild\workspace\Fiddler2\Common\Core\CertMaker.cs:line 111 at Fiddler.CertMaker.EnsureReady() in C:\JenkinsHome\jobs\FiddlerReleaseBuild\workspace\Fiddler2\Common\Core\CertMaker.cs:line 69 at ..(Object , EventArgs ) in C:\JenkinsHome\jobs\FiddlerReleaseBuild\workspace\Fiddler2\Options.cs:line 2153 at System.Windows.Forms.Control.OnClick(EventArgs e) at System.Windows.Forms.CheckBox.OnMouseUp(MouseEventArgs mevent) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ButtonBase.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
When debugging or test web applications it can be useful to increase latency or decrease bandwidth to see how your application works with poor network connections. The modem simulation rule option will do this for bandwidth but latency is more difficult to accomplish using this rule. Having the possibility to do this in a more controlled manner would be really helpful. We now have to resort to multiple tools