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

/usr/sbin/apachectl: line 82: ulimit: open files: cannot modify limit: Invalid argument

After a little investigating it turned out to be caused by an update in the apachectl script to OSX 10.6.5.

The ULIMIT_MAX_FILES variable increases the maximum number of file descriptors allowed per child process. This is critical for configurations that use many file descriptors, such as mass vhosting, or a multithreaded server.

A quick edit of the the apachectl script and it’ll be back working.

I use TextMate, so the command is:

sudo mate /usr/sbin/apachectl

You’ll be prompted for your password.

Once the apachectl file is open, look for the following line (for me it was line 64):

ULIMIT_MAX_FILES="ulimit -S -n `ulimit -H -n`"

and replace with the following:

ULIMIT_MAX_FILES="ulimit -S -n"

This will set the correct command that increases the maximum number of file descriptors allowed per child process.

1. Enable the PHP5 module in Apache:

   LoadModule php5_module libexec/apache2/libphp5.so

   This will normally involve simply removing the hash symbol (#) at the beginning of the line.

2. Restart Apache via the command line:

   sudo apachectl restart -t

   The -t is used to run a syntax check on the Apache file, to ensure you haven’t broken anything.

3. Locate the php.ini.default file in the /etc/ directory and rename it to simply php.ini by running the following commands:

   cd /etc
   sudo cp php.ini.default php.ini
   sudo chmod 666 php.ini

4. Create a file in the web server’s document root, in this case an index.php file, with the following text included:

   <?php phpinfo() ?>

   When you browse to that file, it will display information regarding your PHP installation. (Be sure to remove this after use and certainly don’t include it in a production environment.)

That is all you need to do. Easy huh?

As a point to note, if you need to make changes to either the http.conf file or php.ini, you will need administrative access and will need to restart the Apache server for the chances to take effect.

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.

Eclipse started out as a Java IDE and has continually grown from there. Plugins now include, amongst a plethora of others, the venerable Aptana, CFEclipse, SQL Explorer, Subclipse and, more recently, the Adobe-developed Flex Builder and ColdFusion-equivalent codenamed Bolt.

Apache Ant is a software tool for automating software build processes. It is implemented using the Java language, requires the Java platform, and was originally developed to automate the build of Java projects. However, since Ant was created as a simple, platform-independent tool, it can really be used to automate the build of anything you choose.

Ant uses XML to describe the build process and its dependencies, using a file commonly called build.xml. Using this file, Ant makes it trivial to integrate unit testing frameworks with the build process and has made it easy for web developers to adopt test-driven development, and even Extreme Programming.

Fortunately for us, if you download and run Eclipse, you already have Ant installed and so do not have any complex configuration to concern yourself with; well, at least initially.

Setting Up Eclipse

For the most part, Eclipse has all you need to get up and running with Ant pre-installed. However, most projects will include a release target which uses FTP to upload the files to a live server. The FTP ant task requires some extra libraries (.jar files):

commons-net-*.jar
jakarta-oro-*.jar

(The library files can be downloaded from here).

Copy the files into the ant lib folder of your Eclipse install. The folder is commonly located here:

C:\Program Files\Eclipse\plugins\org.apache.ant_*\lib

(The asterix * refers to the Ant version).

Next, go to Window > Preferences and select Ant > Runtime. In the Classpath tab, select Ant Home Entries, click Add External JARs… and select the 2 files you copied to the ant lib folder.

A Typical Ant Project Setup

A project with ant build scripts should have the following within the repository:

• build.xml (the actual ant build script)
• build.properties.template (a template for individual build.properties files)
• an optional top level lib folder (containing jar files for external ant tasks)

Examples of the build.xml and build.properties.template files can be downloaded from here.

Create Your Own build.properties File

Make a copy of the build.properties.template file (name it build.properties) and set the values to fit your local setup (in most cases, the only property you may want to change is deploy.dir.local which is the path to the site on your local machine).

This file should never be committed to the repository (the repository should be set to ignore it anyway).

Basic Build Tasks

The build file should have a deploy.local task. This task builds the project and copies it to your local webserver (the path to the web server folder will be defined in the build.properties file).

Most projects should also have a deploy.dev task to copy the latest work to the dev server so that other people can view it.

Setting Up an Automatic Build

To make things easy, you can set deploy.local to run every time you save a file. This is called an automatic build.

The process for setting up automatic build is quite convoluted. I’m not sure why but this is the best way I’ve found to make it work.

Step 1: Add the build file to your ant view

Click the add button and select the build.xml file from the project. You can also drag the build.xml file onto the ant view (To add the ant view to your perpective, go to Window > Show View > Other…)

Step 2: Run as Ant Build

In your ant view, right click the newly added build file and select Run As > Ant Build… In the dialog window, select the ‘Hide internal targets not selected for execution’ option in the Targets tab. You can rename the builder in the box at the top of the window if you wish (I usually remove the trailing ‘build.xml’. Click Apply and Close.

Step 3: Setup automatic build

Right click on the project, select Properties, then Builders. Click Import. Before closing the screen, highlight the imported build and select edit. Go to the Targets tab select clean for ‘After a clean’ and deploy.local for ‘Auto build’. Apply the changes and close.

Step 4: Enable Auto Build

Go to Project > Build Automatically

Acknowledgment: Thanks should go to Martin Laine for his help and guidance which resulted in this article.

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.

Only one usage of each socket address (protocol/network address/port) is normally pemitted.
make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to openlogs
Note the errors or messages above, and press the < ESC > key to exit.

Initially I thought it was a problem associated with Windows Vista (yes my development machine is a Vista PC!) and the previously installed IIS. However, after a lot of deliberating and Google searches, it appears that Skype was the culprit. Skype listens on port 80 and 443 for incoming requests. So to solve the problem I simply closed down Skype and re-installed Apache. As Apache was setup as a Windows service, no conflicts subsequently arise with Skype as Apache will start using the ports before Skype.

There is a setting in Skype under Tools > Options > Advanced > Connection called “Use port 80 and 443 as alternatives for incoming connections”. This is checked by default. Uncheck this to prevent conflicts with Apache.

The Key Point: Stop Skype before installing Apache.

The task I was trying to achieve was the installation of development versions of WordPress, Drupal, MediaWiki and Moodle, all of which would require a MySQL database. Trying to load the MySQL extension should have been a simple case of uncommenting the line in the php.ini and restarting the Apache service. With Vista, this was certainly not the case.

I set up a very simple page detailing the php configuration in an index.php file:

< ?php phpinfo(); ?>

This showed me the default configuration path of my php.ini and extensions directory, amongst a whole host of other information.

In both cases the paths were incorrect. First and foremost the configuration file path stated C:\Windows when in fact I had installed it in the root (C:\PHP5). So, although I was amending the php.ini file with the correct detail, Vista was using the default values. If there is no php.ini file in Windows, then you’ll continue banging your head against a brick wall.

The problems didn’t stop there. Moving the php.ini file to the Windows directory under Vista isn’t a simple copy and paste task. You need to be administrator. But Vista’s administrator priviledges are more pseudo than actual! In order to amend and save the php.ini file in the Windows directory, you must run Notepad as administrator and save the file as such. Voila! Everything then works. The phpinfo() function returned the correct installation detail and I could continue with the job I was meant to be doing.

PS. Thanks to Rob Douglas for his help.