One of the clients I have been working with has an interesting situation where they want to use URL rewriting - but in a different way than I've seen in the past.

They've written an application for their clients, which is then used by their clients' customers. They have 100's of clients, each who has potentially 1,000s of users. As we talked about what the requirements were for the URL rewriting, we came up with two main ones:

1. They should be able to have clients running different versions of the software on the same web server  They typically have three versions at any given time: Next, Current, and Past.
2. Each client should have a consistent, non-changing URL. (for example, http://www.mysite.com/Client1)

The obvious solution is to create a virtual directory for each client and put the correct version of the software in each directory. Deployment can be easily automated, and you should be good to go, right? Well, not quite. With 100s of clients on the same server, you end up running 100's of app domains at the same time. That tends to tax your server just a bit. And by tax, I mean grind to a halt!

So we came up with an idea that we thought would work. The basic idea was to create a virtual directory for each version in production. Then in the root folder, you'd have a distributor application. It would look at the incoming request, grab the client ID, look up the client ID in a database to determine which version they were currently using, and then rewrite the URL to the correct version. As long as your application was aware of the way it has to build URLs, this would work well.

Or at least it sounded good in theory. In practice, it didn't work. As it turns out, you can't rewrite URLs across app domains. Or more specifically, you can't write to another app domain unless you have the DLLs you are writing to referenced in your application. That's a problem because we'd have to have references to three different versions of the same application. There would be namespace conflicts that would be tough to overcome. Potentially strong naming could help the situation, but it's not an ideal solution, and something we didn't really look into that much.

Eventually, we settled on an ISAPI filter that sits in front of the whole process and basically does the same thing that our distributor application was supposed to do. We couldn't use recommended filter - ISAPI rewrite - because our rewrites aren't static, and updating them every time a client moved versions would be a major hassle. We ended up using a managed ISAPI filter (Filter.NET). Because it's sitting in front of the app domains, it can handle the rewriting. It's a bit tougher to manage because it's an ISAPI filter, but it does give the flexibility they need, and the rewrites are written in managed code.

Ideally, I think we'd like to look at what IIS 7 has to offer and find a simple solution to our distributor problem, but I can't say whether that's there or not. I haven't looked at IIS 7 enough yet, and their servers aren't running Windows 2008 anyway (obviously). In the mean time, we want to make sure we're doing it the best way. Frankly, other than writing a pure C++ ISAPI filter (which would be much harder to manage, I think), I'm not sure I see any other valid solutions. I'm sure I'm missing something, so if you know what it is, please leave a comment!

Tags: URL Rewriting | Filter.NET | ISAPI