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
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)
The .NET Framework has added support for TLS/1.3.
We should do the work to enable TLS/1.3 in Fiddler (it's very little additional work to add "Tls1.3" to the options dialog and the underlying code).
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)
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/
WebSockets offer a mechanism for doing compression of messages. Fiddler's WebSocket Inspector should provide a simpler means of viewing such content. The mechanism looks to be a simple DEFLATE operation: https://tools.ietf.org/html/rfc7692
My Fiddler log is usually filled with thousands of ClientHello warnings. It's a burden for me to read through the log with all those messages. For example:
23:42:42:4843 HTTPSLint> Warning: ClientHello record was 508 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance 23:42:42:4863 HTTPSLint> Warning: ClientHello record was 508 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance 23:42:42:4863 HTTPSLint> Warning: ClientHello record was 508 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance 23:42:42:4863 HTTPSLint> Warning: ClientHello record was 508 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance 23:42:42:4983 HTTPSLint> Warning: ClientHello record was 508 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance 23:42:42:4983 HTTPSLint> Warning: ClientHello record was 508 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance 23:42:42:5113 HTTPSLint> Warning: ClientHello record was 508 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance 23:42:42:5123 HTTPSLint> Warning: ClientHello record was 508 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
I discussed this with Eric Lawrence in the Fiddler Groups thread HTTPSLint> Warning: ClientHello record was xxx bytes long and he had a few suggestions:
Hi!
Is there any way to disable underlining of URL in Raw Inspector tab? It is very annoying when you try to copy part of the request but in fact open the link in the browser instead.
I had request with json body, after exporting to curl, looking at the batch file, i didn't see the body part of the request
When Fiddler generates a certificate based on the original server certificate (using oSession["X-UseCertCNFromServer"]), it doesn't include all ServerAltNames from the original certificate.
I've attached the raw HTTP response, copied directly from Fiddler. At lOperations[0].lRecords, you'll see that there are 2 records (arrays) and that each record contains 6 items, the last of which is an array. However, when I view the resonse using the JSON filter, the second of these arrays appears to contain only 5 items. I'm sure that the bug has something to do with the fact that the sub-array in the second array is an empty array, but it should display as an empty array, not as if it weren't there at all.
Allow to search / reuse requests from history in a more efficient way 1. Add column [Date] or [Date and Time] to history, so one can look for a request that was used at a given date / time 3. Allow to sort by request Url, date / time 4. Allow to group by request urls: If there are several requests with the same url, provide the option to group / ungroup them 5. Add column [Result] with the result code for each request, so that one can now which request to use (for example, one needs a request that gave a 404, or only 202s) 6. Filter history by request type (GET, PUT, ...), url content (example: search for "/admin/ ... etc"), date / time
Greetings!
For now very popular technology in rest is graphQL
We use it in our project
Could you please add graphQl in Fiddler?
Thx
I would like a way to block all transfers made internally by Fiddler unrelated to what is being proxied because it disrupts my tests. I am using Fiddler in test cases where I need the data to be limited to what I'm sending through Fiddler. Every time Fiddler is started it makes one or more connections to fiddler2.com. For example http://fiddler2.com/Banners/BannerVersion.txt and also there's a survey connection sometimes as well. Those requests are redirected most of the time to a cloud server. I have to use various VM images to run some of the tests and I see it a lot in the packet captures. The update check I have blocked in the registry where I set BlockUpdateCheck to True. I could ignore fiddler2.com I suppose. Regardless I don't like it there is SSL traffic I can't account for or decrypt, and even if I could it would still be noise disrupting the data I need to check.
I found a preference fiddler.banners.showdefault and fiddler.telemetry.AskPermission but I'm not sure if they relate.
On a somewhat related point consider an option to disable telemetry, refer to Fiddler Script Editor disable internet access
It would be highly useful if there was a "URL splitter" tool added, perhaps as a drop-down entry in the TextWizard, which takes a long-form paramaterized URL and splits it into a line-separated list of individual parameters (and can go the opposite way direction as well).
The "WebForms" subpanel already does this, albeit there's no manual ability to choose what URLs this can be done to ...as far as I'm aware.
I use the request LogRequests history to save requests, so that I can replay them when needed. Every month or so when my machine is restarted for an update and if Fiddler is opened, the history is corrupted.
I need a way to either save off certain requests like I can in Postman, etc, or I need Fiddler to have reliable restore points for the history so that the entire history is not corrupted so often.
Please fix or add a feature to address this -
Thanks
HOSTS in fiddler shouldn't change SNI info when Decrypt HTTPS traffic is enabled
When Decrypt HTTPS traffic is enabled and use HOSTS in fiddler, SNI should be keep the same as request, instead of use the one from HOSTS(removed when use IP, or rewrite when use another HOSTS)
Please consider installing a desktop shortcut or start menu shortcut to launch Fiddler viewer (instead of fiddler to listen and capture traffic). This will help folk that want to review fiddler traces from others without launching Fiddler and interfering with locally running apps that misbehave due to Fiddler intercepting traffic by default on launch.
i realize I can create my own shortcut using "fiddler.exe -viewer". But I want to write troubleshooting guides to engineers that are new to both the technology they are learning and Fiddler/HTTP traffic analysis in general. Having two shortcuts created will make it easier to write instructions where we can advise folk to just launch shortcut to viewer to import a session or previously made fiddler saz file from someone else.
Thanks!