.htaccess directive listing order

What's most efficient?

[keyplyr]

I would be very interested in hearing from other webmasters what they feel is the most efficient listing order for directives in the .htaccess file. This is how I currently have mine:

<Files ~ "\.htaccess$"> 
order deny,allow 
deny from all
</Files>

AddHandler application Stuff

ExpiresActive Stuff

Turn a few Mods On

ErrorDocument Custom Directives

RedirectMatch 301 List

Redirect 301 List

RewriteEngine on
RewriteRules to control image access
RewriteConds

RewriteRule to ban bad bots/UAs
RewriteConds

RewriteRule to stop exploits
RewriteConds

Short term SetEnvIf bans for rude visitors

Thanks

[jdMorgan]

An interesting question, but one without a one-size-fits-all answer...

A few of my thoughts on the subject, quite possibly in need of caffeine enhancement:

The most efficient way to order things is such that the most frequent requests take the shortest path through the code. So, for example, you might want to test for image files, and quit the current mod_rewrite code if an image is requested. Put all your images in a subdirectory, and use .htaccess in that subdirectory to check for hotlinking. In this way, you don't take a bunch of time processing html page requests for hotlinking exploits, and the hotlink checks are only run against fle types that are commonly hotlinked.

That's just one example, and assumes that you use .htaccess, rather that the more efficient httpd.conf.

The main problem is that in many cases, .htaccess is used as a 'deny' list, and all requests must pass all tests before being allowed. 'Bad' requests are rejected and a 403-Forbidden is served immediately. The result of this is that only requests which pass *all* tests are honored as 'good', so 'good' requests are processed slowly and 'bad' requests are processed fast.

Other than that, you can keep the code *size* smaller by testing for general cases first, and specific cases later. This tends to reduce the number of required specific-case tests, since most are caught early. As a trivial example, if you ban an IP address range, there is no need to later check specific IP addresses within that range.

Jim