The most common mistake people make when thinking of URL redirection with mod_rewrite, is they believe it creates something, or changes something. It doesn’t.

Here is a simple example, redirecting a page dependent upon its query string. The rewrite condition and rule looks like this:

RewriteCond %{QUERY_STRING} ^id=([0-9]*)$
RewriteRule ^page\.php$ http://www.example.com/page/%1.php [R=302,L]

The rewrite condition matches a numerical ID between 0 and 9. According to the official documentation, you would expect the following behaviour:

/page.php?id=1 -> http://www.example.com/page/1.php
/page.php?id=10 -> http://www.example.com/page/10.php

However, if you don’t append something new, then the original query is passed through by default. This results in the following:

/page.php?id=1 -> http://www.example.com/page/1.php?id=1
/page.php?id=10 -> http://www.example.com/page/10.php?id=10

If you want to discard the original query string you must append an empty question mark at the end of the rule; the query string not append or query string discard flag.

RewriteCond %{QUERY_STRING} ^id=([0-9]*)$
RewriteRule ^page\.php$ http://www.example.com/page/%1.php? [R=302,L]

Putting it all together, here’s a quick reference for dealing with query string in a RewriteRule.

Keep original query (i.e., the default behaviour)

RewriteRule ^page\.php$ /target.php [L]
# from http://www.example.com/page.php?foo=bar
# to http://www.example.com/target.php?foo=bar

Discard original query

RewriteRule ^page\.php$ /target.php? [L]
# from http://www.example.com/page.php?foo=bar
# to http://www.example.com/target.php

Replace original query

RewriteRule ^page\.php$ /target.php?bar=baz [L]
# from http://www.example.com/page.php?foo=bar
# to http://www.example.com/target.php?bar=foo

Append new query to original query

RewriteRule ^page\.php$ /target.php?bar=baz [QSA,L]
# from http://www.example.com/page.php?foo=bar
# to http://www.example.com/target.php?foo=bar&bar=foo

Dave Child has created a great mod_rewrite cheat sheet; a one-page reference sheet, listing flags for the RewriteRule and RewriteCond directives, list of server variables, a regular expression guide and several examples of common rules.

Redirect /page.php http://www.example.com/target.php

More commonly, however, you’re likely to want to do a mass-redirection of pages. To accomplish this, you may use the RedirectMatch directive.

RedirectMatch ^/category/(.*)$ http://www.example.com/topic/$1

This will redirect any page from the category folder to the corresponding one in topic folder with a convenient one-by-one redirect.

However, neither Redirect nor RedirectMatch allow you to specify a query string for the redirect source. In other words, the following statements are invalid and they’ll simply be ignored.

# single page redirect
Redirect /page.php?id=1  http://www.example.com/page/1
Redirect /page.php?id=10  http://www.example.com/page/10
 
# multi-page redirect
RedirectMatch ^/page.php?id=([0-9]*)$  http://www.example.com/page/$1

The solution requires a change of focus from Apache’s mod_alias module to the mod_rewrite module. Here’s an example.

RewriteEngine On
RewriteCond %{REQUEST_URI}  ^/page\.php$
RewriteCond %{QUERY_STRING} ^id=([0-9]*)$
RewriteRule ^(.*)$ http://www.example.com/page/%1.php [L,R=301]

The mod_rewrite module uses a rule-based rewriting engine (based on a regular-expression parser) to rewrite requested URLs on the fly. It supports an unlimited number of rules and an unlimited number of attached rule conditions for each rule, to provide a really flexible and powerful URL manipulation mechanism. The URL manipulations can depend on various tests, of server variables, environment variables, HTTP headers, or time stamps.

So what does this all mean with respect to the above example?

The first line enables the RewriteEngine module. Note that mod_rewrite Apache module must be installed and enabled in order to use the RewriteEngine.

The RewriteCond statements set all the rewrite conditions. The fourth line, the real rewrite directive, will be executed if and only if all conditions are satisfied by the current request.

The first condition is for the page I need to redirect. This condition is included to prevent any unexpected errors if other pages are using the ID variable. Next, I base the rewrite rule on the value for the current request’s query string. The ID value within the regular expression is “wrapped” to be able to reuse the match later as a back-reference.

The final line is the rewrite rule. This line looks similar to the RedirectMatch statement. It specifies the redirection source, then the redirection target. The value captured by the second RewriteCond is referenced in the target with the %N keyword (in this example %1). The RewriteRule also includes a comma-separated list of flags that should be applied to the rule. In this case, L stops the rewriting process immediately whilst R=301 specifies a permanent external redirect (301 is an HTTP Status Code).

Further reading:

• Apache URL rewriting guide
• Apache mod_rewrite
• Apache mod_alias

Apache 2.x uses mod_deflate. Much like setting expires headers, this will save you bandwidth and server load, because it allows output from your server to be compressed before being sent to the client over the network.

The deflate module is not compiled by default and must be enabled in the Apache httpd.conf file. Make sure the following is present and uncommented (remove preceding the #):

LoadModule deflate_module modules/mod_deflate.so

To set GZip compression, simply add the following to the section of your Apache vhost configuration:

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

Alternatively you can add it to your htaccess file in an <ifModule mod_deflate.c></ifModule> block.

All you really need is the first line. The BrowserMatch lines are there to handle issues with older browsers such as Internet Explorer 5.

You can read all about GZip by reading Yahoo!’s Best Practices for Speeding Up Your Web Site guide.

Alternatively, read the Apache mod_deflate documentation.

In Apache, mod_expires is a module that allows you to set a given period of time to live for web pages and other objects served from web pages. The idea is to inform web browsers how often they should reload objects from the server. This will save you bandwidth and server load, because clients who follow the header will reload objects less frequently.

The expires module is not compiled by default and must be enabled in the Apache httpd.conf file. Make sure the following is present and uncommented (remove preceding the #):

LoadModule expires_module modules/mod_expires.so

To set an expires header, simply add the following to the <virtualHost> section of your Apache vhost configuration:

ExpiresActive On
ExpiresByType image/gif "access plus 1 months"
ExpiresByType image/jpg "access plus 1 months"
ExpiresByType image/jpeg "access plus 1 months"
ExpiresByType image/png "access plus 1 months"
ExpiresByType image/vnd.microsoft.icon "access plus 1 months"
ExpiresByType image/x-icon "access plus 1 months"
ExpiresByType image/ico "access plus 1 months"
ExpiresByType application/javascript “now plus 1 months”
ExpiresByType application/x-javascript “now plus 1 months”
ExpiresByType text/javascript “now plus 1 months”
ExpiresByType text/css “now plus 1 months”
ExpiresDefault "access plus 1 days"

Alternatively you can add it to your htaccess file in an <ifModule mod_expires.c></ifModule> block.

If you need to change the length of time a type expires, simply change access plus 1 months to the appropriate length of time, e.g. access plus 1 days, access plus 365 days etc. The time length is by default specified in seconds, but you may also use any of these keys: years, months, weeks, days, hours, minutes and seconds.

You can read all about expires headers by reading Yahoo!’s Best Practices for Speeding Up Your Web Site guide.

Alternatively, read the Apache mod_expires documentation.

For example, the following is WordPress’ default URL configuration for a post:

http://www.domain.com/?p=1635

However, buy using a URL-rewriting available in the Apache webserver, we can achieve a far better result, such as the following:

http://www.domain.com/search-engine-safe-urls

NB. It is also possible to achieve a similar result with an ISAPI rewrite for Microsoft’s IIS webserver, but this topic will not be included in this post.

To get your website working with SES URLs you need to enable both the mod_rewite module and AllowOverride directive in the Apache configuration file.

Uncomment (remove #) from the following to enable the re-write rule:

LoadModule rewrite_module modules/mod_rewrite.so

Change the AllowOverride directive from none to all

<directory />
    Options FollowSymLinks
    AllowOverride all
    Order deny,allow
    Deny from all
</directory>
 
<directory "C:/WebRoot">
    # Possible values for the Options directive are "None", "All",
    # or any combination of:
    #   Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
    #
    # Note that "MultiViews" must be named *explicitly* --- "Options All"
    # doesn't give it to you.
    #
    # The Options directive is both complicated and important.  Please see
    # http://httpd.apache.org/docs/2.2/mod/core.html#options
    # for more information.
    #
    Options Indexes FollowSymLinks
 
    #
    # AllowOverride controls what directives may be placed in .htaccess files.
    # It can be "All", "None", or any combination of the keywords:
    #   Options FileInfo AuthConfig Limit
    #
    AllowOverride All
 
    #
    # Controls who can get stuff from this server.
    #
    Order allow,deny
    Allow from all
</directory>

On Apache webservers, .htaccess (hypertext access) is the default name of directory-level configuration files. An .htaccess file is placed in a particular directory, and the directives in the .htaccess file apply to that directory, and all its subdirectories. It provides the ability to customize configuration for requests to the particular directory. In our case, enabling search engine safe (SES) URLs.

By setting the AllowOverride directive to All in effect defers configuration settings to the .htaccess file.

An example .htaccess file could include the following code to rewrite the URLs:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L,QSA]

Search engine friendly URLs are implemented with Rewrite engines. The rewrite engine modifies the URL based upon a number of rewrite conditions and rules.

The RewriteBase directive explicitly sets the base URL for per-directory rewrites. The RewriteCond directive defines a rule condition, so in this case handling missing files or directories. Finally, the RewriteRule directive is the real rewriting workhorse. In this example, we’re getting everything in the URI — i.e. not including the protocol (HTTP/S) and domain name — based upon a regular expression. This is then appended to the default file reference — index.php — as a back reference. The [L,QSA] refers to the rule being the last rule and append any query string parameters to the default file. It is important to note that this is all done on the server side, the user will never see the website address changing in the browser’s address bar. Furthermore, simply transposing the index.php filename with your default file name — e.g. index.cfm, default.aspx — will have the same result. Indeed, the above rewrite rules are becoming a de-facto standard for web applications.

To fully understand mod_rewrite rules above, look at the Apache mod_rewrite documentation.

Once you have your SES functionality in place on the webserver, it is then the responsibility of your application framework to understand the URL construction and handle it accordingly. Fortunately, frameworks such as ColdBox and Fusebox for ColdFusion, Zend and Symfony for PHP, all contain functionality to do this, but that is the subject of an entirely different post.

Users of web applications prefer short, neat URLs to raw query string parameters. A concise URL is easy to remember, and less time-consuming to type in. If the URL can be made to relate clearly to the content of the page, then errors are not only less likely to happen, but our good friends the search engine robots are able to draw a stronger assumption of the pages’ relevance and content.