Re: Redirects Policy

On Sep 9, 2004, at 3:10 PM, fantasai wrote:

> There's been some discussion in
>   http://bugzilla.mozilla.org/show_bug.cgi?id=258433
> about how we want to do redirects on mozilla.org
>
> There are two main issues:
>   - putting redirects in .htaccess is more maintainable
>     (because we can change them through cvs rather than
>     server config)
>
>   - enabling .htaccess files has a performance hit, as Anne
>     notes in
>       http://bugzilla.mozilla.org/show_bug.cgi?id=258433#c11

I guess the main question really is what's more important?  
Maintainability or performance?  I know that .htaccess files incur a 
performance hit, but I feel that the level of maintainability it 
affords makes it worth the hit.

Is there any information on how many hits/day, page-loads/day or how 
the web server farm is arranged so we can use it as a metric for 
determining the direction we take?  If we are talking about a single 
server, or a group of homogenous servers behind an F5 load balancer, 
the direction we take needs to take that into account.

I tend to follow the "People are more valuable than computers" 
philosophy.  Therefore, anything that will save human-effort while not 
incurring to high of a performance penalty is worth doing.  (thus my 
work with XSLT)

Since most (all?) of the contributors to mozilla.org are volunteers, 
saving their time, or rather maximizing the time they do spend, could 
mean more organization and better documentation.

> It seems that we can limit .htaccess files to only certain
> directories by using <Directory> directives, so I suggest doing
> that as a compromise. We'd have to consolidate the .htaccess
> files a bit, but I'm guessing this will improve performance
> while keeping the redirect lists easily maintainable.
> Something like
>
>   Don't allow in root (use conf files for root redirects)
>   Allow in subdirectories of root
>   Don't allow in subdirectories of subdirectories of root
>   Don't allow in /products
>   Allow in /products/*
>   Allow in random other necessary places (like 
> /projects/ui/accessibility).

While this definitely is possible, in practice I would think this is a 
problem waiting to happen.  I can easily foresee website deployments 
that no longer work because, though a .htaccess file is in the 
appropriate directory, someone forgot to update the Apache 
configuration file.

Additionally, changes to .htaccess files don't require any special 
action to be taken to get the system to read the new configuration 
(thus the requirement to read the file on every page load) whereas the 
suggested changes above would require a full Apache restart to reload 
those Directory rules.  While not exactly a drastic action, it is much 
more disruptive to a heavily-loaded site.

--
Michael A Nachbaur <[email protected]>
http://nachbaur.com/pgpkey.asc