|
|
|
|
|
|
|
|
Nearly every page at the site I manage is prepared for delivery by a FastCGI script. I rely on one omnibus script that performs some wildly disparate functions. To decide which module will be doing the work for any given request, the script needs to be passed quite a few variables.
If this sort of structure appeals to you, you might consider using the Rewrite module that's new to Apache 1.2. At least three reasons led me to do so:
Aesthetics: Instead of forcing visitors to stare at URLs like http://www.yoursite.com/fastcgi-bin/script.pl?arg1+arg2+argn/, they can use one like http://www.yoursite.com/arg1/arg2/argn. mod_rewrite will treat the request as a regular expression; you'll be able to match parts of the URL and use $1, $2, etc. to form the ``real'', and really ugly, request behind the scenes.
Security: Obfuscation isn't the end-all of security, but it's not a bad place to start. If you successfully hide your script behind a wall of rewrite rules, visitors won't know they're accessing a script. Nor will they know its name or how its requests are structured, so they're less likely to launch direct attacks at it, looking for holes.
Flexibility: Suppose you start with one script handling all sorts of chores. As time goes by, you decide to split those chores up between scripts (or even servers). If visitors addressed your first script directly, you risk invalidating your published links when you bring the second script on-line. On the other hand, if they've been using URLs you've been parsing with mod_rewrite, you can add all the extra functionality behind the scenes, never altering your published addresses.