TWU - Telerik Fiddler

TWU - Telerik Fiddler
Chad Heinle profile picture

By Chad Heinle, VP Consulting Services

Categories: Tools

Internet for Dummies book

Originally published in 1998, The Internet for Dummies was already in its 5th edition. In the 20 years that have followed, the expanse of the internet has woven its way into every corner of our lives. Work, school, recreational activities, baby monitors, and even refrigerators are all connected. All of this connectivity from the beginning has relied on two machines talking to one another. It's a pretty simple transaction to to think about - let's use the scenario of visiting a completely random website like 

The transaction goes something like this: you use a browser to visit on your laptop. Your laptop sends a message out into the ether (ok, not really but one thing at a time), and receives a call back. Though it's not really just one call back - actually receives 41 calls back, and that's a pretty small request! Being able to analyze this traffic is an important step to troubleshooting certain issues - you can see where you have broken resource links (perhaps a stylesheet isn't loading), see the incoming data from a web service to find the specific data you're after, or see what call(s) might be taking a long time to load, and then work with your application to adjust as needed.

High Monkey Traffic

This is where Telerik Fiddler comes into play, a free 'web debugging proxy'. Right away, the display looks like something straight out of a movie scene where someone is hacking into a secure government server, trying to steal all of their secrets. In reality, once you figure out the kind of information you want to see, it's pretty easy to look at. On the left is a summary of the calls; in our example, you'll see that there are different calls for the page, the styelsheets, teh scripts, the fonts, and more. By clicking on a specific call, you can see all of the information broken down on the right. You can also see the type of protocol used (such as HTTP/HTTPS) and the summary result, which is shown as a status code. 

A few quick status codes to be aware of: 
- 200 means that the call was successful with no issue
- 301 means that the call was permanently redirected to another address
- 302 means that the call was temporarily redirected to another address
- 401 means you don't have the proper authentication to see the requested resource
- 404 means that the resource was not found

This summary is mostly helpful if you can see that you're getting a 404 status code on a resource such as a stylesheet which could mean you do not have the correct link in place.

High Monkey Statistics

For my own use, I stick to the Statistics and the Inspectors screens. The statistics shows things like the byes sent, bytes received, number of requests, and amount of time that request took. If you have an image file that's taking four seconds to load, that's a potential issues you know you need to address and you can probably pretty easily see by using this tool if you have a very large image or (if it's not on your server) that it's taking a long time to get a response from the hosting server.

High Monkey Inspectors - headers

Clicking on the Inspectors tab, you'll see a lot more information about the data you're actually receiving. The main two areas I utilize the most are Headers and TextView. Headers show the HTTP header information that are a set of rules that govern how traffic is sent and interpreted by the browser. There are also security rules that prevent data from being accessed directly which can be the cause of some malicious activities. If you've ever heard of 'clickjacking' then you'll know that it's pretty easy to include an iFrame of a site within your own unless you have the proper security setup (Google search: X-Frame-Options). 

High Monkey inspectors - text view

Lastly, there's the actual data that comes across with a call. You can usually view this (if it's within a text format) in the TextView tab. This is helpful for seeing segments of HTML and CSS but also seeing the results of JSON calls, a very helpful tool for troubleshooting more complex API work you may be doing. 

Understanding how the web works is an integral part of web development, and being able to understand how calls are made and received is an important tool in a developer's arsenal. Impress your boss by throwing out status codes, wow your non-technical friends, and most importantly, be able to interpret how your code is talking to the internet in general so you can make informed decisions while troubleshooting.