Approved
Last Updated: 29 Jul 2019 08:56 by ADMIN
Created by: Imported User
Comments: 2
Type: Feature Request
3
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.
Approved
Last Updated: 16 Jul 2019 07:40 by ADMIN

Repro steps:

1. Inspect a websocket connections traffic

2. Expand the preview column so that the message body should show more than 65 characters.

3. Observe that even though the column is wide enough to support more than 65 characters, only 65 characters are displayed.

Approved
Last Updated: 10 Jul 2019 10:38 by ADMIN
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
Approved
Last Updated: 04 Jul 2019 11:41 by Daniel

Precondition:

  • Have a list of several AutoResponder rules.

Steps to reproduce:

  • Select a rule in the list.
  • Press the M hotkey to set a comment for the rule.
  • Edit the comment.
  • Save the comment by confirming with OK.

Expected result:

  • The comment edit dialogue displays the current comment of the rule selected in the list.
  • Confirming the dialogue updates the comment of the rule selected in the list with the text box content.
  • The list selection does not change.

Actual result:

  • The comment edit dialogue displays the current comment of the rule selected in the list (expected).
  • As the edit dialogue opens, the selection in the AutoResponder list changes and a different rule is highlighted.
  • Confirming the dialogue updates the comment of the newly selected rule, not the one the user manually selected and whose initial comment was shown in the edit dialogue.

Version: 5.0.20192.25091 (2019-06-04)
Platform: Windows 10 build 17134, .NET 4.7.1

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: 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/