Using Fiddler to trace X3 web traffic

3 minute read time.

Have you ever noticed behavior in X3 that you couldn’t quite explain, and wanted a tool that could help you investigate what’s going on?  There are several third-party tools that you can use for various types of network or web app troubleshooting.  Today we are going to examine one that I like to use from time to time, Fiddler.

What exactly is Fiddler?  The Fiddler tool helps you debug web applications by capturing network traffic between the Internet and test computers. The tool enables you to inspect incoming and outgoing data to monitor and modify requests and responses before the browser receives them (thanks for the explanation Microsoft).  To put it in laymen’s terms, Fiddler lets you take a glimpse under the hood to see what your browser is sending and receiving from the internet.  Fiddler is free, and can be downloaded here.

Anytime you are going to use a tool like this, I recommend closing out of anything else that you can to minimize the traffic.  Sometimes you might be surprised just how much your machine is communicating back and forth with various servers, even when you’re not actively using an application.

After installing Fiddler, I always recommend enabling the option to decrypt HTTPS traffic.  If you are trying to analyze X3 traffic from a client machine without this option, you’re very likely not going to get much value from the exercise.  Here is the traffic that Fiddler captured from logging into X3 with the decryption option turned off:

 

Doesn’t tell us much, does it?  To enable HTTPS decryption in Fiddler, go to Tools > Options > HTTPS tab > check Decrypt HTTPS traffic > click OK.  Once you’ve done this, close and re-open Fiddler for the change to take effect.

 

You will see a warning about installing a root CA certificate—before accepting this, you may want to discuss with your IT or Network Administrator:

 

For additional information about Fiddler, you can consult https://docs.telerik.com/fiddler/configure-fiddler/tasks/configurefiddler.

Now we can re-open our browser and log into X3 again to see what Fiddler is capturing:

 

Much better, now we’re getting some potentially useful information.  Let’s look at a practical application of this from a recent case.

There were odd reports of X3 version 12, patch 21 exhibiting slowness right after logging in, but only periodically.  After some initial troubleshooting, it was discovered that the slowness only occurred after the browser cache had been cleared.  Once X3 wrote some cache entries, logging in was fine.  To illustrate what this looked like, after clear the browser cache, then opening X3 and entering a username/password and clicking sign in, a user would see the screen below for about 15-20 seconds before X3 would load anything.

 

If the cache wasn’t cleared again, any future log ins would take 1-3 seconds from clicking sign in to seeing the landing page.  Let’s look at what Fiddler was seeing when the reported delays were occurring.

 

One thing we noticed was the Body count for the highlighted line—this column shows the number of bytes being received by the client browser.  At 4,729,435 bytes, this equates to 4.7 MB, which seemed suspiciously large.  Without clearing the cache, we captured this traffic from the next login attempt:

 

Notice the absence of the large app.js file from the previous trace.  After some more research, we found that R&D had analyzed a situation just like this and determined that compression that should have been applied to the app.js file wasn’t enabled.  Once this was changed, log in performance after clearing the cache improved significantly.

This is just one example of the many ways you can use a network traffic analyzer like Fiddler to assist in tracking down an issue.  Be careful with tools like this though, you don’t want to get in trouble with a network admin for scanning traffic on a network when you shouldn’t be.  Until next time!