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

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.