I have long used FireFox as my default browser for surfing the web, but I typically test my ASP.NET pages on Internet Explorer for a couple of reasons:
- Some of the larger software projects I work on are developing intranet applications, where all users' browsers are fixed (IE 6 for one client, IE 7 for another).
- For book and article and tutorial screen shots I typically use IE as my browser of choice because IE is still, after all, the most used browser.
- Until Visual Studio 2008, Visual Studio used IE as the browser when debugging an ASP.NET application (even if FF was setup as the default). Because all of my clients arestill onASP.NET 1.x or 2.0, I don't use VS 2008 too often.
However, I have recently been working on some AJAX material and have been using VS 2008 more frequently. Visual Studio 2008 kindly launches my default browser (Firefox) when I debugmy webapplication. The problem was I noticed that Firefox was loading pages very slowly. I'd visit a site through localhost (via the ASP.NET Development Web Server) and pages would take several seconds to load.
To help analyze the problem I used the excellent Firefox extension Firebug(which I reviewed in the March 2008 issue of my Toolboxcolumn).Firebug will show you the total number of network resources downloaded when visiting a page, along with the time it took to download each.
Each resource - from the 4KB HTML fiel to the 7KB JPG file, was taking close to a FULL second to retrieve! When requesting this same page from a remote, production web server, download times were 5 to 10 times faster per resource. What was going on here?
I next opened Internet Explorer - the same pagesloaded instantaneously. I fired upFiddler, an excellent HTTP Debugger for IE, and noted that the resources were being downloaded in 0.02 seconds, nearly 500 times faster than from Firefox. By now I was seriously stumped. I then did what I should have done from the getgo - I searched the web. Duh!
Turns out that there is a known issue with Firefox's IPv6 support and the ASP.NET Web Development Server that introduces these lengthy delays. To quote from the Mozilla Wiki:
IPv6 was designed in part to solve the problem IPv4 will soon be facing: the exhaustion of all possible IP addresses. Mozilla implemented IPv6 support in early 2000, but that support did not receive widespread testing until recently as IPv6-capable OSs and network software/equipment became more common. One particular bug that has appeared exists not in Mozilla, but in IPv6-capable DNS servers: an IPv4 address may be returned when an IPv6 address is requested. It is possible for Mozilla to recover from this misinformation, but a significant delay is introduced.
Two approaches were taken to work around these bugs: first, a preference to globally disable IPv6-based DNS lookups browser-wide (this preference [network.dns.disableIPv6]), and a blacklist of domains which should never have IPv6-based DNS lookups performed (network.dns.ipv4OnlyDomains).
Consequently, to fix this problem of slow response times when visiting localhost using Firefox, either set the network.dns.diableIPv6 configuration property to true or set the network.dns.ipv4OnlyDomains configuration property to localhost. My search led me to many pages around the Web suggested that you set the nework.dns.disableIPv6 property to true, but this would disable IPv6 support for all sites visited by the browser (at least according to the Wiki documentation). Therefore I set the network.dns.ipv4OnlyDomains property to localhost.
To set these properties, fire up Firefox and type about:config in the address bar. Next, locate the appropriate setting and change its value to the desired one. With that small change the debug-time experience in Firefox is greatly enhanced. And make no mistake, Firefox's rich library of extensions make it a great browser for web development. (I'll share some of my favorite Firefox web development extensions in a future blog post.)
Lesson for the day: If you bump up to a problem, search for a solution online first. If your search is fruitless then take the time to investigate it further, otherwise you may spend 15 minutes troubleshooting a problem that is already well-known and has a simple solution.