Products » Knowledge Base » Url Master 

Url Master Help Wiki

Using Fiddler to Trace Http Requests


The first thing you must do is download and install the Microsoft Fiddler tool. This is a Http traffic sniffing application that will show you the request/response for the Http traffic going to/from your website. You can download the Fiddler tool from here : Fiddler Download Page

Once you've got Fiddler installed, you'll be presented with a UI that doesn't make it obvious where to start. Here's what you want to do :

  • Start Fiddler, and check that the 'File'->'Capture Traffic' option is ticked.
  • Open up your site to debug in Internet Explorer (you can get a Fiddler extension for Firefox, but it's easier just to use IE)
  • Watch as the Http traffic between IE and your website is listed in Fiddler. If you don't get a Fiddler-screen full of http traces, then refer to the Fiddler help until you can get it sniffing your Http traffic.

Microsoft Fiddler Screenshot

Figure 1 : Microsoft Fiddler Request Traces

As you can see in the above image (which is a Fiddler trace of ifinity.com.au), there is one line for each request (or 'hit') made to the ifinity.com.au server.

Understanding a Fiddler Trace

Each of these lines are the key to understanding problems with your site. The first thing to inspect is the 'Result' column - this is the Http status returned by the web server for each request. A result of '200' means everthing went OK. A result of '404' means the request was not found on the server. A result of 301 or 302 means that the request was forwarded to another location.

If you've got obvious problems with your website after installing Url Master, such as a page request returning a 404, then this is the first place to look. Non-obvious problems might be that the formatting of your page is all wrong, which is likely a stylesheet with a 404, or some type of key functionality does not work because of javascript errors (a 404 on a .js or .axd file).  You might also have a series of 301/302 redirects causing a problem such as an unwanted logoff of a registered user, or a redirect from a page you'd expect to work, to one that doesn't.

Forming your own Requests

You don't need to 'sniff' traffic to use Fiddler - you can also use it to craft your own Http requests and submit them. The easiest way to do this is to click on an existing trace, and drag it over to the 'Request Builder' tab. When the tab goes bright green, then drop the item, and the Request will be automatically created for you.  This copies all of the relevant request details from the selected request - including the cookies, user-agent information etc.  This will mean that, to the web server, a request from Fiddler will look exactly the same as one from your browser.

Fiddler Detail

Figure 2 : Microsoft Fiddler Request Detail

Getting Debug Information From Url Master

Url Master has a built-in debugger that is activated when you add in a request parameter. This allows you to gain more information about what is causing your problem.

There are two methods to gain extra 'debug' information from the Url Master module

Method Number 1 : Add in Request Header

This method adds a request header which the module reads. By default, the module has this functionality disabled for compatibility reasons. First, enable this functionality by going into the Host->Friendly Url Settings page, and find the 'Allow Debug Code' option. Make sure this option is checked, and Apply Changes.

Then, add the following request parameters into your Fiddler request. You do this by clicking in the 'Request Headers' section of the 'Request Builder' tab, and typing in the information as follows :

_umdebug:true

This request parameter should be on a new line in the Request Headers section, so the entire request headers looks a bit like this :

        Accept: */*



UA-CPU: x86



Accept-Encoding: gzip, deflate



User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1;)



Host: www.ifinity.com.au



Proxy-Connection: Keep-Alive



_umdebug: true

Method Number 2 : Add on a Querystring variable

The request header method is better because it doesn't alter the structure of the Url, but requires the option to be switched on, and requires modification of the request header. The alternate method is to add a querystring variable to the end of the Url, like this : ?_umdebug=true. (if the querystring value contains other parameters already, use &_umdebug=true). You can modify the Url (and querystring) in Fiddler just by editing the request Url field.

Submit your Request

Once you've either added the request header or querystring variable, submit the request using the 'Execute' button, and then inspect the headers by clicking on the trace, and selecting 'Headers' in the Session Inspector response area.

You will see on the bottom of the list of headers, a value called 'X-UrlMaster-Debug:'. This contains debug information as formatted by the Url Master application. If you don't get this response header, and you included '_umdebug:true' - either of two things has happened. 1) You didn't put the _umdebug section in the correct place, or 2) the error is occuring before the code in the Url Master module is run. The second of these scenarios points to an ASP.NET or IIS problem.

If the problem is (2) it means that your request was not served by the Url Master module.  This could be either of two reasons:

a) The request is not mapped to the ASP.NET runtime by IIS.  This might be the case if you're working with Url extensions that are not mapped to ASP.NET by default - extensions that are like this include .html, .jpg, .asp and others.

b) The request has been 'ignored' by Url Master because of a match in the 'ignoreRegex' value in the Regex settings of the module.

If you do have a Url Master debug response header, it will look something like this:

X-UrlMaster-Debug: http://www.ifinity.com.au/favicon.ico, , www.ifinity.com.au/favicon.ico, Output404, 1.15.1

To understand this, here are the 5 sections to the debug header. Each section is separated by a comma, and each can have a value, or no value at all, depending on the response status. Here are the values, in order:

  • Original request : the Url, as requested to the server and seen by the Url Master module. Note that in some cases IIS can modify this request value, and it won't be exactly as typed in.
  • Redirect Url : if a redirect was requested, the value of the Url that the request is redirect to is shown here. Incidentally, the response status should also show this Url if it is a 301 or 302.    
  • Rewrite Path : If a rewrite was processed, the value of the rewritten path will be shown here.
  • Action : This is an internal encoded value, and indicates what the Url Master module decided to do with the request. It may say 'Continue' which means 'OK', or it may say 'Redirect301' which means it decided to 301 redirect the request.
  • Url Master version : the internal version number of the module

As you can see with the favicon example, it decided to output a 404 error as the request could not be understood.

As another example, see this debug request as submitted to the /home.aspx value:

X-Redirect-Reason: Site Root Home Requested

X-UrlMaster-Debug: http://www.ifinity.com.au/home.aspx, http://www.iFinity.com.au/, Default.aspx?tabId=53, Redirect301, 1.15.1

You can see the original request (with home.aspx), the resulting redirect (the site root), the rewritten path (?tabid=53, the home page) and the action value. In addition, because it was a redirect request, the reason for the redirect is also output. In this case it was becase the home page was requested, and an in-built rule for Url Master is that requests for the home page are forwarded to the site root value.

There are 16 different redirect reasons why a redirect might be issued (this number may change with time and further releases).  If you're getting a redirect, looking at this value might give you the information you need to understand why a redirect occured.  The most common is 'Unfriendly Url requested' - this is returned when the Url Master module has determined that the Url requested for a particular DNN page is not the 'most friendly' possible for that page, and as such is redirecting to the more friendly version.  Sometimes this is warranted (when a /tabid/xx/default.aspx request is made), and sometimes it is incorrect (when the request is not for a DNN page at all).  The problem must be correctly diagnosed before the right solution can be found.

Probably the most important value to understand is the 'Url Rewrite Path' (the third item in the list).  This tells you what the Url Master module determined was the correct course of action for the Url.  This Url is what the rest of the DNN framework 'sees' when it looks at the Request Url and Querystring.  If you have a module expecting a particular set of values in the Rewritten path, and it's not seeing those values - that's where the problem lies.

 In the above example, I have dragged-and-dropped the trace for the 'favicon.ico' request into the Request Builder. I can now click on 'Execute', and Fiddler will repeat that request to the server for me. Because I haven't changed anything, the result comes back exactly the same.

The thing that I am most interested in is the Response headers. These contain information about the response we got back from the server. You access the Response Headers by clicking on the trace session for the request you would like to inspect (on the left hand pane) and then clicking on the 'Headers' button in the lower area of the 'Session Inspector' tab.

HTTP/1.1 404 Not Found



Date: Thu, 17 Jul 2008 23:59:26 GMT



Server: Microsoft-IIS/6.0



X-AspNet-Version: 2.0.50727



Cache-Control: private



Content-Type: text/html; charset=utf-8



Content-Length: 6748

The above list shows the response headers for the 'favicon.ico' request.




 |  View Topic History  |