Dr. Dobb's | Don't Like the URL? Change It

Don't Like the URL? Change It

Dynamic URL generation is handy for redirections. Here are some tips for best practices when using the RewritePath method

July 21, 2004
URL:http://www.drdobbs.com/dont-like-the-url-change-it/184405717

Don’t like the URL? Change It

Many web sites serve dynamically generated pages—pages that of course don’t yet exist at the time the application is deployed. For example, a web site that offers daily news will easily reference pages using a fixed URL and a progressive ID in the query string as follows: view.aspx?ID=1023.

However, similar-looking URLs don't necessarily all point to the same physical page, view.aspx. In some cases, the displayed URL is dynamically mapped to a real ASPX page with a different name.

Can you change the URL of the requested page on the fly? If you ask this question to a sample of ASP.NET developers, the average answer is Maybe, resulting from a balanced set of Yes and No.

Can you redirect the browser to show another page? If you ask this question, instead, the answer is a resounding Yes. In both cases, you change the URL of the originally requested page and actually force the browser to display a different page. However, URL change and classic redirect work in two radically different ways.

Changing the URL is an operation that is technically known as "URL rewriting. It takes place during the request processing and determines the overwriting of the originally requested URL. The ASP.NET HTTP context object has a method named RewritePath defined as follows:

public void RewritePath(string path)

The RewritePath method issues a call to an internal method defined by the HttpRequest object. This method accesses some private fields on the Request object and rewrites the target URL of the request. As a result, the displayed page is the one you set through RewritePath; the page shown in the address bar remains the originally requested one. The change of the final URL takes place on the server and, more importantly, within the context of the same call.

This fact represents the biggest difference with the classic browser redirection. When you call Response.Redirect, in fact, the browser receives an HTTP 302 status code and reiterates the request addressing a different URL.

All in all, RewritePath is more efficient than classic redirection because it doesn't require a second call to the browser. However, RewritePath should be used carefully and mainly from within the global.asax file. If you use RewritePath in the context of a postback event, you might experience some viewstate troubles. The following code shows how to rewrite the URL of a request to point to a different page:

protected void Application_BeginRequest(Object sender, EventArgs e)
{
   HttpContext context = HttpContext.Current;
   context.RewritePath("next.aspx");
}

The code is an excerpt from a web application's global.asax class file.

It is worth noticing that RewritePath is used internally to ASP.NET to implement the cookieless session feature. When cookieless sessions are configured, each request embodies a fake URL that includes the session ID. For the successful execution of the request, that fake URL must be replaced with a real one and possibly without performance penalties. That's where HttpContext.RewritePath fits in.

Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant based in Rome, Italy. Dino is a contributing editor to Windows Developer Network and MSDN Magazine, and the author of several books for Microsoft Press including Building Web Solutions with ASP.NET and ADO.NET and Applied XML Programming for .NET. Contact Dino at [email protected].