Htaccess Tricks and Tips | Hacker News Reader

Htaccess Tricks and Tips

queness.com

61 pointskingsidharth18 comments

> AddType application/octet-stream .pdf

Please don't do this. I would rather have my browser's default behavior for application/pdf than have your web site force it to treat your PDF files as opaque binary blobs.

Ditto the above comment. If users don't want to be asked if they want to download/open a file they can use the "Automatically do this from now on" option that Firefox gives them, or the equivalent in their preferred browser. Then users get their preferences, and the not servers forced on them.

Also, if you have root, don't use .htacess files in production and you'll get a performance boost. Set 'AllowOveride none' in the main config & put your .htaccess in a <directory> block included in the main config at launch.

Came here just to say that, you beat me to it. htaccess files are performance-crippling crutches for allowing config access in limited shared hosting environments. If you own the server, never use them. For performance reasons nginx doesn't even have a similar concept.

One interesting thing to note is that every Apache config file will (or should have!) some lines like this in it:

  <Directory />
    AllowOverride None
  </Directory>

If this is not there, Apache will look for a .htaccess file in every single folder starting at '/' all the way up to your document root and on into the folder of the URL being requested e.g.

Your document root is here: /very/long/path/to/your/webroot

You request the following URL: "/project/files/here/file.html", which servers this file: /very/long/path/to/your/webroot/project/files/here/file.html

Without the above config settings, Apache would attempt to stat the following files each time the url "/project/files/here/file.html" is requested...

  /.htaccess
  /very/.htaccess
  /very/long/.htaccess
  /very/long/path/.htaccess
  /very/long/path/to/.htaccess
  /very/long/path/to/your/.htaccess
  /very/long/path/to/your/webroot/.htaccess
  /very/long/path/to/your/webroot/project/.htaccess
  /very/long/path/to/your/webroot/project/files/.htaccess
  /very/long/path/to/your/webroot/project/files/here/.htaccess

Ouch!

If you have the above mentioned config in place (it's part of most default apache configs, but I have seen mis-configured servers without it), but you allow override for your webroot, you will still have the following file stats to perform for the same URL request:

  /very/long/path/to/your/webroot/.htaccess
  /very/long/path/to/your/webroot/project/.htaccess
  /very/long/path/to/your/webroot/project/files/.htaccess
  /very/long/path/to/your/webroot/project/files/here/.htaccess

Which is still rather wasteful if not absolutely necessary. Only use .htaccess files when no other option is available.

First of all, I haven't used apache httpd in production for years and I'm happier for it. It's inefficient. .htaccess only compounds that inefficiency.

General: 1. I've found using anything but GMT/UTC on servers is a recipe for confusion.

4. Great idea, but like most of the recommendations, it's not .htaccess specific. Websites should either redirect www.foo -> foo or foo -> www.foo. Presenting a consistent hostname that way can prevent some cookie-related headaches, and will avoid having search engines index different pages under different hostnames.

8. That recipe inadvertently deletes Cache-control: private

RewriteRule ^(.*/)?\.svn/ - [F] if you checkout code into production server you source files could be accessible from .svn folder.

Why would you checkout to production, rather than export?

Checking out svn production probably isn't ideal, but lots of people do it. I think the default capistrano+svn set up actually does a checkout behind the scenece. It's usually much faster than an export and it means that if you have to tweak a file on production (yikes!) you can check that change back in.

Also, deploying via export is trickier than it sounds. You can't just cd to /var/www/whatever and run "svn export" or else you'll end up with files deleted from the repository still existing on production.

You can't just cd to /var/www/whatever and run "svn export" or else you'll end up with files deleted from the repository still existing on production.

Why would you do that, either? I thought it was something of a best practice to use symlinks for that sort of thing, so you could export to a new directory then change the symlink to point to the directory you just created.

Of course... but that's more work than typing "svn up" on production and lots of developers don't taking deployment strategies nearly as seriously as they should.

That saddens me. I've never done anything serious on the web, but I'm building a project for the first time now and I've been procrastinating a lot by learning the best ways to do everything. The fact that so many people just do a half-assed job and stay employed, while I've been out of work so long (hence the aforementioned project, actually, since I'm hoping to use it as leverage to find someone willing to give me cash bi-weekly).. like I said, it saddens me.

Amen brother. I've worked at a place where our 'deployment script' logged into each of our production servers and ran svn up in working copies. This company handled thousands of financial transactions every day.

At my current company we have a decent sysadmin, so things are a bit more sensible (a combination of svn export, running tests, then an rsync to our production box.)

Don't be saddened, be angry. When you do start doing stuff on the web, do it properly so other people don't have to eventually maintain the nightmare you might have created!

I'm totally with you. Having crappy deployment and source control isn't just annoying, it's counterproductive.

But also keep in mind that crappy code that ships beats perfect code that never ships every time.

Because a checkout allows to update afterwards, which means deployments are faster.

- Enable Strict-Transport-Security:

Header set Strict-Transport-Security "max-age=86400"

- Let GoogleFrame do its magic:

BrowserMatch chromeframe gcf

Header append X-UA-Compatible "chrome=1" env=gcf

How do you redirect traffic?

Say I have tomcat running on port 8080 but I want people to just go to www.site.com/tomcat

Look into the ProxyPass directive, but I don't think that'll work in htaccess.

mod_jk used to be the way to do it with apache. not sure if it's still the "best" method or not. It acts as a proxy between tomcat and apache.

Reply on news.ycombinator.com