undefined = "not undefined anymore";
(function(arg1, arg2, undefined){

    // undefined is undefined in here

})(value1, value2);

This creates a locally scoped variable undefined that has the value of undefined (more on the type, value and variable undefined here). This way your code does not rely on the “fragile” global undefined and is more robust.
More info:

• Undefined – Mozilla Developer Network
• New in JavaScript 1.8.5
• Understanding JavaScript’s ‘undefined’

dict = {'key':'value'}
if dict.has_key('key'):
    print dict['key']
else:
    print 'no such key'

The .get() method will do all that for you:

print dict.get('key', 'no such key') 

This is far more compact and expressive. Ref: Python Mapping Types – dictionary

Earlier this month (on 10/10/10 in fact) Canonical added a brand new member to the mighty Ubuntu family – 10.10 Maverick Meerkat. If you still have not switched to it, I strongly encourage you to do it There are some great improvements and added features. And in case you have already switched, and you are just looking for some new wallpapers to bring some Ubuntu harmony to your desktop, well, you’ve stumbled upon the right URI! Here is a small, but very clean and beautiful collection of fresh desktop eye candy. The first 5 are kindly created by jbaer.

Maverick Beginning

Maverick Blush

Maverick Dunes

Maverick Metro

Maverick 10.10

Ubuntu 3D name

Ubuntu 3D Logo

Ubuntu Dual-monitor default wallpaper

Everyone in the vast community of “web people” these days seems to be extremely excited about CSS3. Along with “HTML5″, “CSS3″ has become one of the big buzz words on the web. Browser leaders like Firefox, Chrome, Safari and Opera started adoption of CSS3 before the final specification has been released. This has made it possible for developers to tap into new style properties, selectors and even transformations. CSS3 is like the new playground that all children have been waiting for and now everyone wants to play. Everyone is excited, but is it for the right reasons?

The CSS3 “Image-less” Hype

Every day, while browsing through tweets and blogs, I find fascinated people spreading the word about “iPhone icons with just CSS3 and no images“, “CSS3 only monster drawing“, “CSS3 iPad no images“, “CSS3 pie chart“, “3D page layout with CSS3“, “CSS3 Animated under sea world“, “3D animated Super Mario, CSS3, no images” and many many more. Recently Smashing Magazine even announced a CSS3 design competition and if you are interested in the results, please do check them out.

All these examples are great little experiments, but they do not quite show what CSS3 is all about. Somehow they seem to define as a great accomplishment the ability to create a picture (even an animated one) on the screen without a single image using just CSS as a drawing and animating tool.

That, however, is completely off target. CSS is not a drawing tool and setting the background property to a bunch of meaningless div-s and arranging them together to form an image does not show you the strength of CSS3. On the contrary, it throws web design way back to square one when content and presentation were scrambled together in a hodgepodge of horrid mark-up.

The whole “no images, CSS only” concept might be in danger of going too far. CSS3 is not here to replace images on the web (I am not talking about content images, but styling images), not at all. It is here to replace old techniques of achieving round corners, shadows and gradients using images and poor mark-up. If someone needs a more complex graphic, then he/she should use an image and not try to “draw” one using CSS backgrounds and a bunch of DOM elements. Leave mark-up alone, its duties end when design starts. Besides, HTML5 will give us the canvas where we can actually draw.

Note: I realise that some of the aforementioned CSS3 examples are created probably just for fun and deprived of any serious meaning. However, they create the wrong hype around CSS3 and they fail to show its true advantages.

CSS3 is about HTML semantics

The mark-up, the mark-up, the mark-up! It is all about the mark-up. CSS3′s ultimate goal and reason for being is not to change the face of the web, but to smarten it. Despite all efforts and preachings of web gurus about web standards and semantic web, up until now “sleek Web 2.0″ design with shadows and rounded corners could not be possible without staining the semantics of the mark-up with meaningless div-s, spans-s etc.

Some say Web 2.0 was a revolution. Although that might very well be true, I reckon Web 2.0 has been mediocre in terms of semantics, accessibility and cross-browser/cross-device compatibility, inefficient in terms of performance and somewhat good looking but in a very very artificial way. CSS3 is loaded with the potential to facilitate the emergence of the next iteration of the Web – fast, smart, accessible, ubiquitous and beautiful.

CSS3 is about speed

If CSS3 is about semantics, it is about performance as well. That is because achieving ultimate semantic mark-up means using the minimum necessary amount of DOM elements. And since the DOM is slow, reducing its elements will inevitably boost performance.

Another speed enhancing consequence of CSS3 is the reduced number of HTTP requests due to the smaller amount of images that are needed for styling (the upper-mentioned shadows, rounded corners, gradients, etc.) Less HTTP requests means smaller load on servers, more efficient bandwidth usage and ultimately faster websites.

CSS3 is about subtleties

Design should always obey content. Design is there to make content easier to spot, read and digest. Beyond that there is just a thin strip allowing design to solely serve creativity very subtly. The true beauty of design resides within this subtlety. Small and “quiet” visual effects like slight shadows, gradients, soft round corners and very light transitions can really change the look and feel of a page.

Up until now achieving those subtle design effects could not be done without getting in the way of content semantics. And it’s those subtleties that reveal the true potency of CSS3. CSS3 will give us a chance to clean the web and make it beautiful “inside”. Now that’s what I find exciting.

There are numerous examples and reasons why one would use hidden input fields in a form, but mainly they all boil down to the following – the server sends out data it wants back unchanged.

Figure 1. General case of hidden input data round trip

The name “hidden”, however, is very misleading because it creates a false sense of security. Nothing on the user machine can really be hidden and therefore virtually anything can be changed. That is why the upper definition says “not intended to be examined” and not “cannot be examined”.

Bottom line: Hidden input fields are neither hidden, nor unchangeable. Once data has left the realm of the web server, it should be treated as possibly contaminated and potentially dangerous. Hidden fields are no exception.

How to make hidden input fields truly hidden and unchangeable

The simple answer is – you can’t. What you can do, however, is make the hidden input’s value unreadable and check to see if the value remained unchanged after the round trip to the user machine. Although web security is never trivial and requires careful assessment of the possible vulnerabilities , this particular task has a relatively trivial solution.

Encryption and hashing

When it comes to hiding (or protecting) information, we essentially talk about encryption. Encryption takes a piece of readable information and using a key and a special algorithm turns this information into a scrambled unreadable string. Later on, using an appropriate (not necessarily the same) key and algorithm, the scrambled string can be turned back into the original readable message (decryption).

Hashing, also referred to as one-way-encryption, employs algorithms that turn the input into a unique value (digest) and make reversion back to the original input impossible (collisions are theoretically possible but computationally infeasible; that depends on the hashing algorithm and technique used, but that is a whole other discussion). The fact that no two inputs would produce the same digest makes hashing great for verifying data.

So, encryption makes data safe to travel and hashing ensures the data arrives unchanged. All it takes is for both the origin and destination to have the appropriate key and to know the encryption and hashing algorithms. That is what is needed to tackle the security issues with hidden input fields.

Figure 2. General case of encryption-decryption and hashing correspondence

Applying encryption and hashing to hidden input fields

If we need to translate Figure 2 to our specific case, the web server is both the origin and destination of the data, and the user machine is the untrusted medium that can compromise the data.

Figure 3. Applying encryption and hashing to hidden input

As Figure 3 indicates the necessary steps needed to be taken to implement the solution are as follows:

• Hash the original value
• Encrypt the original value
• Send the encrypted value along with the hash digest
• Upon receiving back the data, decrypt the encryption, hash the result and compare it to the received hash digest to ensure the value remained unchanged

All that is left is the implementation itself…

Implementing the solution in PHP

PHP provides functions and extensions that deal with encryption and hashing. There are many ways one can implement encryption and hashing – numerous algorithms and techniques. This is the time to say that there is not a right or wrong way of doing things. It all depends on the level of security one strives to achieve. The field of cryptography and security is pretty dynamic and one should always investigate current developments and recommendations.

That being said, the proposed PHP solution should not be taken as the only possible one nor the best (it certainly is not, although it is quite decent). It is just for practical illustration of the upper-described concept.

Encryption-decryption in PHP using MCRYPT extension

The MCRYPT extension provides an interface to the mcrypt library, which supports a wide variety of block algorithms including DES, TripleDES, Blowfish and many more. This example will make use of the Blowfish cipher (64-bit block size) with a 128 bit key. MCRYPT provides a function that implements the supported list of ciphers – mcrypt_encrypt(). Here is the function description and parameters:

The list of parameters that we are going to use is as follows:

• $cipher – this takes one of the predefined constants MCRYPT_ciphername, in our case MCRYPT_BLOWFISH
• $key – in order to generate a 128-bit key, we can use any string and hash it with the 128-bit md5 function – md5(‘ESP_guitars_rock’). This would produce the following key: 6cf50d50aa1174778a0c24fffa558593
• $data – this the message/value that needs to be encrypted, in our case we will encrypt the super secret message – ‘Bing is actually famous, check in Google’
• $mode – one of the MCRYPT_MODE_modename constants, in our case MCRYPT_MODE_CFB
• $iv – initialisation vector that needs to be the same size as the block size of the cipher. Blowfish has a 64-bit block size. However, we do not have to remember that. We can use the mcrypt_get_iv_size() function to get the necessary size.

This is how the final implementation of mcrypt_encrypt() looks like:

Note: We need to encode the output of the mcrypt_encrypt() function with base64_encode(). This encodes the binary data with MIME base64 so it survives transportation when it travels from and to the web server. Otherwise, the data might (most probably will) arrive corrupted and this would break the decryption process. When the data arrives back at the server base64_decode() is used to decode the data back to the original output of mcrypt_encrypt().

The decryption process is carried out in a similar way, this time using the mcrypt_decrypt() function, which takes the same parameters as mcrypt_encrypt(). Note that the $encrypted_value has to be decoded first with base64_decode().

Hashing in PHP

PHP provides several hashing options, most common (and strongest) of which are md5() and sha1(). The former generates a 128-bit hash, whereas the latter returns a 160-bit hash. Although that might sound like a lot of bits, modern hardware can generate hashes of this length pretty quickly (hundreds and even thousands per second). This way, using a dictionary (not only words, but also alpha-numeric combinations), an attacker can keep generating hashes until a collision appears – meaning he can find the original value that generated your hash.

One solution to this weakness is simply using stronger hashing functions (more bits) in order to make brute force collision detection computationally infeasible. However, those functions will also put computational pressure on web servers and ultimately make web pages slow. On the other hand, as of this moment md5() and sha1() are the strongest functions implemented for PHP.

Therefore, a technique can be applied to those functions that makes them stronger – adding salts. Salts are random bits of string with sufficient length that are added to the hash. This results in a different hash generated each time from the same input value. Consequently, we need to know the salt value later in order to regenerate the same hash for the data verification.

This might sound a bit confusing at first, however, looking at an example should clear the confusion. For our hashing process, we will use the 160-bit sha1() function. This is how a plain normal hashing in PHP looks like:

Now let’s fortify this hash mixing it with a salt:

Figure 4 illustrates the algorithm used for creating the $salt. The algorithm uses the functions rand(), uniqid(), md5() and substr() to create a unique salt with length of 10. The illustration breaks the process into steps for better understanding of what is going on.

Figure 4. Creating a salt for hashing

Then comes the algorithm for hashing – we concatenate the salt to the original string, create a 160-bit hash, take 10 characters of the resulting string (just so the final hash is not too long) and attach the salt to the beginning. This way, later we can extract the value of the salt again knowing it is the first 10 characters.

Figure 5. Creating a hash with salts

Mixing it all together with hidden input fields

Now it is time to put everything together. The starting point is just a very simple mark-up page with a form containing one hidden field and a submit button. We will create two php documents. One is form.php where the encryption and the initial hashing will take place. The other is process_form.php where the form will post to and where decryption and verification will take place.

This is the mark-up we are going to start with:

Below is the modified version (document form.php) with added encryption and hashing. Note that there is an additional hidden field just for the hashed value. That is not necessary and is done just for clarity. The hashed value can be concatenated to the encrypted value.

And finally, below is the processing script (document process_form.php). First a check is made to make sure that the form has been posted properly. Then the encrypted value is decrypted using the same $key and $iv. Then the $salt is extracted from the posted hashed value (the first 10 characters). A new hash is created from the decrypted value and the salt using the same algorithm. Finally this new hash is compared to the original one posted by the form. If they match, this means the data came back valid and unchanged and further processing can continue (in this case just print). Otherwise, something went wrong and the data was corrupted, either intentionally or not.

Final words

How far should a developer go with security depends on the situation at hand. Sometimes encryption of hidden fields may not be necessary – in case the developer does not care if the user will see the value or not. In any case, however, I strongly believe that hash verification should always be implemented. This would give the developer a piece of mind that data came back to the server unchanged and that no discrepancies would break his/her application.

Resources and further readings

• Official PHP page
• Bret Mulvey, Hash Functions. Accessed July 6, 2010
• Snyder, C. and Southwell, M. (2005). Pro PHP Security, New York, APRESS
• Icons used in the illustrations courtesy of – PixelMixer, Oliver Scholtz and Evelardo.com

Architectural Patterns operate on a higher level and define the entire system structure and work-flows. An example of an architectural pattern, extremely common in web development, is the Model-View-Controller pattern.

Design Patterns dwell on a lower level and define the relationships and interactions of classes and objects. In object-oriented programming (OOP) design patterns help developers address challenges associated, for instance, with responsibility and polymorphism. Responsibility (single responsibility principle) deals with delegating specific tasks (responsibilities) to specific objects. It makes sure that there is exactly one object dealing with a given task. Polymorphism makes it possible to create a uniform interface to handle values of different data types. In other words, you can alter a given class without changing the rest of the code that interacts with it. This results in more flexible and portable applications with loosen interdependencies.

Two of the most commonly used design patterns with PHP are the Singleton and Factory patterns. The Singleton pattern is a responsibility pattern and the Factory pattern facilitates implementing polymorphism.

The Singleton Pattern in PHP

The Singleton pattern ensures that at any given time there will be just one instance of a given class within the application. It accomplishes that by limiting the object instantiation to just a single point within the object itself. In addition, it restricts its public constructor (by declaring it private) and also blocks the possibility of object cloning (by creating a blank private __clone() method). Thus a singleton class can only initialise itself and no other class can create a new instance or a copy of the object. The singleton class can provide a reference to its only instance if another object requires it.

The following hypothetical situation and sample code illustrate the purpose of the Singleton pattern.

Imagine a class of 4 students. Each student has one responsibility when the class starts – he/she must shout out loud his/her name for their teacher to write down in his attendance book.

Below is some sample code that implements the described task in the conventional way. Two classes are declared – Teacher and Student. The Teacher class has one protected property $_name and two public methods – one is the constructor and the other one marks a student as present. There is also another property $_number_of_instances which is static and it is just for the sake of keeping track of how many instances of the class are created. The Student class has two properties – the name of the student and the student’s teacher. Naturally, it has one public constructor and a public method shoutYourName that needs to tell the teacher that the student is present.

One thing to notice is that every time a student object is instantiated, a brand new teacher object is created as well. In other words, every student in this class has his/her own teacher. Going further down the sample code, four students are created and then they inform their teacher(s) of their presence.

The code has the following output:

number of teachers:1
number of teachers:2
number of teachers:3
number of teachers:4
Kirk is present.
Lars is present.
Robert is present.
Jason is present.

The picture below illustrates the result of the conventional implementation. It creates multiple unnecessary objects that do the same thing essentially (moreover, it does not recreate the described plot of 4 students and only 1 teacher).

This is where the Singleton pattern comes into play. Below you can see a rewrite of the sample code. The Teacher class has been modified to become a, what is called, Singleton class. The modifications are as follows:

• Another static property has been added $_instance that will hold the self-created instance of the class.
• The constructor method was changed from public to private, restricting its access from the outside.
• A private method __clone() has been declared (doing nothing) to overwrite the PHP magic method __clone() in order to prevent object cloning
• A public static method getInstance() has been created. Its function is to check if there is already an instance of the class, if there is not it creates one, stores it in the static $_instance variable and finally returns it to whoever requested it.
• The Student object gets a reference to the teacher’s instance by calling the Teacher::getInstance method.

The code outputs the following:

number of teachers:1
Kirk is present.
Lars is present.
Robert is present.
Jason is present.

The picture below shows the result. As you can see, using the Singleton pattern, the Teacher class has been instantiated just once and then each Student object receives a reference of that instance.

Benefits of the Singleton Pattern

The Singleton pattern prevents memory duplication and, therefore, saves system resources. In addition, using the Singleton pattern, you can be sure that there is only one flow path for a certain task or data. This results in more controlled and secure application work flow as well as easier debugging and maintenance.

Further reading:

• Pro PHP: Patterns, Frameworks, Testing & More: Patterns, Frameworks, Testing and More
• PHP Design Patterns – when should they be used?

Speeding up and optimizing JavaScript

This is an excellent and extremely useful talk by Nicholas Zakas. He discusses JavaScript performance issues including scope management, data access, loops and the DOM. It’s the way these issues are approached that makes the difference between mere scripting and front-end engineering.

High Performance Websites and YSlow

Yahoo!’s Exceptional Performance Team has identified 14 best practices for making web pages faster. These best practices have proven to reduce response times of Yahoo! properties by 25-50%. In this talk Steve Souders goes in-depth on these best practices and the research behind them. He demonstrates YSlow and does some live performance analysis of popular web sites. Enjoy the talk (the audio is bad only during the first 3-4 mins)

Bezier curves, invented by french engineer Pierre Étienne Bézier, play a crucial role in the world of computer graphics (and not only). They are used to create smooth and infinitely scalable curves (and surfaces in 3D) in vector graphics. In addition, in computer animation they are used to describe and control the velocity of an object, so that a more natural motion can be achieved via ease-in and ease-out effects. Those are just some of the applications of Bezier curves.

Understanding how Bezier curves work, however, can be mind-boggling if you just stare at the neat little formula that is used to describe them:

I have always loved breaking complex things down into their smallest bits to bring out the beautiful simplicity hidden behind their intimidating mathematical facade. Do not get me wrong, I am not a math freak, not at all, but I always strive to actually see how things work. Therefore I dug a bit deeper into Bezier curves (just a bit) and I did some Actionscripting to create this simple interactive visualization that shows the mechanical beauty of the scary formula:

The maximum possible order number you can enter is 9, because higher degree curves get really expensive in terms of calculation. If you crank up the value to 9 you can notice how sluggish the application becomes (this of course depends on your machine’s characteristics). In general, the most commonly used Bezier curves in computer graphics are of order 2 and 3 (quadratic and cubic curves). If a more complex shape is required, Bezier curves are patched together forming paths.

The smoothness of the curve depends on how close the approximation is to the continuous interval [0,1]. This reflects the number of calculated points from the curve that get connected with a line segment. The more the points, the bigger their density and the smoother the raster curve.

The Actionscript behind the application

Those of you curious to see the Actionscript behind the application can check out the Bezier Actionscript class I wrote here.

In a dynamic web application the database is the heart that keeps it alive pumping data in and out. The database is the very core that holds the essence of that application – the data in its basic form. That core is then wrapped with the application layer that holds all logic and operations that seal that data and control its communication with the outer world. A web application is like a living cell and if something malignant enters its nucleus, it dies or becomes harmful.
The web forms are a peculiar HTML element because they provide a pathway for external input leading to the data core of the web application. Therefore, what happens to that external input along the way before it enters the database is of crucial importance. The input must be scanned and cleaned with great precision before it becomes pure data and “qualifies” for database insertion. This is what makes data pure:

• Its data type and format matches the one the database expects
• Its length does not exceed the limit the database field can hold
• Escape sequences and special characters should be filtered to prevent SQL injections which can be detrimental to the data integrity
• Client-side scripts (JavaScript) should be recognized and filtered to prevent potential cross-site scripting (XSS)

This is where form validation kicks in. Form validation can be divided into two separate layers – client-side and server-side validation.

2. Client-side vs Server-side validation

Essentially both types of validation (client-side and server-side) are the very same thing, only the place where they are executed is different. Exactly that difference, however, defines the way we look at those two layers of validation. Client-side validation should be looked upon more like a usability enhancement that helps users with good intentions and bad typing. It is fast and users do not have to wait for a server response to understand they had input wrong data. JavaScript, however, can easily be disabled (presumably by users with bad intentions) thus removing the client-side layer of defense. Therefore, validation on the server is absolutely mandatory.

3. CodeignIter and server-side validation

Codeigniter is a great open-source PHP MVC framework that is loaded in terms of functionality and yet very light and excellently documented. Here you can find an excellent tutorial to get you started with CodeIgniter if it is completely new for you.
CodeIgniter comes with a built-in Form Validation Class and a Form Helper for fast and effective form building. This is how they can be used to quickly create a form and secure it on the server.

3.1 Setting up the View

The output in the browser generated by this is view can be seen in figure 1. As CSS styling is not in the agenda of this article, I am not going to comment on it. The CSS file can be found with all source files here.

Figure 1. The form generated by the view

3.2 Setting up the Controller

The first thing that needs to be done is setting up the appropriate controller object:

This is a pretty generic and simple CodeIgniter controller consisting of a constructor, index function and a send function that will process the form later on. One thing to notice is that the Form helper is loaded in the constructor. The index function is the default function executed when the controller is called (unless a different function is specified in the URL). All we do in the index function in this case is load the base URL of our application from the config file so it can be passed to the view via the $data array. The send function is going to be the function called in the action attribute of the form.
The send function loads the Form Validation class from the library and sets the rules for the corresponding form fields, specified by field name. The set_rules function takes three parameters:

• the field name as specified in your form
• A “human” name for that field in case you want to store that in a language file (more on this here)
• the set of rules that will apply for the corresponding field (the full list of rules can be found here)

If the validation fails (returns false), the controller returns the user to the form view again displaying the corresponding error messages.

Figure 2. The form returned after failed validation

4. jQuery validation

A great way to validate a form on the client machine with jQuery is via a plug-in called Validation. This is how the implementation of this plug-in looks like:

$(document).ready(function(){
    $("#myform").validate({
        rules: {
            name: {
                required:true,
                alphanumeric:true,
                maxlength: 45
            },
            email: {
                required: true,
                email: true,
                maxlength: 45
            }
        },
        messages: {
            name: {
                required:"It would be nice if I know who you are.",
                alphanumeric:"This field should not contain any funny characters",
                maxlength:"My dissertation is shorter than your name Give me a nickname."
            },
            email:  {
                required:"Please enter your email address.",
                email:"Oh, come on, this is not an email, you know that!",
                maxlength:"Maximum characters allowed – 45"
            }
        },
        invalidHandler:function(){
        }
        })
});//document ready close

This way the user does not have to wait a trip to the server and back to understand he/she has entered something wrong.

Figure 3. Errors if nothing is submitted.

Figure 4. Errors when the input is the wrong type

5. Source files

All source code files used in this example can be downloaded here.

There are several scenarios in which you as a developer might want to use URL rewriting and redirecting. You might need to:

• tidy up messy URLs which are the side effect of data intensive dynamic websites
• temporarily redirect incoming requests due to maintenance
• permanently redirect a certain request due to a changed location of a specific resource

The Apache web server offers us an elegant and very powerful solution to URL manipulation in the face of mod_rewrite module. It uses regular expressions to match any requested URL to the corresponding resource location on your server. It can be used on a per-server basis (via the httpd.conf) or on a per-directory basis (using .htaccess files). Per-server configuration is the recommended way (provided you have access to the server settings) mostly due to performance overhead when using .htaccess files (more on this here). However, when you do not have direct access to your server .htaccess do the trick pretty well. Let’s have a look at how mod_rewrite would tackle the upper mentioned three scenarios.

Messy URLs

Dynamic website architectures by default come with a price – long URL paths containing variables and values that the server-side scripts need to get what the user requested.

Messy URL example: www.somewebsite.com/guitars.php?type=electric&brand=esp&year=2010

That is what our web application needs to know to get to the needed information. However, that is something that the user does not care about and does not need to see or know. A much more visually appealing and easily remembered way of presenting the upper URL would be:

Tidy URL example: www.somewebsite.com/guitars/electric/esp/2010

There are no special characters, no equal signs and no file extensions. It is more logical to the human eye and certainly more understandable to search engines. Now let’s see how Apache’s mod_rewrite can be used to map the tidy URL the user inputs to the “messy” URL your web application needs. All you need to do is create a .htaccess file in your base directory (or wherever the application is installed) and put the following magic code in it:

The RewriteEngine directive controls the status of the rewriting engine – whether it’s ON or OFF. The RewriteRule uses three arguments divided by space:

• pattern – a regular expression to match the URL to be rewritten
• substitution – the location where the matched URL should be sent to
• flags – a set of options regarding the mod_rewrite operation (more on flags here)

In our case the pattern part consists of – ^([a-z]+)/([a-z]+)/([a-z]+)/([0-9]{4})$
Let’s break it down:

^ – this special character matches the beginning of the coming URL string. In our case this is www.somewebsite.com/
[a-z]+ – this regular expression matches any alphabetical string. In our case it matches guitars, electric, esp.
[0-9]{4} – this matches any combination of exactly 4 digits. We need this to match the year 2010.
Those regular expression segments are encapsulated with brackets (). This way they can be back-referenced in the substitution argument using $1, $2, $3, $4
$ – this indicates the end of the string

The substitution argument in our RewriteRule directive is – /$1.php?type=$2&brand=$3&year=$4. The variables $1, $2, $3, $4 are back-references to the pattern segments encapsulated with brackets and in our case they hold the values – guitars, electric, esp, 2010.

The flag argument we are using is [L]. The L flag (“L” for last) tells the rewrite engine to stop processing further if the current rule is matched. More on the different flags you can use with mod_rewrite can be found on the Apache mod_rewrite Flags page.

Temporary redirects due to maintenance

Whenever a website needs to undergo a major maintenance procedure that would hinder its normal workings and possibly throw errors if someone tries to access it, it is recommended that the website is put offline until maintenance is finished. Putting a website offline requires informing its visitors why they cannot access it or parts of it so they know they can come back later. This is important because some of those visitors may be search engine crawlers and unless they are told to come back later, they will record the 404 errors your previously indexed URLs throw at them.

The elements of a temporary maintenance redirect with Apache are as follows:

• Customized maintenance message page
• A .htaccess file with directives to redirect all incoming requests to the maintenance page and throw the necessary http status code

This is how the .htaccess might look like:

The RewriteCond directive defines a condition under which the rewrite should be executed and it should be placed before the RewriteRule line. In our case we use the RewriteCond with the server variable %{REMOTE_ADDR} which represents the IP address from which the website is accessed. Thus our condition tells Apache to redirect all requests except the ones coming from IP 11.111.11.111 (this could be the IP address of the machine that is used for testing the website). All requests coming from other IP addresses are redirected to our maintenance.php page.

Another important element of the redirect is the http status code that has to be sent with the maintenance message. That’s because the maintenance message is important for people, but the search engine crawlers understand the http status code in the header. Basically there are two options from the list of http status codes:

• 302 (moved temporarilly) – it basically tells the requestor that the server responds with a resource from a different location, but the original location should be kept for future access
• 503 (service unavailable) – this tells the user agent that the server is unavailable due to overload or maintenance and it should come back later

I personally prefer the 503 status code because it describes better the essence of the maintenance state. The http status code can be sent via the header php function in the maintenance.php file. Example:

Permanent redirect due to changed location

Although frequent change of resource locations is not recommended, sometimes it is a needed action. In that case one needs to make sure that the user’s bookmarks of the old location will still work, and also inform the user agent that the change is permanent via an appropriate http status code. That http code is 301 (moved permanently). It tells the user agent to update its records of the location of that specific resource.
Let’s say we want to redirect all requests for http://somewebsite.com/old.php?var=value to http://somewebsite.com/new.php?newvar=value. Then the .htaccess file in this case might look like this:

Again the RewriteCond directive is used, this time with the %{QUERY_STRING} variable which represents the GET arguments passed via the URL. This way any request to the /old.php?var=value will be redirected to /new.php?newvar=value. That, however, is a little stiff redirect since it will match only one specific variable name and value. We can make the redirect a lot more flexible using a short but powerful regular expression:

This RewriteCond will match any call to the old.php page regardless of the name and value of the arguments passed. It will also match a call to the old.php page without any GET arguments supplied.
The flag argument of the RewriteRule directive is [R=301]. The R flag (“R” for redirect) redirects the request with the supplied http status code.

Additional information:

• RewriteRule
• RewriteCond
• HTTP Status Codes
• Apache mod_rewrite Flags
• .htaccess files
• URL rewriting (www.yourhtmlsource.com)
• URL redirection (Wikipedia)