Individual INI files for each Web Site

Topics: Developer Forum, User Forum
Mar 2, 2007 at 8:55 PM
Cheeso (et al),

I know this issue has been discussed already (here and here), but I'd like to re-address it.

Having seperate INI files for each new web site is a critical need for larger hosting environments. You don't have to get through many sites before your rules will start to conflict with each other, and your INI file gets very large.

I've seen two solutions mentioned here on the forums:
  1. Add conditional statements to every rule and target them at a specific web site. This might work for 2 or 3 sites, but when you start getting into 10 or 20, the INI file gets very verbose, and now every site suffers as speed decreases.
  2. Have a seprate folder for each site with it's own DLL and INI file. This has the advantage of keeping the rules in each INI file distinct, but it introduces two new problems: 1) You need 20 (30? 50? 100?) copies of the DLL installed on your web server, and 2) It probably means that 20 (30, etc.) copies of the DLL are loaded into memory at the same time.

I'd like to propose that a more elegant solution be developed for this issue. Here are three possible ways to address the issue:

The Dream Solution - 1 DLL with many ini files
This is how Linux handles rewrites (as I understand it). Each web site folder has it's own INI file with it's own rules. This is the ideal solution. The next-best would be having all the INI files in the same folder as the DLL, but with a different name for each -- maybe based on the name associated with the site in IIS.

The Compromise - 1 DLL, multiple instances, multiple ini files
This is the fallback from the Dream Solution. We still have one physical DLL on the web server, but a unique instance is loaded for each web site. The ini files are still seperated -- one for each site.

While this isn't the ideal answer because you still could have 50 instances of the DLL in memory, I believe it's how IIS itself works.

The Other Compromise - Conditional Rule Blocks
Right now conditions are limited in that they only affect the next rule in the file. That means that if you've got 10 rules for a particular web site, you also have 10 condition statements. You've just doubled the number of rules.

A better approach would be to have the conditions affect a block of rules. For example:

RewriteCondStart %{HTTP_HOST} (mysite)
  RewriteRule ^/[c|r]\d+/([\w\-\%]+)\.(gif|jpg|png|css|js|ico)$ /$1.$2 [I,L]
  RewriteRule ^/r(\d+)/(.+)$ /Results.aspx?lt=$1&h=$2 [I,L]
  RewriteRule ^/c[A-Z0-9\-]+p[A-Z0-9\-]+/([\w\-\%]+)\.(gif|jpg|png|css|js|ico)$ /$1.$2 [I,L]
RewriteCondEnd
Yes, this does break with the Linux standard from rewrites, but if neither of the options above are viable, this would work.

Having not dug through the source code myself, I'm not sure how difficult each of these would be to implement. Perhaps there are a few intrepid developers here that might be willing to collaborate with Cheeso to come up with a solution.

Thoughts?

- Bryan

Coordinator
Mar 5, 2007 at 7:00 PM
This discussion has been copied to Work Item 8669. You may wish to continue further discussion there.
Mar 6, 2007 at 2:10 PM
Thanks, Cheeso.