Lately I’ve been doing alot of web development work.  Not here on Yeraze.com, as you can obviously see, but on http://daac.hpc.mil (for work) and http://www.finalcolony.com (for fun).  I’ve been learning alot about JavaScript and CSS, and I hope to start sharing what I’ve learned soon.  But just recently I’ve been playing alot with .htaccess files.  I’ve worked with them a bit in the past to setup custom 404 pages and password protect areas, but I’ve never done much more.  Well, recently I’ve learned a few pretty neat tricks that I want to share.

  • URL Redirection to a www. version of a hostname
  • Locking a site during development
  • Dynamic Compression (GZ) of PHP output
  • Dynamic Compression (GZ) of JavaScript & CSS files
  • Static Compression (GZ) of JavaScript & CSS Files

So come on in and see how I did it… [tag:apache][tag:htaccess]

URL Redirection to a www. version of a hostname

One very common problem when working with AJAX requests is that security measures prevent you from downloading a page via JavaScript on a domain other than the one hosting the JavaScript.  This constantly stings me when people use "http://yeraze.com" to get to my site instead of http://www.yeraze.com .  So, how do I fix this?  If I redirect everyone who goes to "http://yeraze.com" to "http://www.yeraze.com", then the problem is fixed.  In my .htaccess, this is easily fixed with a rule like so:

RewriteCond %{HTTP_HOST} !^www.yeraze.com
RewriteRule ^(.*) http://www.yeraze.com/$1 [L,R=permanent,NC]

This redirects every request that comes to the site that does not start with "www.yeraze.com"  to the same site prefixed with www.yeraze.com.  It’s done via a real Redirect (Permanently), and is a Non-Case Sensitive match.

Locking a site during development

Another common thing is to have the site operating on the real domain & webserver, but only accessible to a certain few developers.  What do you do for everyone else?  Well, you could password lock it, but that throws up an annoying popup everytime someone hits the site.  There has to be a cleaner way, right?  How about this:

ErrorDocument 403 http://www.finalcolony.com/splash/index.html
Order deny,allow
Deny from all
Allow from <ip address>
Allow from <another ip address>

People from the specified IP addresses will see the real site, but everyone else will be Denied.  Then, we change our 403 (Access Denied) error page to take us to a nice splash page for everyone else.  Simply place another .htaccess in splash subdirectory with "Allow from all", and put whatever you want in that subdirectory. 

Dynamic Compression (GZ) of PHP output

This is an easy one, simply add the following to your .htaccess :

php_flag zlib.output_compression On

And all your PHP script output will be GZ compressed, if the client supports it.  It’s a neat way to conserve bandwidth at the (minimal) expense of gz-compressing your output on the fly.  I really only bring this up as a segway to the next category…

Dynamic Compression (GZ) of JavaScript & CSS Files

Compressing your HTML is nice, but what about all the JavaScript & Stylesheets?  If you use libraries like Mootools or Prototype, then you could easily have 50k of JavaScript to send to the user.  Wouldn’t it be nice to compress this stuff too?  Well, you can with a bit of htaccess & php trickery.  First, create a PHP file like so:

<?php
header("Content-type: text/css; charset: UTF-8");
header("Cache-Control: must-revalidate");
$offset = 60 * 60 ;
$ExpStr = "Expires: " .
gmdate("D, d M Y H:i:s",
time() + $offset) . " GMT";
header($ExpStr);
?>

Then, create a .htaccess rules like this:

<FilesMatch ".css$">
    AddHandler application/x-httpd-php .css
    php_value auto_prepend_file /wherever/gzip-css.php
    php_flag zlib.output_compression On
</FilesMatch>

So, an explanation.  The PHP file simply outputs some HTTP header information about Cache Expiry & specifies the content-type.   The HTAccess rule specifies that all CSS files (AddHandler) should be processed via PHP, with the previously shown PHP file pre-pended (put at the beginning) of the output.  It also enables GZ compression of the output.  The result is that every CSS request will be executed via PHP with that file first. 

This can easily be extended to JavaScript files too by modifying the content-type in the PHP file to be "text/javascript" and modifying the HTaccess rule accordingly.

Static Compression of JavaScript & CSS Files

So, compressing on the fly can offer a huge bandwidth savings, but it does cost a tiny bit of CPU utilization.  While the utilization is minimal, if the JavaScript & Stylesheets never change then you should be able to compress them once and never worry about it again, right?  Here’s a rule to do that:

RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule ^(.+) $1.gz [L]

So, this checks that the client accepts GZip compressed files, and that the requested file exists on the system with a gz extension.  If it does, then the GZ compressed version of the file is sent to the user instead of the original one.  With this rule, you can compress files that rarely ever change (JavaScript libraries, stylesheets, etc) and place a compressed copy alongside the uncompressed, and the rule will handle the rest.

HTaccess files can really do alot of neat stuff, and this just scratches the surface.  For alot more ideas you can check out the "Stupid htaccess Tricks" blog.

Be Sociable, Share!