Url Rewriting Using a Custom 404 ASPX Page

[Greg Collins [Microsoft MVP]]

I have done a bit of research of Url Rewriting, but as yet have been unsuccessful at getting it to work well, and there are issues around what file types are supported and how much code you want to write.

While working on a similar, though partially unrelated, issue, I came across a possible alternate method. Before I pursue this method in full, I wanted to get opinions of others as to any unforseen issues I might encounter.

The method is this:

In IIS, replace the default 404 error page with a custom ASPX page. Make sure you don't try to process any errors in the web.config.

When a 404 is hit, the custom ASPX page is called. Although to the user, the URL they typed in is still visible, the ASPX page is now loaded, and the QueryString contains the original url typed in.

So if I type in:

http://localhost/some_path

I get redirected to my custom ASPX page with a QueryString containing:

404;http://localhost:80/some_path

This query string is encoded--so it must be decoded first to be useful. Also note that it added the port ":80" to the host name.

In my custom ASPX page, I can now parse this url and do my Url Rewriting. If an unknown url is encountered, I pass to an error page.

To me this is much easier and more elegant than trying to do Url Rewriting in other ways.

So my questions are:
* Has anyone else tried this, or is currently using this?
* Are there unforseen issues I will encounter with this approach?

 

[George Ter-Saakov]

I would advice against doing that way.
It's actually really easy to get Url Rewriting working.
The hint is to rewrite URL back to original in your page.

A lot of things like search engines and robots rely on correct 404 code
thrown to know that page does not exist. Otherwise it would create infinite
website with the same page given out for any bad URLs. Plus analysing your
logs you will never know that some image is missing or link is broken on
your site.


Url rewriting simplified.

Global.asax
protected void Application_BeginRequest(Object sender, EventArgs e)

{

string sTmp;

HttpContext ctx = HttpContext.Current;

string sPath = ctx.Request.Path.ToLower();

ctx.Items["OriginalPath"] = sPath;

ctx.RewritePath("~/Default.aspx", "", "" );

}



Page default.aspx

private void Page_Load(object sender, System.EventArgs e)

{

//no caching

Response.CacheControl = "no-cache";

Response.Expires = -1;

HttpContext ctx = Context;

//rewrite URL back.

string sOriginalUrl = (String)ctx.Items["OriginalPath"];

string sOriginalQueryString = (String)ctx.Items["OriginalQueryString"];

if( sOriginalQueryString.Length > 0 )

sOriginalQueryString = sOriginalQueryString.Substring(1,
sOriginalQueryString.Length - 1);

ctx.RewritePath(sOriginalUrl, "", sOriginalQueryString);

}


George.


"Greg Collins [Microsoft MVP]" <gcollins_AT_msn_DOT_com> wrote in message
I have done a bit of research of Url Rewriting, but as yet have been
unsuccessful at getting it to work well, and there are issues around what
file types are supported and how much code you want to write.

While working on a similar, though partially unrelated, issue, I came across
a possible alternate method. Before I pursue this method in full, I wanted
to get opinions of others as to any unforseen issues I might encounter.

The method is this:

In IIS, replace the default 404 error page with a custom ASPX page. Make
sure you don't try to process any errors in the web.config.

When a 404 is hit, the custom ASPX page is called. Although to the user, the
URL they typed in is still visible, the ASPX page is now loaded, and the
QueryString contains the original url typed in.

So if I type in:

http://localhost/some_path

I get redirected to my custom ASPX page with a QueryString containing:

404;http://localhost:80/some_path

This query string is encoded--so it must be decoded first to be useful. Also
note that it added the port ":80" to the host name.

In my custom ASPX page, I can now parse this url and do my Url Rewriting. If
an unknown url is encountered, I pass to an error page.

To me this is much easier and more elegant than trying to do Url Rewriting
in other ways.

So my questions are:
* Has anyone else tried this, or is currently using this?
* Are there unforseen issues I will encounter with this approach?

 

[Greg Collins [Microsoft MVP]]

There's a couple of issues I have with traditional Url Rewriting:

1. I can never seem to get it to work. I can install other web apps that use it, and they work... but if I try to do it myself (using any of the examples I've seen online) it never works right. For example, your code--as I understand it, the url will be redirected to default.aspx no matter what page I enter in. But if I go to localhost/foo.aspx, then I just get a 404 error.

2. Without much more complex code and other adjustments (which I don't understand at this point), you cannot deal with rewriting non-ASP.NET pages and folders. So a path like: localhost/foo/bar (i.e. no filename) or localhost/foo.bar (non-ASP.NET file extension) won't work.

As per your other arguments:

I can agree that the server logs will no longer show a list of 404 errors to check up on. . . but I think that this can be resolved by logging them yourself to a database, since you'll have the original url available to you via the query string. This could also be used for broken links.

I tested with a missing image, and that seemed to work fine (in the browser).

As for search engines and robots. . . many sites take advantage of a custom 404 page so that they can have their site framing around the error message. So it seems like these issues should already have been resolved. The object here is to handle the rewrite where possible, and then if not, then drop to a default error page anyway.

I'm not convinced that this is the correct route to go, and I'd rather not go this route if I could actually get traditional Url Rewriting to work. . . but after several months of beating my head on this subject, this looks like a viable alternative. I can have any path (with or without a filename, whether or not ASP.NET handles the file extension) sent to an ASPX page where I can process the original URL and perform the rewriting or drop to an error page.

Although your arguments may be valid, I'm not yet convinced that they are bad enough to keep me from going this route.

Again, I'd much rather do traditional Url Rewriting. . . if I could ever get the thing to actually work! Maybe I've just got some wierd IIS problem. So far as I know, I've got a default install on a WinXP SP2 x64 machine. I can't seem to get it to work on my shared hosting server either. What drives me nuts the most is that, as I said earlier, I can install some web app that uses it (like community server or .text) and they seem to work just fine.

 

[Greg Collins [Microsoft MVP]]

Hi George (or anyone else),

Please feel free to bring up points against my arguments or thoughts... I want to understand all the consequences of this choice if I do choose to go this route.

I have heard of others using this method... so if those who are using it want to make comments, I'd appreciate that too.

I want to know what I'd be getting into!

Thanks.