Comment by laumars | Hacker News Reader

Comment by laumars | Hacker News Reader

Parent Full thread

> as in, if you get slasdotted (ha! i'm old!) your site will stay up either way as long as you're getting less than 215 rps. and it goes down either way if you're getting more than 245 rps. that's a pretty tiny window in the grand scheme of things.

12% performance boost is actually quite a significant jump when you're pushing heavy traffic and looking to shave any fat from the stack you can find.

Also your comment about "and it goes down either way if you're getting more than 245 rps" doesn't really make a whole lot of sense as the webfarm isn't going to magically crash the moment you get one request more. I suspect you're not really understanding what those ab results are representing, but that doesn't really matter as I wouldn't trust those figures for any real world usage anyway. As I pointed out in another post in this thread, the actual performance penalty will be subject to a considerable number variables.

> and, as to the security of it -- if you have access to the httpd.conf file, i GUARANTEE you've got bigger holes in your own hodge-podge, whole-system security than something like an .htaccess file on which you'd have to work really hard and explicitly make insecure.

You have things completely backwards there. httpd.conf is more secure than .htaccess because httpd.conf can only be amended and actioned by root where as .htaccess will have lower security permissions and is loaded on demand (ie an attacker doesn't need to restart the Apache daemon to action any changes).

> I suspect you're not really understanding what those ab results are representing

ah. no, no. i'm not adequately explaining where i was going with that. lemme try again.

1) it's not 12% on a web farm. it's 12% on one server.

2) that 12% manifests in a slowly degrading experience. so, it takes 4 seconds to return during peak traffic instead of 3 and a half. meh. whatever.

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.

>You have things completely backwards there

again, i'm not explaining myself well. i fully understand that, in theory, httpd.conf is more secure. i'm not talking about that.

if you have access to httpd.conf, you also probably have access to /etc/ssh/sshd_config -- did you configure that securely? does your server allow root logins? what about your mysql config? what about the latest security update to the distro?

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.

> 1) it's not 12% on a web farm. it's 12% on one server.

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

man. i must be terrible at communicating.

> 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?

> 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.

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.

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

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

hehe (though to be fair, I was running Redhat before Slackware). These days I tend to manage Debian, SLES, FreeBSD (on personal boxes) and Solaris (plus one or two Ubuntu Server boxes colleagues have set up which I'm planning on wiping when no-ones looking hehe)

ha! that's awesome!

Reply on news.ycombinator.com