jdMorgan - 7:22 am on Jun 25, 2010 (gmt 0)

> should rewrite this as
ErrorDocument 404 /error404.php

> So what should this redirect to /forum (first rule) be?
# Externally redirect requests for forums subdomain to /forum subdirectory
RewriteCond %{HTTP_HOST} ^forums\.example\.us
RewriteRule ^(forum/)?(.*)$ http://www.example.com/forum/$1 [R=301,L]

> And what should the final rule look like?
This varies based on what types of resources can be generated by your scripts. I don't know about your scripts, but a typical site might use:

# Skip the following rules if any of these filetypes are requested or if
# the requested URL resolve to a physically-existing file or directory
RewriteCond %{REQUEST_URI} \.(gif|jpe?g|png|ico|css|js|pdf|swf|flv|avi|wmv)$ [OR]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
#
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

It is reasonably certain that your scripts do not generate image files -- They may generate HTML pages which 'include' images, but likely do not generate the image files themselves. Therefore, skipping the file- and directory- exists checks along with the final three rules is generally safe. The other filetypes are also not likely to be generated by typical PHP scripts.

The idea here is to avoid doing the file- and directory-exists checking when it is not necessary; If the current state of the filesystem is not cached in memory, or if that cache is marked as 'dirty,' the those two -f and -d RewriteConds represent physical disk reads. Now humans consider those to be fast, but compared to HTTP request transmission and normal server response handling, disk reads are fairly slow. Plus, every unnecessary disk access you allow is one less necessary one you'll be able to do before that hard drive (eventually) fails...

The bottom line is that by excluding the most-frequently-requested filetypes which cannot be generated by the scripts, you avoid beating your hardware to death and also speed up your site. On many sites, this one small change makes a visible improvement in site responsiveness under load. On lightly-loaded sites, you may see no change except that the disk activity light seems slightly 'dimmer' because there are fewer disk accesses occurring.

> And I should delete the <Limit PUT DELETE> command?
No. Replace the <Limit PUT DELETE> and its closing </Limit> with
<LimitExcept GET POST> and a closing </LimiteExcept>,
leaving the enclosed content of the original <Limit PUT DELETE> container as it was.

This takes care of *all* other HTTP methods *except* for GET, HEAD, and POST (note that HEAD is considered as a variant of GET, and is therefore 'automatically included' with GET). For example, your original code had nothing to say about CONNECT, PROPFIND, and a bunch of other HTTP methods. The suggested approach says, "Do this (allow them) with GET, HEAD or POST and if it isn't one of those, then do this other thing (deny them)."

Jim