1 Introduction
URL redirection, also called URL forwarding and the very similar technique domain redirection also called domain forwarding are techniques on the World Wide Web for making a web page available under many URLs. HTTP allows servers to redirect a client request to a different location. Although, this will usually result in another network round trip, it has some useful applications:
    1).A web application may use redirection to navigate between parts of the application.
    2).If content has moved to a different URL or domain name, redirection can be used to avoid breaking old URLs or bookmarks.
    3).It is possible to convert a POST request to a GET request using redirection.
    4).A client can be directed to use its local cache for content that has not changed.
A server specifies redirection by returning a 3xx status code:

301
This indicates that the content now resides permanently at the location specified by the Location header and future requests should be directed to this location.
302
Same as 301, except that the new location is temporary and future requests should still be sent to the original location. Another feature of this status code is that if the original request was a POST the client will change to using a GET when it re-issues the request.
303
This status code was intended to be the only status code that caused a POST to be converted to a GET. However, most browsers treat a 302 like a 303.
304
Used in response to an If-Modified header to redirect a request to the browser's local cache.
305
A 305 response is used to specify that a request must be resubmitted through the HTTP proxy in the Location header

       This document is intended to help engineers understand how URL redirection works and how to implement URL redirection feature in WTOS. Besides, web logon mechanism will be introduced.
2 HTTP Headers
HTTP Headers are name/value pairs that appear in both request and response messages. The name of the header is separated from the value by a single colon. Syntax:
    message-header = field-name ":" [ field-value ]
For example, this line in a request message:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Provides a header called User-Agent whose value is Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1). The purpose of this particular header is to supply the web server with information about the type of browser making the request. A complete definition of this and other commonly encountered HTTP headers can be found in the HTTP 1.1 specifications.
2.1 HTTP Request Headers
HTTP clients use headers in the request message to identify themselves and control how content is returned. If you are using IE, you will have seen the following headers sent with the request in example:
Accept:*/*
This header indicates that the browser will accept all types of content.
Accept-Language: en-gb
The browser prefers British English content.
Accept-Encoding: gzip, deflate
The browser can handle gzip or deflate compressed content
Connection Keep-Alive
The browser is requesting the use of persistent TCP connections.
Host: www.wyse.com
HTTP/1.1 requires that the host name is supplied with every request so that multiple domains can be hosted on a single IP address.
Referer: http://www.wyse.com/
This is supplied by the browser to indicate if the current request was the result of a link from another web page. The server may use this information to gather usage statistics or to track which web sites have links to a page.
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
This identifies the browser is Internet Explorer Version 6 running on Windows XP.
2.2 HTTP Response Headers
HTTP servers use headers in the response message to specify how content is being returned and how it should be handled. If you are using IE, you will have seen the following headers returned with the p_w_picpath in example:
Cache-Control: no-cache
This header indicates whether the resource may be cached by the browser or any immediate caches. The value no-cache disables all caching. (See 5. Caching for more information)
Content-Length: 2748
This header contains the length in bytes of the resource (i.e. the gif p_w_picpath) that follows the headers.
Content-Type: p_w_picpath/gif
The content is in GIF format.
Date: Wed, 4 Oct 2004 12:00:00 GMT
This is the current date and time on the web server.
Expires: -1
The Expires header specifies when the content should be considered to be out of date. The value -1 indicates that the content expires immediately and would have to be re-requested before being displayed again.
Pragma: no-cache
The browser may be connecting to the server via HTTP/1.0 proxies or caches, that do not support the Cache-Control header. Setting Pragma to no-cache header prevents HTTP/1.0 caches from storing the content.
Server: Microsoft-IIS/6.0
The web server is an IIS 6 web server.
X-AspNet-Version: 2.0.50727
The web server is running ASP.NET 2.0
X-Powered-By: ASP.NET
The web server is running ASP.NET.
3 HTTP Method Messages
The HTTP method is supplied in the request line and specifies the operation that the client has requested. Internet Explorer will generally just use two methods to access and interact with web sites; GET for queries that can be safely repeated and POST for operations that may have side effects (e.g. ordering a book from an on-line store). For details of other HTTP methods refer to the HTTP 1.1 specification.
3.1 HTTP GET
The GET method is used to retrieve information from a specified URI and is assumed to be a safe, repeatable operation by browsers, caches and other HTTP aware components. This means that the operation must have no side effects and GET requests can be re-issued with worrying about the consequences. For example, displaying the balance of a bank account has no effect on the account and can be safely repeated. In fact, Internet Explorer will allow a user to refresh a page that resulted from a GET, without displaying any kind of warning. Other HTTP aware components such as proxies may automatically retry GET requests if they encounter a temporary network connection problem. One downside of GET requests is that they can only supply data in the form of parameters encoded in the URI (known as a Query String) or as cookies in the cookie request header. Therefore, GET cannot be unused for uploading files or other operations that require large amounts of data to be sent to the server.
As follows are GET method message and response messages in example:
http://www.wyse.com/
 
GET / HTTP/1.1
Host: www.wyse.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101012 Firefox/3.6.11 ( .NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
 
HTTP/1.1 200 OK
Date: Mon, 25 Oct 2010 06:43:08 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Content-Length: 26440
Content-Type: text/html
Set-Cookie: ASPSESSIONIDQABSTSDB=GODDEPICIJEMHEENNACJAPFF; path=/
Cache-Control: private
-------------------------------------------------------------------------------------------------------
3.2 HTTP POST
The POST method is used for operations that have side effects and cannot be safely repeated. For example, transferring money from one bank account to another has side effects and should not be repeated without explicit approval by the user. If you try to refresh a page in Internet Explorer that resulted from a POST, it displays the following message to warn you that there may be side effects:
 
For banking, and other transactional web applications, the best approach is to use a POST when the user submits a change and then use a 302 redirection to change to a GET that displays the result of the action (e.g. the new account balance). The user can then safely refresh the resulting page without being presented with the retry dialog shown above. The POST request message has a content body that is normally used to send parameters and data. Unlike using the request URI or cookies, there is no upper limit on the amount of data that can be sent and POST must be used if files or other variable length data has to be sent to the server. If you are working with Microsoft's Internet Information Server (IIS) (e.g. running the samples in this HTTP Gallery) you may notice that it returns two status codes in its response for a POST request. The first is 100 Continue to indicate that it has successfully received the POST request and the second is 200 OK after the request has been processed.
As follows are POST method message and response messages in example:
http://www.newsmth.net/bbslogin2.php
 
POST /bbslogin2.php HTTP/1.1
Host: www.newsmth.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.newsmth.net/indexpages/100618-100624-dd/
Content-Type: application/x-www-form-urlencoded
Content-Length: 33
id=test&passwd=password&x=18&y=12
 
HTTP/1.1 200 OK
Server: nginx/0.7.64
Date: Thu, 11 Nov 2010 04:18:13 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Cache-Control: no-store, no-cache, must-revalidate
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
Content-Encoding: gzip
--------------------------------------------------------------------------------------------------------------------
4. References
1.       [ RFC2616]: Hypertext Transfer Protocol -- HTTP/1.1
2.       http://en.wikipedia.org/wiki/URL_redirection
3.       [URL encoding]: http://www.blooberry.com/indexdot/html/topics/urlencoding.htm