Bad practice URL rewriting?

I’ve implemented a basic URL rewriting method based on HTTP 404 responses (page not found). I have a custom page that deciphers the fake URL and returns the correct response:

  1. non-existent page.htm is requested
  2. page.htm not found, so use custom 404 page
  3. custom page checks database for content for page.htm
  4. if found, display with a 200 OK status
  5. if not, display ‘page not found’ content with 404 status

I know there have been improvements in the way .net deals with URL rewriting, but this is a very simple method that suits my purposes perfectly. I just wondered if this was creating other problems, or may do so down track, that I haven’t considered, e.g. postback URLs, etc?

Actually, I like the modular nature of this solution best, easy to write as an HTTP module, register it in your web.config and then serve it from a different file / location (URL rewriting) or build the Response from scratch (custom server app)

Are you trying to do Routing in your ASP.NET site?

I’m not sure if this would apply to you but it is possible to use something called Smarty Routes in ASP.NET that may apply to what you are trying to do here.

There is another method for handling this as well using the URL Rewrite module in IIS. You can power this modules handling of requests/response from a database using a .NET provider that you register with the module so if a request came in like the one above it could look up “widget” find the data, return the page and then write the reponse url as even if that page didn’t actually exist.

you can learn more about the URL Rewrite module here,

hope that helps.

I don’t think there’s anything specifically wrong with this solution, so on the one hand I would make sure that you save the code to implement that solution. IMO, any project you work on is always a work in progress, but any phase at which everything works the way you want is a good place. So congratulations on getting this pretty sophisticated functionality up and running. :slight_smile:

On the other hand, it does first require running everything through the normal page handler and throwing an error, then catching the error and then… finally… getting around to doing the processing that you really want to do at the beginning rather than the end of the process. Again, it’s not that you’ve implemented anything incorrectly, it’s just not that efficient. The drawback, can be expressed this way, rather than building a web application you’ve built a really big error handler.

If you only want to retrieve the new URL from the DB, then simply find a new event to hook into. Rather than hooking into the error handler, I believe it’s better practice to create that code in the Application_BeginRequest event handler in your Global.asax file. :smashy:

On the other hand, I’ve been working on grabbing the entire application output from a DB. Depending on your situation you can skip rewriting and just dynamically generate the code, ie write a true server based application by creating a new HTTP Handler (.ashx file). This is an excellent architecture for an internationalized (i18n) site because its entirely transparent to swap languages in or out just by configuring the SQL selects for the desired language. Then you can register the handler in your web.config file.

This is cool, since your web.config allows you to specify specific folders where to use the new handler, which means that anything else can still be handled by the “normal” page handler. Depending on what you’re building this may be unnecessary, however, I suspect that it will be golden for you right now in the same way I’m using it. I’ve specified a particular subfolder of my application to use my new custom handler (.ashx file). That’s where I’m conducting all of my testing, without disrupting the current incarnation of my website. Pretty cool. I got a lot of my information and excellent resources posting at a different forum, you can check out the link if you’d like.