Get Your Head Out of the LAMP's ASS and See Some Light - ASP.NET URL Rewriting Works Great!
Last week Jonathan Hochman wrote an article about how URL Rewriting does not work properly on the ASP.NET/IIS platform. He could not be farther from the truth if it bit him on his big toe and drew blood. Jonathan admits that he was extremely green to the ASP.NET platform and was doing research on how to perform URL Rewriting, permanent redirects and custom error pages. Well anyone with more than a day or two working with ASP.NET most likely is aware of how to configure custom error pages, and I plan on covering that in another post.
Permanent redirects are when you tell the client the resource has been permanently moved and provide the new URL. In the process you pass a 301 status code in the response header. I will go into more detail about that in another article too. I have already covered 301 permanent redirects in ASP.NET to a certain extent more than a year ago.
What really got my goat was Jonathan's comment "Microsoft's URL rewriting technology does not inspire much confidence." and pointing out an erroneous entry from Matt Cutts that ASP.NET URL Rewriting throws a 302 status code (temporary redirect) instead of a 200 status code indicating a successful request.
Today I want to directly address Matt Cutts' article from July 5 2006. For those of you who are not in the know, Matt is the Scott Guthrie of search engine optimization world and works for Google. If you are anyone in the search engine optimization world you hang on his every word like stock traders used to hang on Allen Greenspan's every word in front of congress.
In Matt's article he points us to an entry on the Community Server's forums where a member states that his Community Server site is tossing up 302 status codes when a page is requested through URL Rewriting. I checked my Blog, since it is Community Server and could not replicate this issue at all. I then checked several sites I am using the RewritePath method to perform URL Rewriting and could not replicate this person's issue.
As it turns out it was a bug in Community Server, not ASP.NET. Well not really, the RewritePath method has several overloads and the version that Community Server 2.0 was using needed to be adjusted.
ReWritePath Method Overloads as Provided by Reflector
Public Sub RewritePath(ByVal path As String)
Public Sub RewritePath(ByVal path As String, ByVal rebaseClientPath As Boolean)
Public Sub RewritePath(ByVal filePath As String, ByVal pathInfo As String, ByVal queryString As String)
Public Sub RewritePath(ByVal filePath As String, ByVal pathInfo As String, ByVal queryString As String, ByVal setClientFilePath As Boolean)
Friend Sub RewritePath(ByVal filePath As VirtualPath, ByVal pathInfo As VirtualPath, ByVal queryString As String, ByVal setClientFilePath As Boolean)
While I think forums like on CommunityServer.org and Forums.ASP.NET are great ways for the developer community to grow, they can also be the source of hysteria. In this case it was a bog, just not really with the framework. I know from experience that Search Engine Optimization forums like Digital Point are used way too often to cause the competition to waste hours down the wrong paths. I try to stay on top of what Matt post on his blog, but to this day I have not seen him point out what the issue really was, so people like Jonathan just assume ASP.NET is inferior. Not that I am calling Matt dishonest, but it would be nice for a admitted Microsoft bigot to admit that Microsoft products are not that bad once in a while. Yes I called him a Microsoft bigot, you should have heard him on this podcast I caught the other day!
I have checked and rechecked this situation and just do not have the issue on any of my sites.
So here is what I plan on doing over the next month or so, do a series on URL Rewriting, Custom Error pages and response Status Codes from a technical and a Search Engine Optimization point of view. I use httpHanlders, Regular Expressions and anything else I need to get the job done. I hope when I am done there will be no confusion for anyone out there about the functionality of ASP.NET URL Rewriting.