Need more time in the day? Take command and reinvent solutions to the most common web debugging issues using a HTTP(s) web debugging proxy tool. 

Few things seem unchallenging in today's environment; around every corner, you are faced with decisions, obstacles and sometimes, when you see a clear path, you forge ahead with excitement. The same can be said when you are facing common debugging website issues. In this blog, we want to offer you a clear path to easily identify website issues and offer you solid guidance on debugging these issues using a web debugging proxy. At the end of the path, you will have a reassuring understanding of how to find an issue, locate it, inspect it, all of which can simplify your life, giving you quality time back.  

Understandably, a website is made up of multiple requests. Requests which feed the HTML, the JavaScript, and the million other components that your website has. Yet sometimes it can be a huge pain to understand all website requests. 

Using a web debugging proxy tool, in our scenario Fiddler Everywhere Pro, you can filter out the requests based on the criteria you specify. To illustrate, I'm going to use the hash node website to inspect some of the errors present on the page, and then using Fiddler Everywhere Pro, I am going to see how we can debug them. 

At first glance at this website, it does not look like anything could be wrong because everything seems to be loading correctly. By inspecting the hash node website in Fiddler Everywhere Pro, you can capture every network request from their website and the other hundreds of requests coming in from the different websites and applications that are open.  

The Fiddler Everywhere Pro UI shows the type of files every request brings.  

The magic here is that the web debugging proxy shows you the type of file that every request brings, and in this instance, there is a particular file coming from hash node as indicated by the host. By utilizing the parent/child requests selection feature, you can see all the requests, including those from the hash node host and some similar scripts, and save the selected sessions. 

Now you have saved all the recorded sessions from hash node, and you can quickly identify how many HTML files are included, how many CSS files and all the JavaScript files present within the session. Having these saved sessions makes it simple and convenient for you to understand the various requests going out and coming in every time the website is loaded. This becomes important if you want to track malicious requests that you think may be present when the website is being loaded. 

Now that you can catalog all the network requests without having to set filter options let's see how you can best identify website errors. Website errors could be caused due to multiple things. It could be a 4XX error caused due to a client site problem, or it could be a 5XX error caused by communication problems with the server. You can identify these problems at a compelling speed by using the web debugging proxy I introduced to you above, Fiddler Everywhere Pro.

Remember, when we first loaded hash node, it seemed like everything was working fine. Yet, by utilizing the Fiddler Everywhere Pro UI, you immediately see all the hash node traffic that has been captured, and the 404 error is evident right away. 

You can see in the traffic inspectors that the particular response was not found, as indicated by the 404.

The request is indicated in red, showing that it is an error. And if you click on that particular request in the traffic inspectors, you can see that that particular response was not found, which means it is a 404 error. So even though the website seemed to be working fine, you went behind the scenes quickly to identify this error, which was not clearly visible in the UI of hash node.

Now let's see how we can solve the problem causing the errors. Again, when I come to my inspector in the request headers, I can see the GET request hitting a new URL, which seems wrongly typed. If I'm not mistaken, the intention was to fetch this particular URL, a Google APIs for fonts. To correct, you can apply a rule which will redirect to a different URL every time this particular request is made. Fiddler's AutoResponder, which is what you can use here, gives you the freedom to create mock rules and provide responses without contacting the server. By creating a rule for this URL and reloading the session, you can see the exact CCSS file is resolved, and it is now behaving as intended. 

If you had to make the same change on the server, this problem would be permanently solved, yet you can use Fiddler's Autoresponder to mock the response and make sure that it is first solved locally. Just think, what manually would be labor-intensive, you can now intuitively do to identify various website-related errors, many of which may not be directly visible without using a web debugging proxy.  

Now, coming to the third one, and this one is sometimes a little tricky for you or your developers because you constantly hear the phrase, "It didn't work on my system." Thus, it is exactly one of the major problems that we face while testing websites. 

How do you simulate an error or a problem that a user is facing in their environment when it's not happening in yours? A beautiful feature within Fiddler Everywhere Pro answers this question by giving you the ability to mock issues. By mocking issues and errors, you can simulate your user's environment. This happens using the AutoResponder feature you learned about in the last section. For example, you can see what would happen if your CSS took a little longer than usual to load and then use Fiddler Everywhere Pro to simulate what would happen in each scenario.

To accomplish this, you start by adding a new rule for it using the AutoResponder. Example: "Every time the CSS file is being loaded, I want to set a delay of ten thousand milliseconds, which is approximately ten seconds." Then you are going to save this, reload the session and see what happens. 

Simulate scenarios by adding a rule, I.e., a delay in this instance, using the Fiddler AutoResponder.  

When you reload, you can see that the website is still waiting. And then, after 10 seconds, it loads. Now you see the changes that took place once the CSS file loaded. For example, all the icons and text blocks were resized and fell in place as expected. By utilizing this method, you can be ahead of the curve and better manage it as you now know what to expect. 

This is the tip of the iceberg, and you may want to continue debugging other common website issues. There are more hints and examples available to you. Sign up for the Fiddler digest. You can expect to have productivity workarounds and other insightful guidance on debugging safely and reliably while navigating away from costly errors curated for you by a team of debugging experts.

Subscribe to Fiddler Monthly Digest