htaccess vrs httpd.conf?
Is it still true that you shouldn't use htaccess files if you can use httpd.conf?
The Apache site says "In general, you should never use .htaccess files unless you don't have access to the main server configuration file." But I don't know how old that advice is, or if it's still relevent.
I'm working on a large site that only uses the httpd.conf file. But it's getting very long and of course requires a reboot any time a change gets made. And with the number of departmental sites running under the main site (and all using the httpd.conf file), it's a disincentive to ever make changes.
Now we are running wordpress 3 (in a multisite configuration) as well. I want to test some changes to the config rules, but the only way I can currently do that is to keep restarting apache, which I'd rather not do on the live site. (in particular the rewrite rules seem to be misbehaving where some blog posts are getting prepended with "www.", while others aren't)
I was considering enabling .htaccess just on the wordpress folder, but is it wise?
Our server is busy (about 60k page views a day, according to google), but isn't being taxed too hard.
What is the current best practice? Are servers now sufficiently grunty that a possible slight performace hit is negligable compared to the ease of managment of the .htaccess files?
But it's getting very long and of course requires a reboot any time a change gets made.
If length is a problem, then consider breaking out configuration sections and using the Include directive instead. As others have said, it's possible to reload the httpd configuration with 'reload' or 'restart', and this should reduce disruption for your users. You'd need to train your administrators to use 'reload' or 'graceful', which is easier said then done-- many people don't know about these commands, and some people don't trust them.
Here are some reasons why .htaccess files are considered evil:
.htaccess files cause confusion. I once inherited a site which had over 50 .htaccess files throughout the directory hierarchy, which were created by dozens of different people spanning back 6 years. It was very difficult to figure out the "server configuration" for any particular directory, or why certain features didn't work on certain directories.
Security: Any user who can write to the .htaccess file can override some of your carefully thought-out settings which you placed in httpd.conf , unless you take care to restrict the available options with AllowOverride. See When (not) to use .htaccess files for more information.
Auditing: It's easy to create a configuration management for your main httpd.conf and Include'd directories. This provides a nice audit trail of who did what. It's more difficult to implement configuration management when the configuration files are spread throughout the directory hierarchy.
Loss of control: It's possible for someone to create an .htaccess file and not tell you. Pretend someone did this at 5PM on a Friday, added a bunch of mod_rewrite rules which did the wrong thing and broke a bunch of pages, and then the person left for the weekend. You don't discover the problem until Monday.
There are certainly cases where .htaccess files make sense-- if there are only a handful of .htaccess files, and the purpose of each is well understood.
The downside the an .htaccess file is that you have to load the file with every request. So it adds overhead. If all your rules are in your conf file, then they are loaded when apache loads, and that is it. So if you with your sites that is 60K less files it has to read. Plus any rules that can be pre-processed won't be, which could cause a delay in response. Now days disk speeds and processor and ram are abundant and fast, I think for most sites the effect is hardly noticeable.
As crimson_penguin said, there is a why to have apache re-read the config file without restarting it. Most OS'es do this with the reload command instead of the restart. If using the apache2ctl command, you would run apache2ctl graceful you can run apache2ctl configtest first to make sure everything is in order. Of course you'll need to run this as root.