Same difference. 12% on 1 server is 12%. But if you have a dozen servers with the same 12% gain then it's still 12%. Such is the nature of percentages.

> therefore, if you get hit by something that will actually make a difference, it's not going to be within 12%. it's going to be like 12,000%. so, it's not going to make a whit of difference at that point whether you have httpd.conf or .htaccess.

I manage a data centre for a number of high profile sites. If I can improve throughput by 12% then that means I need one less server in the farm. It means less strain on the db as connections are clearing down quicker. And it also means the likelihood of visitors hitting 'refresh' due to slow load times is reduced, which in turns slows the exponential growth that happens shortly before a site buckles. So trust me when I say 12% does matter if you're building busy sites - I know this because I wouldn't be doing my day job properly if I didn't load test this stuff and implement any free optimisations I can.

> i'm just saying, if you've got access to httpd.conf, you've got the whole server. that means you've probably got bigger fish to fry as to worrying about security than a pretty harmless, defaulted as secure, .htaccess file.

Yes, I'd already said the former point myself, however your latter point is still ignoring the simple fact that you don't need to be root to edit a .htaccess file. I repeat, you do /NOT/ need to be root to edit a .htaccess file!

Someone can edit your .htaccess file even when they don't have permissions to edit httpd.conf (and thus ssh_config nor anything else in /etc nor other root-owned config hierarchies). Thus if your http docs are writeable (and they typically are for personally web servers as you don't have a dedicated network storage such as a SAN shared across your web servers, so your content is stored on the web server itself) then a bug in your website could allow an attacker access to write to the disk in the web docs directory. In short, attackers could create and edit their own .htaccess files.

We're not talking about root access here, these are not attacks that have permissions to write to httpd.conf; we're talking about a http-owned (eg 'www-data' on Debian) users who shouldn't have ability to write files having that ability to edit the Apache config because .htaccess is not typically root owned.

If you want the convenience of a .htaccess file but the security of a httpd.conf, then change all your .htaccess files to be root owned:

    sudo find / -name ".htaccess" -exec chown root:root {} \; -exec chmod 644 {} \; -print

> Same difference. 12% on 1 server is 12%. But if you have a dozen servers with the same 12% gain then it's still 12%. Such is the nature of percentages.

no. you said it yourself. if you save 12% on a server farm, you can drop out a server. with a single vps, you can't or else you go from one server to none. and, we're talking about self-hosting vs. shared hosting, we're talking about a single server and not an elastic cloud. so, 12% degraded perf? meh. 12,000% degraded perf? boom.

> I repeat, you do /NOT/ need to be root to edit a .htaccess file!

yessir. i understand that. i've been writing apache vhost files (tho, i think back then it was straight-up httpd.conf files and not vhosts - shrug whatever. my memory sucks.) since the late-nineties on slackware machines.

my security point:

1) shared hosting -- by default, you have the ability to tinker with .htaccess files and NOT httpd.conf. this means for it to be insecure, you have to explicitly do something silly with it. not just turn indexes on or off. (indexing security arguments not withstanding)

2) vps/managed/under-your-desk hosting -- this is where you can actually make changes to httpd.conf. but, you're responsible for the whole machine, not just apache configs. you have to secure the entire machine and its services from ssh to ftp (eek!) to security updates and everything in between.

ergo: if the answer to httpd.conf vs .htaccess is "httpd.conf gets more performance" and "httpd.conf has better security"...

i say the performance isn't relevant in the self-hosted, non-clustered model and you've probably got bigger security holes in your server to worry about than some .htaccess files in your htdocs directories owned by www-data.

does that make sense?

That was just an example. But using yours, that's more the reason to try and save overhead because you don't have the ability to spin up extra nodes when traffic gets heavy.

> yessir. i understand that. i've been writing apache vhost files (tho, i think back then it was straight-up httpd.conf files and not vhosts - shrug whatever. my memory sucks.) since the late-nineties on slackware machines.

Ditto here :) I don't use Slackware these days I used to love that distro. Still miss it at times.

> 1) shared hosting -- by default, you have the ability to tinker with .htaccess files and NOT httpd.conf. this means for it to be insecure, you have to explicitly do something silly with it. not just turn indexes on or off. (indexing security arguments not withstanding)

Well yeah, but it's a bit of a moot point because there are no alternatives to .htaccess with shared hosting. Plus they'll generally do some clever stuff to sandbox each users vhost (something along the lines of each vhost running as a different user, if I recall correctly. I've never provided shared hosting solutions my line of work is supporting high profile sites / cloud services)

> does that make sense?

Not really. It's just a lazy dismissive argument in my opinion. Saying something doesn't matter because there's "probably" other issues is the kind of attitude that leads to servers getting hacked.

You seem a nice guy and experienced as well, so I'm not criticising your abilities. But whenever I hear others say "I can't be bothered doing xyz and there's probably other issues", they usually end up getting hacked (or breaking it themselves) a few months down the line.

right? ...stupid redhat coming along and making it obselete!