Clever Geek Handbook

Using custom url rewriter, IIS6 and urls with .htm, .html, etc.

I have a custom site that I am building with auto url rewriting using a custom engine. The rewriting works great as long as the url of the page does not end with some type like .htm or .html. For these pages, it goes directly to the iis 404 page instead of first clicking on my rewrite engine.

I have a wildcard handler in the Home Directory section of the IIS6 config of this website, but these urls seem to be ignored by it (for example things like css, jpg, js, etc. to send the url to the sender -addresses in my web project). How do I configure IIS6 to force these URLs to be sent to the handler while still serving the page if it exists normally?

The handler basically does this

if (!File.Exists(Request.Path))
{
    doMyRewriting();
}

I have to assume that using a block like this (simple and simple, the real one does some other things to format the Request.Path to be correct with everything), should run "doMyRewriting ()" if the file requested does not exist, otherwise it will serve page as usual. Am I wrong?

If I tell IIS to specifically send .htm and .html pages through a .NET handler, then the rewrite works, but if the page is actually there, it won't serve it.

Any help would be greatly appreciated.

Thanks in advance!

+1


source to share


3 answers


Don't know if you can or want to do this, but there is an Ionics Isapi url reactor you can use.

http://www.codeplex.com/IIRF



Basically set then set the rule to remove the .html so that it gets into your rewrite engine. I am using it in IIS 6 with several blogs of mine.

+3


source


I think that if you have IIS, send all requests to .NET and your handler, then your handler will have to detect if the page exists and serve it, not rewrite it.



UrlRewriting.NET has the ability to do this - you can look at their code to see how they handle this case.

+1


source


In my opinion, url rewriting from IIS 6 is best handled with an ISAPI filter, written as unmanaged native code. Otherwise, you will run into the problems you mentioned - to map all extensions to ASP.Net and lose the ability to easily handle files. With an ISAPI filter, you can choose not to rewrite some URLs and let IIS handle them as usual.

To get started, I suggest reading the ISAPI Filter Overview on MSDN.

If your filter absolutely needs the .NET Framework, you can write a small ISAPI filter wrapper that hosts the CLR and forwards requests to some managed code. Filter.Net Framework takes this approach and may be appropriate for your needs. The slight downside to this approach is that you will have to use the same .Net version as any ASP.Net applications that run in the main IIS process.

+1


source






More articles:


All Articles