Approved
Last Updated: 11 Apr 2019 12:58 by ADMIN

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

Approved
Last Updated: 11 Apr 2019 12:45 by ADMIN

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:

  1. Stop logging these entirely, or maybe log them only when the handshake is between 255 and 512 bytes (https://cs.chromium.org/chromium/src/third_party/boringssl/src/ssl/ssl_test.cc?l=1082&rcl=9f0e7cb314ae64234b928fd379381ae9760a9a5f). I think today the warning in Fiddler is simply >255 bytes. But we should probably get rid of this logging entirely, as the buggy server appliances are probably out of the market at this point. Although maybe show a warning at >767 bytes as a) that's huge, and b) we found that there's a server called Gatling that fails on handshakes that big.
  2. Extend the existing interfaces related to Log handling to allow an extension to "eat" messages so that they don't end up in the log.
  3. Extend the Log tab to make use of that new interface to have an "Ignore regex match" box.

 

Approved
Last Updated: 11 Mar 2019 13:18 by ADMIN
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)
Approved
Last Updated: 27 Sep 2018 05:00 by Imported User
Created by: Shmuel
Comments: 2
Type: Feature Request
5
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.
Approved
Last Updated: 31 Aug 2016 05:00 by Tsviatko
Created by: Leslie
Comments: 2
Type: Feature Request
6
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/