URL Rewriting

[Frankie]

I understand that with URL rewriting we can have a request come in for, say
Page1.aspx, and rewrite it so that PageA.aspx gets served up to the user.

My question (assuming the above is correct): What does the user see in the
browser after URL Rewriting? In the above case, when PageA is rendered to
the browser, will the address bar show "PageA.aspx" or would it show
"Page1.aspx" - the originally requested URL?

Thanks.

 

[Cowboy \(Gregory A. Beamer\)]

It depends on what you are doing.

If you are using a server.Transfer, they see the original URL. In general,
with an HttpHandler, it will also show the original URL. This is normal and
generally expected. If you want the new URL to show, you can program it that
way via a client side redirect, which can happen with Response.Redirect or
using certain other mechanisms that send out a redirect (generally a 300
level response).

 

[Frankie]

I'm not looking for the user to see/know the real page being rendered. What
I'm looking for is a level of indirection where the user never knows what
the "real" page is. Specifically, I'd like for the users to request a
particular page, say Page1.aspx, then on the server render PageA.aspx down
to the browser. All the while the user thinks they are looking at
Page1.aspx - which actually doesn't exist on the server - never has, never
will.

Apparently the default URL Rewriting behavior provided by
HttpApplication.Context.RewritePath yields this effect automatically.

Is this correct?

Thanks.

 

[Guest]

That's correct Frankie, Context.Rewritepath is the right class for that kind
of stuff.

For more info and examples check this:
http://weblogs.asp.net/scottgu/archive/2007/02/26/tip-trick-url-rewriting-with-asp-net.aspx

hth
Andreas

 

[Alan Silver]

That's correct Frankie, Context.Rewritepath is the right class for that
kind of stuff.

However, you don't need to use HttpModules to do this. I have absolutely
no idea why people make URL rewriting so complex. Almost every article I
have seen insists on using HttpModules, when they just aren't needed.

Suppose you want the user to enter (or click) an URL like
http://www.domain.com/Toaster.aspx, and have the server send back the
contents as if they had typed (or clicked)
http://www.domain.com/products.aspx?product=Toaster
then all you need to do is add the following to your Global.asax file...

void Application_BeginRequest(Object sender , EventArgs e) {
if (Request.Path == "Toaster.aspx") {
Context.RewritePath("/products.aspx?product=Toaster");
}
}

Note that this is air code, but it is basically right. You don't need an
HttpModule, just a bit of code in Global.asax

HTH

 

[Cowboy \(Gregory A. Beamer\)]

HttpHandlers can be really nice for this:
http://www.ftponline.com/vsm/2002_02/magazine/columns/qa/

 

[Cowboy \(Gregory A. Beamer\)]

The main reason for HttpModules is efficiency. You can do it much simpler,
which is fine for many sites. But, if you are doing this long term on a site
that needs to scale, you are better to intercept the call as high up the
stack as possible.

 

[Alan Silver]

The main reason for HttpModules is efficiency. You can do it much simpler,
which is fine for many sites. But, if you are doing this long term on a site
that needs to scale, you are better to intercept the call as high up the
stack as possible.

Is that why people use HttpModules? I never found a decent reason.

So what are the implication for doing it in Application_BeginRequest?
You imply it's less efficient, but why?

Thanks for the reply. Shame this point isn't made clearer. Everyone just
states that you have to use an HttpModule, without any explanation. At
least with your added info, an informed decision can be made.

Ta ra

 

[Frankie]

My motivation has more to do with driving the mapping logic from a database,
rather than hard-coding it into Global.asax (as per your earlier example).
Hard-coding is easier if the pages (or at least mappings) rarely change. But
in my case, I have admin pages whereby my customers can add entirely new
pages to their Web sites. Those pages never physically exist on disk, and
are instead defined in a database. When page requests come in, I have logic
that retrieves the "page" content from the database and injects it into a
placeholder within a "template aspx" page. That's an oversimplification but
gets you the basic idea. Anyway, my desire to do URL Rewriting comes from
the fact that users now request (perhaps via link on a page) these db-driven
"pages" with a long URL that looks something like
"TheirSite.com/SomeFolder/TheTemplate.aspx?pageID=398. The programming logic
then looks to the db and retrieves the page content for 398. Anyway I want
more "user friendly" URLs. So in the future the users will be able to
request, for example, "TheirSite.com/MeaningfulPageName.aspx". The URL
Rewriting logic will then map that friendly name to the real URL:
"TheirSite.com/SomeFolder/TheTemplate.aspx?pageID=398" URL.

-Frankie

 

[Alan Silver]

My motivation has more to do with driving the mapping logic from a database,
rather than hard-coding it into Global.asax (as per your earlier example).

<snip>

My example was deliberately simple to illustrate the point. In reality,
this would be done from a database. Nothing that you have suggested
couldn't be done just as easily in global.asax, so I don't see that your
motivation affects the issue.

Ta ra