Which kinds of information do you have in your .htaccess files?

And why? And in which order?

[troels nybo nielsen]

I am new to .htaccess and am slowly learning the possibilities of this wonderfull -- but also dangerous -- instrument. And right now I am in the process of editing some .htaccess files and creating some new that are necessary because I am moving hundreds of files to new directories.

So I would like to know what kinds of information other members put into their .htaccess files. And if there are several informations in one specific file, which order do you then put them in?

Do you have .htaccess files on several different levels for specific purposes or do you put all the informations in one file?

How do you edit them? One of my hosting companies have this wonderful file management with the option of showing hidden files so I can see and edit my .htaccess files in real time.

Have you learned any lessons about .htaccess the hard way by making disastrous mistakes?

[jdMorgan]

> So I would like to know what kinds of information other members put into their .htaccess files. And if there are several informations in one specific file, which order do you then put them in?

MIME type and file handler declarations (AddType & AddHandler)

Custom error page declarations (ErrorDocument)

Server options configuration (e.g. Options -Indexes)

.htaccess and .htpasswd file access control

HTTP method access control (e.g. LimitExcept GET POST)

Server exploit screening (e.g. NIMDA trap)

Referer access control (e.g. protect images from hotlinking)

Proxy access screening (disallow certain specific cases of access by external proxies)

IP address blocking

User-agent screening (e.g. larbin)

Proxy service control (prevent attempts to use our server as a proxy)

Malicious robot access controls

Various browser fixups (e.g. Netscape 7 favicon.ico redirect to custom Favicon file)

Domain and subdomain redirects (e.g. redirect example.com to example. org & map text.example.org to example.org/test/)

Dead file response configuration (410-Gone for HTTP/1.1 requests, 404-Not Found for HTTP/1.0)

Replaced file redirects

E-mail form and script access controls

Cache control header configuration (ExpiresActive, ExpiresDefault, Header unset, Header append, etc.)

The order is based on what makes sense for your site; code dependencies, code execution efficiency, and keeping the file organized are my priorities.

> Do you have .htaccess files on several different levels for specific purposes or do you put all the informations in one file?

Yes, but I personally prefer to keep most of it centralized for ease of maintenance. On my sites, certain default settings made in top-level .htaccess are overridden by settings in subdirectory .htaccess. An example would be cache-control settings; I set the expiration time on files in the 'gif images' subdirectory to a much longer time that the default setting made in the top-level file.

You have to trade off code execution efficiency against centralized administration. For example, you might want to move all the code that prevents image hotlinking into the 'images' subdirectory. I used to do that myself, but then I moved the code back to the top level because I expanded it to protect scripts and CSS files after having those exploited.

> How do you edit them? One of my hosting companies have this wonderful file management with the option of showing hidden files so I can see and edit my .htaccess files in real time.

I edit on my own computer and upload to the server, but again, this is a personal preference. I can see how having a 'real-time edit' capability on the server would greatly help code testing, though (always test new code in a test subdirectory if possible, not on the 'live' part of the site!)

If you do edit on the server, always create a backup before you edit anything, no matter how small.

> Have you learned any lessons about .htaccess the hard way by making disastrous mistakes?

Yes,

See last line of previous answer... ;)

Study regular expressions and get comfortable with them. There's no way to play with mod_rewrite safely without a good understanding of regular expressions.

Concentrate on fixing problems that your site needs to have fixed - there is no need to block every potentially-misused user-agent that ever existed or ever will exist. Concentrate on the 'big problems' first.

Test your code. Every time. Just like making backups... every time.

... And, if you discover some neat new trick, post it here! :)

Jim