

Htaccess Tricks and Tips - kingsidharth
http://www.queness.com/post/5421/17-useful-htaccess-tricks-and-tips

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

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

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

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

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

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

~~~
AgentConundrum
Why would you checkout to production, rather than export?

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

~~~
AgentConundrum
_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.

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

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

~~~
alinajaf
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!

------
mike-cardwell
\- 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

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

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

