With the ever increasing number of websites dealing with e-commerce, forums and blogs, dynamic solutions have become really popular these days.
Dynamic websites are those connecting to some sort of database to retrieve information and display them into the same page; this is particularly useful if you don’t want to create by hand a thousand pages, one for each of your products, and then, when you’re finally done, change them again because the design was not so good after all.
Though, when dealing with dynamic websites, a problem usually arises: URLs.
In fact, the big advantage of static websites is their placement in search engines lists, due to their clean, search engine-friendly URLs.
The problem resides in the way dynamic websites obtain information from the user. Let’s say we run a successful online store and users can read product details accessing the following URL:
http://example.com/index.php?category=1&product=234&page=details
It’s not very nice to look at especially compared to what a static website’s looks like
http://example.com/shoes/234/details.html
And that’s exactly what we’ll end up with! The reason being most search engines cut off the part coming immediately after some special signs (& = ?) resulting in several pages that all look the same and provide no information about their actual content in the URL.
But we can change that. And the change is possible in several server-side programming languages either directly or with the help of extension module.
The most common HTTP server comes with an extension called mod_rewrite that lets you create pretty looking URLs with little effort. Lots of options are available, too, to make mod_rewrite work exactly as you wish.
The very first thing to do is making sure the mod_rewrite module is installed by uncommenting the corresponding line into the Apache’s configuration file.
Now, the trick is to put in your .htaccess file just a couple of lines that make the web server “translate” URLs:
RewriteEngine On RewriteRule products/(.*)/(.*)/(.*)\.html$ index.php?category=$1&product=$2&page=$3 [NC,L]
The first line just enables the rewrite engine, while the other one is the regular expression the program has to take into account whenever requests are made.
So, whenever users try to reach
http://example.com/products/1/234/details.html
the server automatically translates it and sends in to the server a request for the page
http://example.com/index.php?category=1&product=234&page=details
The [NC,L] part are flags. Flags are used to tell the application some more instructions; for example, NC means No Case and causes the rewrite rule to be matched in a case insensitive manner, while the L (Last)flag tells mod_rewrite to stop processing the rule set.
There are many other flags, some really useful, whose description can be found here.
A special mention is required for the RewriteCond directive, that works as a conditional statement would. The RewriteCond, if proved correct, jumps directly to the nextmost RewriteRule and applies it.
# Is the request for a non-existent file?
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^/$ /this-is-a-directory.html [L]
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^/$ /this-is-a-file.html [L]
RewriteRule ^/$ /does-not-exist.html [L]
This checks for the requested file (or directory) and redirects all the requests to the page describing the current situation. The process stops once the right condition has been detected.
Further information is here.

The problem here is to find a good extension which is free and works as it should.
I find IIRF (Ionic’s ISAPI Rewrite Filter) really nice as it works pretty much the same as Apache’s directives do.
Installation instructions and a relatively extensive documentation is available online.
OpUrl is another, rather simplistic, extension whose full version is sold for US$40.
The OpUrl.txt configuration file syntax looks like the following:
[www.domain.com] /products/([0-9]+) /product.asp\?id=$1
OpUrl configuration lists all the rules for the selected domain one under another. Also, a few options are available; though, it’s great for basic usage only — which is what most of us need anyway.
ISAPI_Rewrite 2 offers a very cool package with lot of options and possibility to control almost everything for as low as US$99.
Syntax isn’t a big deal and there are some options that let you do extremely interesting things, such as changing case of result to either lower or upper.
IIS Mod-Rewrite claims to be the ultimate URL rewriter for IIS, and I must admit they’re quite right, since it’s also mod_rewrite compatible, so that you can migrate your Apache configuration to IIS and viceversa. All this for just US$75.

I found just one package that allows proper URL rewriting for Java, that is, Url Rewrite Filter.
It’s based off Apache’s mod_rewrite, and “allows you to rewrite URLs before they get to your code. It is a very powerful tool just like Apache’s mod_rewrite”.
You can use either mod_rewrite-style syntax or XML syntax. Since we’ve already seen how mod_rewrite syntax looks like, let’s have a look at the XML-style syntax (the following code is to be put in the <urlrewrite> section in the configuration file).
<rule> <from>^/products/(.*)/(.*)/(.*).html$</from> <to>/index.jsp?category=$1&product=$2&action=$3</to> </rule>
The result will be, as usual, that the page
http://example.com/products/1/234/details.html
will correspond to
index.jsp?category=1&product=234&action=details

Sometimes we haven’t the rights to run .htaccess files or install any rewrite module and we’re left alone with PHP and URLs to clean up.
Actually, just a couple of lines are enough to do the trick
<?php
// This is index.php in the root directory of your website
//
// REQUEST_URI can be used too, and gets the query part as well
$vars = explode ('/', preg_replace ('/^(\/)/', '', $_SERVER['PHP_SELF']));
// print_r ($vars);
?>
Now, whenever you load index.php, the script gets the path you requested, removes the ‘index.php’ part, then explodes the query string so that all the stuff we look for can be found into one array, called $vars.
Users can now type
http://example.com/index.php/1/234/details
and get (print_r output)
Array
(
[0] => 1
[1] => 234
[2] => details
)
From now on it should be pretty straightforward, since you already have the variables you’d would obtain from the $_GET array and you can play around with them as you wish.
A little drawback could be the ‘index.php’ part still showing in the URL, but this could be easily fixed with the help of Apache.
You probably couldn’t see the point, since if you have Apache installed it’s easier and logical using mod_rewrite, but you could have the web server without mod_rewrite available.
Options MultiViews
should be added to the .htaccess file. And then access your website through
http://example.com/index/1/234/details
Multiviews option makes Apache look for any file whose name is ‘index’ and guess the extension automatically.
A step forward could be changing the ‘index’ part to ‘product’, which actually makes more sense
http://example.com/product/1/234/details

The Rails framework has definitely contributed to the evolution and success of the ruby language. And so does in the case of URL rewriting.
The Routes controller module works with any web server and completely replaces Apache’s mod_rewrite.
Routes are defined in the routes.rb file and, once you generate the files for your project, a default route for your application comes already installed:
ActionController::Routing:Routes.draw do |map| map.connect ':controller/:action/:id' end
which means that when you load a page like
http://example.com/blog/edit/12
you’ll end up with
params = { :controller => 'blog',
:action => 'edit',
:id => '12'
}
While ‘:controller’ and ‘:action’ respectively map to your controller name and to an action with your controller, other words just map to a parameter, exactly as ‘:id’ does.
An example to generate pretty-looking URLs for our e-commerce website would look like
map.connect 'product/:category/:product/:action',
:controller => 'products',
:category => /\d{1,2}/,
:product => /\d{1,4}/,
:action => 'show'
Resulting in the possibility to access pages through the following URL:
http://example.com/products/1/234/show
The parameters would then be
params = { :category => '1',
:product => '234'
}
Some more information can be found here.

It’s interesting to read on the Django website how Django processes a request:
When a user requests a page from your Django-powered site, this is the algorithm the system follows to determine which Python code to execute:
1. Django determines the root URLconf module to use. Ordinarily, this is the value of the ROOT_URLCONF setting, but if the incoming HttpRequest object has an attribute called urlconf, its value will be used in place of the ROOT_URLCONF setting.
2. Django loads that Python module and looks for the variable urlpatterns. This should be a Python list, in the format returned by the function django.conf.urls.defaults.patterns().
3. Django runs through each URL pattern, in order, and stops at the first one that matches the requested URL.
4. Once one of the regexes matches, Django imports and calls the given view, which is a simple Python function. The view gets passed an HttpRequest as its first argument and any values captured in the regex as remaining arguments.
The URLconf module is exactly what we need to analyze and eventually modify in order to enable URL rewriting. Here’s a sample URLconf configuration for our e-commerce site
# required for patterns()
from django.conf.urls.defaults import *
urlpatterns = patterns ('',
(r'^products/(\d{1,2})/(\d{1,4})/(.*).html$', 'shop.views.product_show')
)
As you can see, the code is pure Python with some regular expressions. It basically works as a mapping between URL patterns and Python callbacks functions.
Whenever the URL
http://example.com/products/1/234/details.html
is requested, Django calls the function
shop.views.product_show (request, '1', '234', 'details')
Obviously, a lot more is possible, and you should read some documentation for more detailed information.
Great post, thanks!