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). 

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.

I have a base64 of a gzip of utf8 bytes of a string - base64(gzip(utg8(string)))

Please add to the TextWizard options in the transform to encode/decode a string to gzip

 

When there's a HAR file with h3 entries, they are either misinterpreted or ignored.

I know how to fix it both in the importer/exporter DLL and in Fiddler.exe.

I can submit a correction.

Hello! The problem is described on this link: stackoverflow

 

 Please add in Filter -  feature block named "Request Body" with options "Show only if request body contains", "Hide only if request body contains"

So far Fiddler says it can only import unencrypted sessions from PCAP files.

Various tools and libraries support the SSLKeylogfile environment variable and log the necessary keys.

You can either have them inside the pcapng file or in a seperate file.

It would be nice if Fiddler would accept an optional file with these keys and treated sessions with a suitable key as unencrypted.

This would make things a lot easier in the process.

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) 

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

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

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!

I am using Fiddler for 6 months and I found it really nice and simple to understand and get the required information, but one feature in which fiddler is lacking is the NIC information although with fiddler we get the Source and destination IP, port, MIME type, TLS/SSL versions etc but if we get this NIC information it will be complete solution for Web debugging.

Regards,

 

Faris

When I go to File | Save | All Sessions it defaults to a directory (that is not where I want to store the debug information I collected).  

I store all problems I am working on in a different directory structure.  When I go to SAVE my debug session I would like to set the Default directory (structure) where I save all my other documentation for problems I am working on.  Having to "re-find" my documentation folder multiple times in 20 minutes of saving multiple debug sessions is tedious and non-productive.

I suggest a user preference that has these options:

Set default directory to: ..........   (It will always open to here when a SAVE is done)

Follow Last SAVE directory:  (Check box)     This will open whatever directory location you last did a SAVE to

User Fiddler's Default Location:  (Check box)     This is like a "Reset" to Fiddler's default location.

 

 

Most extensions and inspectors need to access the decompressed/unchunked body bytes to perform their function, requiring them to have an understanding of how to get those decoded bytes. To simplify this, add UnencodedRequestBody and UnencodedResponseBody properties to Session that return a byte[], for example:

            

         public byte[] UnencodedResponse() {
            if (!_HasResponseBody() || !Utilities.HasHeaders(oResponse)) return Utilities.emptyByteArray;

            if (oResponse.headers.ExistsAny(new[] { "Content-Encoding", "Transfer-Encoding" }))
            {
                arrResponse = Utilities.Dupe(mySession.responseBodyBytes);
                Utilities.utilDecodeHTTPBody(mySession.ResponseHeaders, ref arrResponse);
            }
            else
            {
                arrResponse = mySession.responseBodyBytes;
            }
         }

 

GetRequestBodyAsString and GetResponseBodyAsString can then be refactored to call these byte[] properties.

Today, if a browser makes a HTTPS request to a site with a certificate error, and the user picks "No" when Fiddler asks whether to accept the Certificate Error, it is very difficult to figure out where the HTTPS request made in error came from.

It would be cool if instead of simply closing the TUNNEL connection, Fiddler instead had an option by which the server connection was rejected but the client connection to the Tunnel got a 200 OK but was connected to a special "DEAD" pipe that returned HTTP/503.

That way, the client could make its HTTP requests to the dead pipe (whose URL and Referer header might reveal from where the request came) allowing the user to debug, but overall security would be maintained (no network connection made insecurely).

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)

Since most browser's and mobile apps are starting to use HTTP3 it would be nice if Fiddler could also support this.

Currently, the ImageView Inspector is only available for responses.

Why not enable it for requests?

Currently Statistics show the time of request:

ACTUAL PERFORMANCE
--------------
ClientConnected: 15:33:43.395
ClientBeginRequest: 15:33:43.725
GotRequestHeaders: 15:33:43.725
ClientDoneRequest: 15:33:43.725

 

It would be useful to know the date of the request as well for projects that span several days.

 

Thank you.