Debugging Url Master Problems
With the growing number of installations of the Url Master module, the types of support requests I receive continue to surprise me - some people use the module in way I had not expected. That's great news, of course, as talented end-users come up with ways to make the software work for situations it wasn't necessarily designed for.
I'm happy about it, of course, because it validates the deliberate strategy of leaving a wide array of configuration options, which tends to mean no two installations are ever alike. However, the wide variety of requests highlighted the need for a way to remotely diagnose problems on installations. This isn't always possible, of course, because a lot of testing of the module takes place on 'localhost' installations.
This blog post is about how you (as the end-user) can debug and diagnose problems in your Url Master setup. The best place to look for answers remains the Url Master support forum, but think of this post as a guide to installating and troubleshooting.
Some DotNetNuke Url Theory
Before diving into the details, I'd like to cover some theory first. This is important to define terms so the rest is understandable. Here's the list of functions that the Url Master module actually does. This is to eliminate confusion as to what the functionality is.
- A Url Rewriting module : it takes virtual (as in they don't map to a physical file) Urls, and rewrites them so that the rest of the DNN code (including third party modules) sees the Url in the format that we would traditionally expect : /default.aspx?tabid=36&ctl=login
- A Url Redirecting module : it accepts Urls for locations and then forwards those requests to a new location. This is both done automatically for 'unfriendly' urls (forwarded to 'Friendly' urls) and for custom redirects (accepting a Url for a location no longer supported and forwarding the request to a new location)
- A Friendly Url Provider : Once installed, the module replaces the standard DNN Friendly Url Provider, and it generates Urls in the most humand and search friendly format possible. This includes putting a separator between words, allowing the end-user to specify whatever they like for page names, ensuring urls are all in lower case - anything to do with making presntable Urls.
- A DNN Rewriting HttpModule : this sounds like a duplicate of the first point, but it's important : the standard DNN Url Rewriter does more than just rewrite Urls, it also determines which request is for which portal, and sets important request context items, such as the 'PortalSettings' and 'OriginalUrl' values.
With those definitions out of the way, it's important to recognise in which area does your problem fall into
- Problems with 404 or 500 status codes, or from Third Party Modules not working correctly are probably Rewriting errors.
- Problems with 301 or 302 status codes, or from getting the wrong page for the Url requested, are probably Redirecting errors.
- Problems with Urls not looking like you would expect, such as including the 'Tabid' path when you didn't want it, are probably Friendly Url Provider errors.
- Problems such as 'PortalSettings is null' or other 'null reference' type errors in other parts of your DNN install may be to do with the failure of the DNN rewriting functions.
Note that I say 'probably' and 'maybe' because there are no hard and fast rules, and problems could be a combination of several of the above factors, working together.
Debugging Your Problems
Performing Http Tracing to Diagnose Problems Correctly
Install Microsoft Fiddler
The first thing I recommend is the downloading and installation of 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 (yes, Firefox users, it won't kill you)
- 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.
Figure 1 : Microsoft Fiddler Session Trace Detail
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. Incidentally, this is why you don't refer to 'hits' when talking about web page statistics - there are 26 hits here for one single page view. Each of these lines represent a resource that was downloaded from the server. There a couple of other rogue requests in there as well, such as the Google Toolbar request (see, I told you they were watching you) and the Internet Explorer 7.0 phishing filter request (urs.microsof.com:443 - see I told you they were watching you also!)
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. A result of '200' means everthing went OK. A result of '404' (such as the ifinity.com.au favicon - which I'll attempt to fix here) means the request did not go OK. A result of 301 or 302 means that the request was forwarded to another location.
If you've got obvious problems with your Url Master install (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).
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.
Figure 2 : Microsoft Fiddler Request Detail
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.
Getting Debug Information From Url Master
The latest versions of Url Master (from 1.0.9 upwards) have built-in debug code that is activated when you add in a request parameter. This allows you to gain more information about what is causing your problem.
To do this, 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
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 haven't got a recent enough version of Url Master (1.0.9 upwards), 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 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
Note, debug information broken over two lines for formatting
To understand this, here are the 4 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.
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
Note, debug information broken over two lines for formatting
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.
Troubleshooting Url Master Installations
I feel obliged to mention here that the majority of installations of Url Master work just fine, and the code works as designed. For the other 5% or so where there are complications, here's a good checklist for troubleshooting your problems.
- If you're getting a 404 error, is it from IIS, or ASP.NET, or from Url Master. Url Master 404 pages are different to the IIS 404 page and the ASP.NET 404 page. If you're getting an IIS or ASP.NET 404, chances are the problem lies in an IIS setting like application configuration. A common mistake is to modify the page extension mapping (to wildcard or another value) and then tick the 'verify file exists' check box. This will result in 404's because each of the Urls is virtual, in that it doesn't map to a physical file location.
- Check your DNN Event Log. Some exceptions will result in a 404 so as to not stop the site from working if they are in the main logic path. An example is an invalid Regex filter applied in the settings for the module - the latest versions of Url Master log an exception but don't stop processing. If you can't logon to your site to check the log, query the database directly - it's the dnn_EventLog table you need to look at.
- Understand the debug information if you're using it, and try and work out why you're getting the results you're getting. If you're getting a 404 for something like a .swf, .png, .ico file, and you have 'wildcard' mappings on for your site to run in extension-less mode(as ifinity.com.au does), then you may need to exclude that value using the advanced regex settings.
- Don't forget the test setup. In the 'Friendly Url Settings' page of your Url Master installation, there are test boxes for both Friendly Url Generation and Url Rewriting. You can test out the Urls you're trying, and these boxes will give information as to what happened during processing. This is particularly useful if you're trying to install the module on a live site, and can't leave the Url Master module 'switched on' because some aspect of the site is not working. The 'test' functions will work even when the module is switched off.
If you've come across a module that doesn't seem to work well, it's probably because that module doesn't use the Friendly Url API in the DNN Core to generate Friendly Urls. These modules often do some type of find/replace function on the 'default.aspx' string in the Url, and as such, are outside of the Core Url functionality. It's best to ask the developer of the module to use the core Friendly Url Api to generate the Urls, and you can point them to my blog post on the topic : An open letter to the DotNetNuke developers of the world: Please start using the FriendlyUrlProvider API for custom page names!
Need More?
Of course, if you're stuck and this information hasn't helped at all, you should post your problem to the Url Master Support Forum.
If you've got any other tips to add, please do so via the comments below. Personally, I'm off to locate my lost favicon.ico.