Following on from our previous articles about server error codes and browser error codes, this articles looks at the redirect status codes. You can read details about all of the HTTP status codes on the W3.org website.
Whereas the 4xx and 5xx status codes were errors, a server initiates a redirect with a 3xx status code.
This type of redirect is employed when a page or image is available in more than one format.
For example, pages may be translated to multiple languages. On most sites that use multiple languages, you are asked to pick which language you prefer. However, it is possible to automatically redirect users based on the language their browser is set to prefer. Say for example, your browser sent the following in every request header:
Accept-Language: de
The web server can be set up to automatically redirect this user to the German section of the website (de is the code for German).
You can read a lot more about content negotiation and how to implement it in Apache at the Apache website.
This is the classic, most popular server redirect is use today.
It is used when a page has been moved permanently. For example if you change the URL of this page:
http://newwebmasters.net/article/servercodes.htm
To this:
http://newwebmasters.net/article/server-codes
Any request for the original URL can be redirected to the new URL with a 301 status code.
This type of redirect is commonly used in the search engine optimisation field. It prevents what is known as “canonical content” by redirecting multiple similar URLs to a single chosen URL.
For example the following URLs are all slightly different, but return the same content:
http://newwebmasters.net/
http://www.newwebmasters.net/
http://www.newwebmasters.net/index.php
http://newwebmasters.net/index.php
It is common practice to nominate one of those URLs are redirect the others to it with a 301 redirect.
This type of redirect will send the user to the specified page and give the instruction to use the new URL in the future. According to the HTTP specification, a user should not be automatically redirected via a 301 redirect if the request method is POST.
You can read more about how to implement the 301 redirect at Shimon Sandler’s website.
302 is very similar to a 301 redirect, except that it temporary whereas 301 is permamnent.
The user should be forwarded to the new URL, but should continue to request the old one in the future, as the redirection is just temporary. Again, like the 301 redirect, a user should not be automatically redirected via a 301 redirect if the request method is POST.
This type of redirect is designed for the POST request method. As mentioned in the 301 and 302 sections, a user should not be automatically redirected if the request method is POST.
The user can be automatically redirected to that page, but the form details submitted via POST should not be sent again.
In practice, this can be used to redirect users to a thank you page when a form has been submitted. This means that if the page is refreshed, the data is not submitted again. You can read a great tutorial on how to accomplish this in PHP at The Electric Toolbox.
This resposnse code is returned when checking if a cached component has been updated.
Your browser will cache scripts and images from websites you visit. When you visit the site again, the browser will try to save download time by using the components it always has cached. The last modification date of each component is sent to the web server. If the current version is newer, the browser discards the cached version and downloads the new version. If the cached version is the same as the version on the website, the server returns the 304 response code. This tells the web browser that downloading the resource again is unncessary.
This is a technique that is favourable to both webmasters and web surfers. It means that the same page components are not downloaded over and over again. This means faster loading websites for the surfer and lower bandwidth usage for the webmaster.
The file or page requested must be accessed via a specific proxy. The redirect sends the user to the appropriate proxy where the request can be repeated.
The W3C specification states that only “origin” servers should use this redirect. An origin server is the one that the original copy of a file resides on. This exludes cache servers.
This status code was used in a previous HTTP version and is no longer used.
The 307 redirect is the successor to the 302. It is only understood in HTTP 1.1 so is not commonly used.
A lot of web crawlers like Google advertise themselves as 1.0 compatible, whereas they can actually understand HTTP 1.1. As a result, it cannot be relied on that they understand 307 redirects.
The main use of a 307 redirect comes when using the POST request method. When a 302 redirect is received on a POST request, the request is redirected via the GET method. As you can imagine, this can totally destroy a request. When a 307 redirect is received on a POST request, it is redirected as a POST request and all the fields are left intact.
Whether you user the 307 redirect depends if you use the POST request method and whether you want to exclude user agents that can’t support HTTP 1.1. It’s a tricky tradeoff. You can read a detailed article comparing 301, 302 and 307 redirects here.
This is definitely a helpful article especially for new articles. I remember over a decade ago when I kept a notepad beside my computer with all these numbers and what they meant :p