In "Virtual Directories: Targeting Local Directories and Network Shares," September 2002, InstantDoc ID 25930, I explain how you can use IIS's virtual-directory structure to selectively publish the content of physical directories without exposing their locations. In that article, I discuss the two most popular content sources: a local directory (i.e., a directory on the Web server) or a network share. A third option exists: redirection from one URL to another. Redirection can help you manage ever-changing content locations and directory structures. To prevent your clients' browsers from running into the infamous URL Not Found error, get to know the basics of HTTP redirection, as well as the range of available options that let you take advantage of IIS's capabilities.
The Basics of Redirection
IIS uses HTTP redirection features to notify clients of new locations for existing URLs. (The lengthy Internet Engineering Task Force—IETF—Request for Comments—RFC—2616 fully describes HTTP.) The structure is fairly simple: A Web client such as Microsoft Internet Explorer (IE) sends a request, and the Web server responds to that request. In its common form, such a request looks like the following:
METHOD URL HTTP_Version
HeaderName_1: Header_Value_1
...
HeaderName_N: Header_Value_N
BODY
The METHOD attribute (aka the verb) is an action that the client wants the server to perform. GET and POST are the most common methods. GET requests usually don't carry data to the server, although they can send a short amount (i.e., about 1KB) of text-based data in a query string. (A query string is the text string that follows the question mark in a URL. For example, the URL http://altoid/scripts/getparam.asp?fname=leon&lname=braginski contains the query string fname=leon&lname=braginski.) POST requests are made specifically to transfer data to the server. With the POST request, which various HTML forms use, the browser sends data to the server and requests the server to perform an action with that data (e.g., the client sends user data for the server to add to a database). The request's Content-Length header specifies the amount of data that the request can send. This article concentrates on the redirection of GET requests. (To learn about redirecting POST requests, see the Web-exclusive sidebar "Redirecting POST Requests," http://www.windowswebsolutions.com, InstantDoc ID 26302.)
The URL attribute is the HTTP request, which is a path (or an HTML document) relative to the Web server's home directory. For example, the URL for a request to http://altoid/scripts/myscript.asp would be /scripts/myscript.asp.
HTTP_Version is a string identifying the HTTP protocol version that the client is using. The server can reply by using the specified version or an earlier version. (The most recent available version is HTTP 1.1, but a server can reply with HTTP 1.0.) This attribute prevents the server from replying with a version that the browser can't handle.
HeaderName identifies the headers that the HTTP protocol uses to transfer auxiliary information (i.e., Header_Value in the sample request) from the client to the server and vice versa. Some headers are required for each HTTP request (e.g., the Host header for HTTP/1.1 requests, the Location header for 302 Redirect server replies), but many headers are optional. For example, browsers usually identify themselves with the optional User-Agent header. Each header in a request ends with a carriage return and line feed; the final header in a request terminates with a double carriage return and line feed.
The BODY attribute is mandatory for all POST method requests in which the Content-Length header isn't zero. The BODY can be any type of data. For an HTTP form request, the BODY might be a buffer of name=value pairs (e.g., Fname=Leon). When a client encounters the input type=file HTML tag (which is used to upload files to a server), the BODY might be a large binary buffer.
The following output shows a sample GET request. This request for a default document is from a browser using HTTP 1.1.
GET / HTTP/1.1
Host: altoid
After receiving a request, the Web server responds to the client. In its simplest form, a standard response looks like the following:
HTTP_Version STATUS_CODE REASON
HeaderName_1: Header_Value_1
...
HeaderName_N: Header_Value_N
BODY
STATUS_CODE is a numeric value that defines the status of the completed operation. The standard success reply is 200 OK, as in the following:
HTTP/1.1 200 OK
Connection: Close
Content-Length: 29
This is the body of the reply
The status code is the most important part of HTTP redirection. IIS natively supports two redirection status codes: 302 Redirect and 301 Move Permanently. You can redirect any virtual directory, physical directory, Web site (by redirecting the root directory), or file to a new target location. When you configure an IIS server to perform redirection, the server sends the 302 Redirect status code (unless you specify permanent redirection) and the Location header, which can represent an absolute URL (e.g., http://server/page.htm) or a relative URL (e.g., /newdir/page.htm). To show that a URL has moved permanently, the server can reply with the 301 Move Permanently status code. These status codes instruct the browser to send a new request to the URL that the Location header specifies. A simple redirection looks like the following:
302 Redirect
Location: http://newserver/newurl
Keep in mind that when you configure redirection, you increase the number of requests necessary to get to the specified URL. Browsers will always need to send at least two requests: one to the original URL and one to the new URL.