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
_______________________________________________ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
