URL Rewrite（1）：IIS与ASP.NET

To fully understand the topics discussed later in the article, we must briefly understand the communication process between IIS and ASP.NET. What I'm explaining here is the IIS 6 server. As for IIS 5 and IIS 7, the former can be said to have been eliminated, while the "classic mode" of the latter is exactly the same as IIS 6, and the new "pipeline mode" actually talks about some concepts in ASP.NET and IIS. Deep integration. I believe that if you understand IIS 6 and ASP.NET, you will not have any problems in the integrated mode of IIS 7.

First, let's take a look at a simple schematic diagram, showing several main steps in the entire process of IIS from receiving the Request to returning the Response:

1. IIS receives the request.
2. The selector selects an ISAPI to handle the request based on the characteristics of the URL and the configuration in IIS - now it is natural to choose ASP.NET ISAPI.
3. The ASP.NET execution engine receives the request and initializes the data (such as building various objects).
4. Start triggering various Pipeline events, naturally starting with BeginRequest.
5. After multiple Pipeline events, ASP.NET selects a suitable Handler or HandlerFactory for the current request according to the configuration (except for special circumstances, such as directly outputting the results and ending the request in the previous event).
6. After being processed by the Handler, it goes through several Pipeline events and ends with EndRequest.
7. Output Response.

If you want to perform URL Rewrite in an ASP.NET application, you usually call the RewritePath method of HttpContext in the BeginRequest event to re-position the request to a target URL. For example, we can override the Application_BeginRequest method in Global.asax to achieve this:

The reason why Rewrite is performed in BeginRequest is because this event is the earliest triggered among all Pipeline events. After re-positioning at this time, some properties in the current HttpContext have also changed accordingly (such as HttpContext.Request.Path). In this way, the handler logic of the following Pipeline events will be affected. For example, when permissions need to be determined based on a directory, the "located" path will be used instead of the request received by ASP.NET. Naturally, the most "significant" change is the choice of Handler. For example, in the above example, we relocate the request to the "CustomerList.aspx" file, so that the ASP.NET engine will select the System.Web.UI corresponding to *.aspx. The PageHandlerFactory class handles requests.

public class Global : System.Web. HttpApplication
{
    protected void Application_BeginRequest( object sender, EventArgs e)
    {
        HttpContext context = HttpContext .Current;
 
        if (context.Request.Path.Equals( "/Customers" ,
            StringComparison .InvariantCultureIgnoreCase))
        {
            context.RewritePath( "~/CustomerList.aspx" );
        }
    }
}

As a final aside, there are two concepts that need to be distinguished, namely "ASP.NET Pipeline" and "Web Forms". Both are important models in ASP.NET, but the differences are still very big:

• ASP.NET Pipeline: As every request received by an ASP.NET application, it will be processed through this "pipeline". This is an ASP.NET level model.
• Web Forms: During the execution of ASP.NET Pipeline, one of the steps is to select a suitable Handler (or HandlerFactory) to handle the request. If it is an aspx page, ASP.NET will choose the System.Web.UI.PageHandlerFactory class, in which the WebForms model is finally formed .

In fact, the word "form" in the above sentence may not be accurate. Because Web Forms should probably be an execution engine and model that can be used independently, and System.Web.UI.PageHandlerFactory only uses this model. When we write ASP.NET applications, we can use this model in other places according to our needs. For example, in the article " Technique: Using User Control for HTML Generation ", we use ascx as a template in a Generic Handler to generate content.