IIS URL Rewriting vs URL Routing - asp.net

I was planning to use url routing for a Web Forms application. But, after reading some posts, I am not sure if it is an easy approach.
Is it better to use the URL Rewrite module for web forms? But, it is only for IIS7. Initially, there was some buzz that URL routing is totally decoupled from Asp.Net MVC and it could be used for web forms.
Would love to hear any suggestions..

This is the best article I found about this topic: IIS URL Rewriting and ASP.NET routing by Ruslan Yakushev.
IIS URL Rewriting
When a client makes a request to the Web server for a particular URL, the URL-rewriting component analyzes the requested URL and changes it to a different other URL on the same server. The URL-rewriting component runs very early in the request processing pipeline, so is able to modify the requested URL before the Web server makes a decision about which handler to use for processing the request.
ASP.NET Routing
ASP.NET routing is implemented as a managed-code module that plugs into the IIS request processing pipeline at the Resolve Cache stage (PostResolveRequestCache event) and at the Map Handler stage (PostMapRequestHandler). ASP.NET routing is configured to run for all requests made to the Web application.
Differences between URL rewriting and ASP.NET routing:
URL rewriting is used to manipulate URL paths before the request is handled by the Web server. The URL-rewriting module does not know anything about what handler will eventually process the rewritten URL. In addition, the actual request handler might not know that the URL has been rewritten.
ASP.NET routing is used to dispatch a request to a handler based on the requested URL path. As opposed to URL rewriting, the routing component knows about handlers and selects the handler that should generate a response for the requested URL. You can think of ASP.NET routing as an advanced handler-mapping mechanism.
In addition to these conceptual differences, there are some functional differences between IIS URL rewriting and ASP.NET routing:
The IIS URL-rewrite module can be used with any type of Web application, which includes ASP.NET, PHP, ASP, and static files. ASP.NET routing can be used only with .NET Framework-based Web applications.
The IIS URL-rewrite module works the same way regardless of whether integrated or classic IIS pipeline mode is used for the application pool. For ASP.NET routing, it is preferable to use integrated pipeline mode. ASP.NET routing can work in classic mode, but in that case the application URLs must include file extensions or the application must be configured to use "*" handler mapping in IIS.
The URL-rewrite module can make rewriting decisions based on domain names, HTTP headers, and server variables. By default, ASP.NET routing works only with URL paths and with the HTTP-Method header.
In addition to rewriting, the URL-rewrite module can perform HTTP redirection, issue custom status codes, and abort requests. ASP.NET routing does not perform those tasks.
The URL-rewrite module is not extensible in its current version. ASP.NET routing is fully extensible and customizable.

There's a great post here about the differences between the two from a member of the IIS team.
One caveat I would advise is that for WebForms, you need to be careful when using Routing. I've written a sample implementation of how you'd use routing with WebForms that addresses these concerns and hopefully helps answer your question.

Do you want formatted urls to be a factory for spawning pages?
or do you want to make the .aspx go away?
rewriting, is for making the .aspx go away, or just to tidy up the url.
Routing, is for looking at a request and determining which object should handle it. They sound similar, phil haack has a few good articles on the subject.
in iis6, isapiRewrite, is very good

I recently just wrote my own rewriting system to make the URLs on my sites look better. Basically, you're going to need to write your own IHttpModule and add it to your web.config to intercept incoming requests. You can then use the HttpContext.Current.RewritePath to change what you're pointing at.
You'll also want to configure your site to use the aspnet_isapi for everything.
You'll discover a lot of little problems along the way like trying to work with pages that use "tails" on them (like for PageMethods), or pathing of page elements and form postbacks, but you'll get through them.
If interested, I can post a link to the code and you can check it out. I've worked a lot of the problems out already so you can read through it as you go. I'm sure there are a lot of other people that have done this as well that might be good resources as well.

You may want to check out my answer to this question: ASP.NET - Building your own routing system. I include some good references to help build your own routing system with either using the url rewriting method or the new routing engine that you can use that came out of the ASP.NET MVC project.

The Dynamic Data project that is available with .Net 3.5 SP1 shows a good example of a url routing implementation.

For URL Rewriting on IIS, IIRF works in IIS5, 6, 7. Free. Easy. Fast. Open Source. Regular expression support.

Related

How is ASP.Net Routing accomplished given there is no obvious ISAPI mapping?

So Im reading that:
If a file name extension has not been mapped to ASP.NET, ASP.NET will
not receive the request. This is important to understand for
applications that use ASP.NET authentication. For example, because
.htm files are typically not mapped to ASP.NET, ASP.NET will not
perform authentication or authorization checks on requests for .htm
files. Therefore, even if a file contains only static content, if you
want ASP.NET to check authentication, create the file using a file
name extension mapped to ASP.NET, such as .aspx.
which I understand given the obvious .htm <> ASP.net ISAPI mapping in the webserver but what about routes in a route table? I'm not mapping those in the web server so how does the web server know to forward those URLs to ASP.Net??
So there are at least two pieces to this question:
The first is if you are running in IIS in classic mode versus integrated mode. Classic mode will make things behave like IIS 6, where everything is an ISAPI filter, including ASP.NET itself. Integrated mode takes advantage of the fact that IIS 7 was rewritten from the ground-up and now uses modules instead.
Secondly, the short answer of why IIS knows how to forward a URL to ASP.NET is the Routing Module in the IIS 7+ pipeline; ISAPI filters are now part of the ISAPI Filters Module.
For a visual description of how the IIS 7+ pipeline works from a Routing/URL-Rewriting perspective, read IIS URL Rewriting and ASP.NET Routing
So the good news is if you are very much attached to the ISAPI filter approach you can use the classic mode of IIS.

ASP.Net routing from website root

Say I have a website www.abc123.com. What would be the best way to determine when users attempt to access pages like www.abc123.com/section1 and www.abc123.com/otherStuff ?
I've done some research and found that Request.PathInfo works quite well when the user visits www.abc123.com/Default.aspx/section1 but it does not work without having the Default.aspx portion included in the URL.
Right now all I get are 404 errors when attempting this with the built in IIS server in VS2k8 and on a published website. I'm using ASP.Net 3.5 and IIS 6 if those things matter.
This works better in IIS7 since it routes all request through the ASP.NET pipeline (not just requests for ASP.NET resources).
In IIS6, I think your best bet would be to write an HTTPModule. I think IIS passes all requests (not just requests for ASP.NET resources) through the HTTPModule pipeline.
In IIS7, you can just use your applications Global.asax to hook into the Application_BeginRequest event.
I am running 3.5 on IIS 6 and there are a few things to do, but it can be done. A post already covers this, look at ASP.NET routing on IIS 6.

How to create a blog in ASP.NET and not ASP.NET MVC

I have created a blog application with ASP.NET MVC and MSSQL. I must say, i really enjoyed the process of creating an application with ASP.NET MVC. Clean URLS(with URL routing), No view States and so on.
BUT i was wondering how would this would have been done if i choose web-form style coding? will the aspx would be created in the fly as i create a article.(take this url for ex: http://weblogs.asp.net/scottgu/archive/2010/10/06/announcing-nupack-asp-net-mvc-3-beta-and-webmatrix-beta-2.aspx) though the URL is not clean but still makes sense. if yes then what about its corresponding cs file? if no how is the URL so clean?
Would be great if someone throw some light on how it is done in ASP.NET.
Thank you, Faraaz.
If your using .NET 4, you can make use of MapPageRoute to accomplish the clean URL's with regular Web Forms.
routes.MapPageRoute("MySuperCleanRoute", "some/clean/url", "~/ActualPage.aspx");
With the addition of MapPageRoute, you no longer have the feeling "I should use ASP.NET MVC because i want clean URL's".
Choose ASP.NET MVC if you like the pattern. If your used to Web Forms, use it - and use MapPageRoute to achieve clean URL's (or use a URL Rewriting module if <= .NET 4)
A blog in ASP .NET would have been done in much the same way. The idea is to use one file and URL rewriting. IIS7 has URL rewriting built in but for IIS6 you can use something like ISAPI_Rewrite to handle .htaccess style files (which is what Apache uses).
ASP .NET MVC handles all this for you in its routing but you can do it yourself using a URL rewriting tool. The difference is that for MVC, the application handles the rewriting but ISAPI_Rewrite, IIS Rewriting are done by the server. This can change a URL like http://mysite.com/something/other to http://mysite.com/file.asp?p1=something&p2=other.
The second link is only internal to the server (it doesn't actually change the URL in the user's address bar). In the case of a URL like on Scott's blog, you could store the 'announcing-nupack-asp...' bit in a database as part of the article row so your blog article page has something to look for. The files don't actually exist on the server but the rewriting passes all requests to an existing file with parameters.
Note that this technique is common for lots of different sites - not just blogs. Notice the Stack Overflow URL, Twitter URLs, etc.
MSDN has an old article on URL Rewriting in ASP .NET, along with some examples of filters you can use.
See IIS URL Rewrite Module
You can use the URL Rewriting that is in asp.net MVC with WebForms if you are using .Net Framework 3.5 SP1 (if you don't have access to .Net 4)
Here's an MSDN magazine article explaning...

How to rewrite a path using a custom HttpHandler

I'm writing a multi-tenant app that will receive requests like http://www.tenant1.com/content/images/logo.gif and http://www.anothertenant.com/content/images/logo.gif. I want the requests to actually map to the folder location /content/tenant1/images/logo.gif and /content/anothertenant/images/logo.gif
I'm using asp.net Mvc 2 so I'm sure there's probably a way to setup a route to handle this or a custom route handler? Any suggestions?
Thanks!
I created a custom HttpModule that taps into the BeginRequest event and then checks to see what the path is then calles Context.RewritePath
If I understand correctly, because it's URL rerouting, I don't know that MVC 2 routing handles this. You need IIS routing, which varies depending on the version you have. For IIS 6, there is an IIS resource toolkit that can handle these kinds of request, or there is helicontech.com's ISAPI_REWRITE or Ionic's rewriter at iirf.codeplex.com. IIS 7 has an MS add-on for url routing too, from what I hear, as a separate download.
These tools can actually redirect the URL in the ways you want, as MVC doesn't deal with the URL itself for the web site, but the pages within the URL request. the ISAPI_REWRITE and other tools actually redirect requests to hosts as you mentioned.

Using hosting companies "404 error behavior" to implement URL Routing

Many hosting companies let you define which page will be shown to the user if the user goes to a page that does not exist. If you define some .aspx page then it will execute and be shown.
My question is, why not use this for routing. since I can parse the users URL and then do a server.transfer to the page I want. I checked and there is no redirect sent to the client and the http headers are HTTP/1.1 200 OK.
So, is this a good idea for servers that don't have ASP.NET 3.5 SP1 or if you are not using MVC?
Thanks
You "can" do that, but why not just create an HttpModule and handle the routing there? That's how most of the URL rewriting systems work (in actuality, it's also how the MVC routing works since global.asax is just a pre-build HttpModule with a few extras).
The big thing with relying on that kind of server handling you describe is that you really aren't in control of it, and it is a hackish mechanism... by that I mean you are taking a function of the web server that has a specific purpose and design and laying a different meaning and function on top of it... which means you now have no built in handling for an actual 404 error. Plus, the mechanism you are contemplating is harder to adapt to your purpose than just using the other options available to you.
Unless you need something special from routing, you should consider using an existing routing component such as Mod-Rewrite or one of the dozen or so other popular URL rewriters that were built before the MVC routing engine was implemented and work fine in older versions of asp.net. There are also numerous tutorials on using HttpModules, HttpHandlers, and various other techniques to do routing in asp.net webform environments.

Resources