Getting Started with Apache 2.0 Part III - URL Rewriting (Page 3 of 4 )
The following comment by Brian Behlendorf, a member of the Apache Group, sums up the power and complexity of the next module that I'm going to talk about: "The great thing about mod_rewrite is it gives you all the configurability and flexibility of Sendmail. The downside to mod_rewrite is that it gives you all the configurability and flexibility of Sendmail." It's time to say hello to the "mod_rewrite" module!
Originally invented by Ralf S. Engelschall in 1996, the "URL Rewriting" module allows you to "rewrite" a URL using a "rule-based" engine. To be more specific, each set of rules is associated with a list of conditions in the configuration file. The "rewrite" engine reads each combination one by one, and if a particular condition is satisfied, the engine implements the associated rule. Note that the rules and conditions can consist of server and environment variables, timestamps, complex regular expressions and much more.
At the onset, I'll admit that the examples listed below are similar to the ones listed in the "URL Rewriting Guide" by Ralf S. Engelschall (the inventor of the module) and hosted at http://httpd.apache.org/docs-2.0/misc/rewriteguide.html.
With that little caveat out of the way, I would like to highlight that the "mod_rewrite" module is not enabled by default. You'll have to compile it into the Web server using the "--enable-rewrite" compilation option or load it at run-time as a DSO module. Next, you must enable the "rewrite" engine by adding the following directive to the Apache configuration file:
RewriteEngine On
Now, consider the example of a rogue website that displays image files hosted on your Web server. Not only does the bandwidth utilized (for displaying the image off your Web server) count towards your monthly quota, but you also must grapple with a violation of your intellectual property. No can do!
How can "mod_rewrite" help you out? Add the following lines to your configuration file and re-start the server:
# Images may not be included from external sites
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://www.mysite.com/.*$ [NC]
RewriteRule .*\.jpg$ - [F]
Now, any request to an image file (with a ".jpg" extension) should result in a "403 - Forbidden Request" response to the rogue server. Of course, requests from your own website, accessible at "http://www.mysite.com", will continue to be served without any hassle.
It's time to decipher the magic behind these new directives. I've already indicated that you need to specify a set of conditions (using the "RewriteCond" directive) and rules (using the "RewriteRule" directive) for each requirement.
In the above example, the two "RewriteCond" directive statements test the value stored in the "HTTP_REFERER" server variable against two regex patterns - one matches an empty string and the other matches the URL of your website. The "[NC]" special flag at the end of the second statement informs the engine to carry out a case-insensitive regex pattern match.
The bottom line: with any request that does not have blank referrer or is not a request from your own website, the associated "rule" is enforced, which brings us to the "RewriteRule" directive.
Once again, a simple regular expression, which matches the request strings that end with ".jpg", does the job. Note the use of the "[F]" flag, which informs the Web server to send a "403 - Forbidden Request" response to the client for all such requests.
You can also use "URL Rewriting" to serve different versions of a page depending on the local time on the Web server. In the example demonstrated below, for all requests to the file "weather.html", the server will display "weather.day.html" between 5 a.m. and 8 p.m. and "weather.night.html" between 8 p.m. and 5 a.m.
RewriteCond %{TIME_HOUR}%{TIME_MIN} >0500
RewriteCond %{TIME_HOUR}%{TIME_MIN} <2000
RewriteRule ^weather\.html$ weather.day.html
RewriteRule ^weather\.html$ weather.night.html
To be frank, I've only covered the tip of the iceberg - the "URL Rewriting" module is much, much more resourceful than indicated by the examples listed above. I'll leave it to your sense of adventure and discovery to unearth its true potential!
Next: Et Cetera >>
More Apache Articles
More By Harish Kamath
