URL rewriting Principle

(Organized from the Internet)

What happens when a request arrives at IIS:
When a request arrives at the IIS Web server, IIS checks the extension of the requested file to determine how to process the request. IIS can handle requests (such as HTML pages, images, and other static content) by itself, or route requests to ISAPI extensions. (ISAPI extension is an unmanaged compilation class that processes incoming Web requests. The task is to generate the content of the requested resource .)
For example, when a request is sent to the Info. asp Webpage, IIS routes the message to the asp. dll ISAPI extension. Then, the ISAPI extension loads the requested ASP page, executes the page, returns the rendered HTML to IIS, and IIS sends the HTML back to the request client. For ASP. NET pages, IIS routes the message to the aspnet_isapi.dll ISAPI extension. Then, the aspnet_isapi.dll ISAPI extension passes the processing operation to the managed ASP. NET auxiliary process, which processes the request and returns the HTML of the ASP. NET webpage.
You can customize IIS to specify the ing between the extension and ISAPI extension. Figure 1 shows the "Application configuration" dialog box of the Internet Information Services management tool. Note that extensions related to ASP. NET (. aspx, ascx, config, asmx, rem, cs, vb, and others) have been mapped to the aspnet_isapi.dll ISAPI extension.

(Figure 1)

What will happen when a request enters the ASP. NET engine?

Before ASP. NET, you need to use the ISAPI filter to rewrite the URL on the IIS Web server. Because the ASP. NET engine is very similar to IIS, you can use ASP. NET for URL rewriting. The similarities exist because the ASP. NET engine can implement the following functions:
• Events can be triggered when processing requests.
• Allows any number of HTTP modules to process events, which is similar to the ISAPI filter of IIS.
• Delegate the task of rendering the requested resource to the HTTP handler, which is similar to the ISAPI extension of IIS.
Like IIS, ASP. NET engine triggers an event within the validity period of the request. It sends a signal to indicate that the processing process changes from one state to another. For example, when the ASP. NET engine responds to a request for the first time, the BeginRequest event is triggered. Next, the AuthenticateRequest event is triggered, which appears when a user ID has been created. (In addition, there are a large number of other events: AuthorizeRequest, ResolveRequestCache and EndRequest. These events belong to the System. Web. HttpApplication class;
As discussed in the previous section, you can create an ISAPI filter to respond to events caused by IIS. Similarly, ASP. NET provides an HTTP module that responds to events triggered by the ASP. NET engine. You can configure ASP. NET Web applications to have multiple HTTP modules. For each request processed by the ASP. NET engine, each configured HTTP module is initialized and the event handler can be bound to the event triggered during request processing. Note that many built-in HTTP modules are used for each request. One of the built-in HTTP modules is FormsAuthenticationModule. This module first checks whether form authentication is used. If it is used, it checks whether the user has been authenticated. If not, the user is automatically redirected to the specified logon page.
As mentioned above, the request passed in through IIS will be finally sent to the ISAPI extension, and the task of ISAPI extension is to return the data of the specific request. For example, when requesting a traditional ASP Web page, IIS passes the request to the asp. dll ISAPI extension. The task of this extension is to return the HTML tag of the requested ASP page. The ASP. NET engine uses similar methods. After the HTTP module is initialized, the next task of the ASP. NET engine is to determine which HTTP handler should process the request.
All. the requests passed by the NET engine will eventually arrive at the HTTP handler or HTTP handler Factory (the HTTP handler factory only returns the HTTP handler instance and then uses the instance to process the requests ). The final HTTP handler returns a response, that is, the requested resource. This response will be sent back to IIS, and IIS will return the response to the requesting user.
ASP. NET includes many built-in HTTP processing programs. For example, PageHandlerFactory is used to render an ASP. NET webpage. WebServiceHandlerFactory is used to present the response SOAP envelope of ASP. NET Web services. TraceHandler will present the request's HTML tag to trace. axd.
Figure 2 describes how to handle requests to ASP. NET Resources. First, IIS receives the request and schedules the request to aspnet_isapi.dll. Next, the ASP. NET engine initializes the configured HTTP module. At last, the system calls the correct HTTP processing program, presents the requested resources, and returns the generated mark to IIS and the request client.

Figure 2.IIS and ASP. NET are processing requests

Create and register a custom HTTP module and HTTP handler

Creating a custom HTTP module and an HTTP handler is a relatively simple task, including creating a Managed class that implements the correct interface. The HTTP module must implement the System. Web. IHttpModule interface, while the HTTP processing program and the HTTP processing program factory must implement the System. Web. IHttpHandler interface and the System. Web. IHttpHandlerFactory interface respectively.
After creating a custom HTTP module or HTTP processing program, you must register it with the Web application. Register the HTTP module and HTTP handler for the entire Web server only on the machine. in the config file, simply add the HTTP module or HTTP handler for a specific Web application, including the Web. add several lines of XML to the config file.
In particular, to add the HTTP module to a Web application, add the following lines in the configuration/system. Web Section of web. config:
<HttpModules>
<Add/>
</HttpModules>
The type value provides the HTTP Module assembly and class name, and the name value provides a friendly name. You can use this friendly name in the Global. asax file to reference the HTTP module.
The <HttpHandlers>
<Add verb = "verb" path = "path"/>
</HttpHandlers>
As mentioned above, for each incoming request, the ASP. NET engine will determine which HTTP handler should be used to present the request. This decision is made based on the verb and path of the incoming request. The verb specifies the type (GET or POST) of the HTTP request, and the path specifies the location and file name of the requested file. Therefore, if you want the HTTP handler to process all requests (GET or POST) to files with the extension. scott, you can add the following lines in the Web. config file:
<HttpHandlers>
<Add verb = "*" path = "*. scott"/>
</HttpHandlers>
Type is the type of the HTTP handler.
Note: When registering an HTTP handler, it is important to ensure that the extension used by the HTTP handler has been mapped from IIS to the ASP. NET engine. That is to say, in this. in the scott example, if. if the scott extension is not mapped from IIS to the aspnet_isapi.dll ISAPI extension, then the file foo. scott's request will cause IIS to attempt to return the file foo. scott's content. To enable the HTTP handler to process this request, the. scott extension must be mapped to the ASP. NET engine. Then, the ASP. NET engine routes requests to the corresponding HTTP handler correctly.
Implement URL rewriting
You can use the ISAPI filter to rewrite the URL at the IIS Web server level, or use the HTTP module or HTTP handler to rewrite the URL at the ASP. NET level.
Using the RewritePath () method of the System. Web. HttpContext class, URL rewriting can be implemented at the ASP. NET level. The HttpContext class contains HTTP-specific information about a specific HTTP request. For each request received by the ASP. NET engine, an HttpContext instance is created for this request. This class has the following attributes: Request and Response, which provide access to incoming requests and outgoing responses; Application and Session, which provide access to applications and Session variables; User, provides information about users who have passed identity authentication and other related attributes.
Using Microsoft. NET Framework Version 1.0, the RewritePath () method can accept a single string as the new path to use. The RewritePath (string) method of the HttpContext class updates the Path and QueryString attributes of the Request object internally. In addition to RewritePath (string),. NET Framework 1.1 also includes another form of RewritePath (). This method can accept three string input parameters. This alternate form of overload requires not only setting the Path and QueryString attributes of the Request object, but also setting internal member variables, which are used to calculate the PhysicalPath, PathInfo, and FilePath attribute values of the Request object.
To implement URL rewriting in ASP. NET, you need to create an HTTP module or HTTP processing program to complete the following operations:
1. Check the requested path to determine whether the URL needs to be rewritten.
2. If you need to override the path, you can call the RewritePath () method to override the path.
For example, suppose our website contains every employee via/info/employee. aspx? Information that can be accessed by empID = employeeID. To enable the URL to be more segmented, we can decide to visit the employee page through the following address:/people/EmployeeName. aspx. This is an example of using URL rewriting. That is to say, when requesting the/people/ScottMitchell. aspx page, we need to rewrite this URL to use/info/employee. aspx? EmpID = 1001 page.
Use the HTTP module to perform URL rewriting
You can use the HTTP module or HTTP processing program to perform URL rewriting at the ASP. NET level. When using the HTTP module, you must determine the time point during the request validity period to check whether the URL needs to be rewritten. At first glance, this seems to be an option, but the decision will impact the application in an obvious and subtle way. Because the built-in ASP. net http module uses the properties of the Request object to execute tasks, it is very important to choose where to execute rewrite. (As described above, the rewrite path will change the attribute value of the Request object .) These closely related built-in HTTP modules and their bundled events are listed below:
 

HTTP Module
Event
Description
 
FormsAuthenticationModule
AuthenticateRequest
Determine whether the user has passed form authentication. If not, the user is automatically redirected to the specified logon page.
 
FileAuthorizationMoudle
AuthorizeRequest
When Windows authentication is used, this HTTP Module checks to ensure that the Microsoft Windows Account has sufficient permissions for the requested resource.
 
UrlAuthorizationModule
AuthorizeRequest
Check to ensure that the requester can access the specified URL. Use the <authorization> and <location> elements in the Web. config file to specify URL authorization.
 

 

As mentioned above, the BeginRequest event is triggered before AuthenticateRequest, and the latter is triggered before AuthenticateRequest.
A safe location for URL rewriting is in the BeginRequest event. That is to say, if the URL needs to be rewritten, this operation will be executed after any built-in HTTP module is run. This method has some defects when using form authentication. If you have used form authentication before, you will understand that when users access restricted resources, they will be automatically redirected to the specified Login Page. After successful logon, the user will be returned to the page on which they first attempted to access.
If URL rewriting is performed in the BeginRequest or AuthenticateRequest event, the logon page (after submission) redirects the user to the rewritten page. That is to say, if you type/people/ScottMitchell. aspx in the browser window, this address will be rewritten to/info/employee. aspx? EmpID = 1001. If you configure a Web application to use form authentication, when the user first accesses/people/ScottMitchell. aspx, the URL will first be rewritten to/info/employee. aspx? EmpID = 1001; next, FormsAuthenticationModule runs and redirects the user to the logon page (if needed ). However, after successful logon, the user will be sent to/info/employee. aspx? EmpID = 1001, because after FormsAuthenticationModule runs, this URL is the requested URL.
Similarly, when rewriting is performed in the BeginRequest or AuthenticateRequest event, UrlAuthorizationModule will see the rewritten URL. That is to say, if you use the <location> element in the Web. config file to specify authorization for a specific URL, you must reference the rewritten URL.
To solve these minor problems, you can decide to execute URL rewriting in the AuthorizeRequest event. This method solves some problems of URL Authorization and form authentication, but also creates a new problem: file authorization cannot work. When Windows authentication is used, FileAuthorizationModule checks to ensure that authenticated users have access to specific ASP. NET pages.
Assume that a group of users do not have Windows-level file access permissions for C: \ Inetput \ wwwroot \ info \ employee. aspx, and attempt to access/info/employee. aspx? EmpID = 1001, they will receive an authorization error message. However, if we move the URL rewriting to the AuthenticateRequest event, when the FileAuthorizationModule checks the security settings, the requested file is still considered as people/ScottMitchell. aspx because the URL must be overwritten. Therefore, the file authorization check will pass, allowing this user to view the rewritten URL/info/employee. aspx? EmpID = 1001 content.
Then, when should I rewrite the URL in the HTTP module? This depends on the authentication type to be used. If you do not want to use any authentication, it does not matter whether URL rewriting occurs in BeginRequest, AuthenticateRequest or AuthorizeRequest. If you want to use form authentication instead of Windows authentication, rewrite the URL and run it in the AuthorizeRequest event handler. Finally, if you want to use Windows authentication, arrange URL rewriting during the BeginRequest or AuthenticateRequest event.

Execute URL rewriting in the HTTP processing program
The URL can also be rewritten by the HTTP handler or the HTTP handler factory. As mentioned above, an HTTP handler is the class responsible for generating the content of a specific type of request; an HTTP handler factory is the class responsible for returning an HTTP handler instance, which can generate content of a specific type of request.
In this article, we will discuss how to create a URL rewrite HTTP handler factory for ASP. NET web pages. The HTTP handler factory must implement the IHttpHandlerFactory interface, which includes the GetHandler () method. After the corresponding HTTP module is initialized, the ASP. NET engine determines which HTTP handler or HTTP handler factory is called for the given request. If you want to call the HTTP processing factory, the ASP. NET engine will pass in the GetHandler () method of the HTTP processing factory of HttpContext for the Web request call and some other information. Then, the HTTP handler factory must return an object that implements IHttpHandler that can process requests.
To execute URL rewriting through an HTTP program, we can create an HTTP processing program factory. The GetHandler () method of the processing program factory will check the requested path, to determine whether to rewrite the URL. If needed, it can call the RewritePath () method of the incoming HttpContext object, as discussed earlier. Finally, the HTTP handler factory can return the HTTP handler returned by the GetCompiledPageInstance () method of the System. Web. UI. PageParser class. (This technology is the same as the technology used when the built-in ASP. NET webpage HTTP handler factory PageHandlerFactory works .)
Since all HTTP modules will be initialized before the custom HTTP handler factory is instantiated, When you overwrite the URL in the second half of the event, using the HTTP handler factory brings the same risk, that is, file authorization cannot work. Therefore, if you rely on Windows Authentication and file authorization, you may want to rewrite the URL using the HTTP module method.
In the next section, we will discuss how to build a reusable URL rewriting engine. After introducing the URL rewriting engine (which can be obtained by downloading the code in this article), we will introduce the actual usage of URL rewriting in the remaining two sections. First, we will discuss how to use the URL rewriting engine and introduce a simple URL rewriting example. Next, we will use the RegEx function of the rewrite engine to provide a truly "strikethrough" URL.

Build a URL rewriting Engine
To help describe how to implement URL rewriting in ASP. NET Web applications, I have created a URL rewriting engine. This rewrite engine provides the following features:
• The ASP. NET page developer who uses the URL rewriting engine can specify the rewrite rules in the Web. config file.
• Rewrite rules can use regular expressions to implement powerful rewrite rules.
• You can easily rewrite the URL to use the HTTP module or HTTP handler.
In this article, we will introduce the use of URL rewriting only for the HTTP module.
Specify configuration information for the URL rewriting Engine
Let's first introduce the structure of the rewrite rule in the Web. config file. First, you must specify in the Web. config file whether to use the HTTP module or HTTP processing program to rewrite the URL. In the download code, the Web. config file contains two comments:

<! --
<HttpModules>
<Add
Name = "ModuleRewriter"/>
</HttpModules>
-->

<! --
<HttpHandlers>
<Add verb = "*" path = "*. aspx"
Type = "URLRewriter. RewriterFactoryHandler, URLRewriter"/>
</HttpHandlers>
--> <! --
<HttpModules>
<Add
Name = "ModuleRewriter"/>
</HttpModules>
-->

<! --
<HttpHandlers>
<Add verb = "*" path = "*. aspx"
Type = "URLRewriter. RewriterFactoryHandler, URLRewriter"/>
</HttpHandlers>
-->
 

 

Comment out the In addition to specifying whether to use the HTTP module or the HTTP processing program for rewriting. the config File also contains a rewrite rule: the rewrite rule consists of two strings: The pattern to be searched in the requested URL; the pattern string to be replaced (if found ). In the Web. config file, this information is expressed in the following syntax:

<RewriterConfig>
<Rules>
<RewriterRule>
<LookFor> the mode to be searched </LookFor>
<SendTo> string used to replace the mode </SendTo>
</RewriterRule>
<RewriterRule>
<LookFor> the mode to be searched </LookFor>
<SendTo> string used to replace the mode </SendTo>
</RewriterRule>
...
</Rules>
</RewriterConfig>
 

 

Each rewrite rule is expressed by the <RewriterRule> element. The pattern to be searched is specified by the <LookFor> element, and the string to replace the pattern is entered in the <SentTo> element. These rewrite rules are calculated from start to end. If the URL matches a rule, the URL is overwritten and the search for the rewrite rule is terminated.
When specifying the mode in the <LookFor> element, note that you must use a regular expression to perform matching and string replacement. (Later, we will introduce a real example to illustrate how to use regular expressions to search for patterns .) Since the mode is a regular expression, ensure that any reserved characters in the escape regular expression are retained. (Some regular expressions retain the following characters :.,? , ^, $, And others. You can escape these characters by adding a backslash (for example, \.) to match the text periods .)

Use the HTTP module to perform URL rewriting
Creating an HTTP module is as simple as creating a class that can implement the IHttpModule interface. The IHttpModule interface defines two methods:
• Init (HttpApplication ). This method is triggered after the HTTP module is initialized. In this method, you will bind the event handler to the corresponding HttpApplication event.
• Dispose (). This method is called when the request is complete and has been sent back to IIS. You shall perform all final cleanup operations here.
To create an HTTP module for URL rewriting, I will start with creating an abstract base class BaseModuleRewriter. This class implements IHttpModule. In the Init () event, it binds the AuthorizeRequest event of HttpApplication to the BaseModuleRewriter_AuthorizeRequest method. The BaseModuleRewriter_AuthorizeRequest method calls the Rewrite () method of the requested Path and the HttpApplication object of the Init () method. The Rewrite () method is abstract. That is to say, in the BaseModuleRewriter class, the Rewrite () method does not have a method subject. Classes derived from BaseModuleRewriter must overwrite the method and provide the method subject.
With this base class, you only need to create a class derived from BaseModuleRewriter, which can overwrite Rewrite () and execute the URL rewriting logic there. The following shows the BaseModuleRewriter code.

Public abstract class BaseModuleRewriter: IHttpModule
{
Public virtual void Init (HttpApplication app)
{
// Warning! This code is not applicable to Windows Authentication!
// If Windows authentication is used,
// Change to app. BeginRequest.
App. AuthorizeRequest + = new
EventHandler (this. BaseModuleRewriter_AuthorizeRequest );
}

Public virtual void Dispose (){}

Protected virtual void BaseModuleRewriter_AuthorizeRequest (
Object sender, EventArgs e)
{
HttpApplication app = (HttpApplication) sender;
Rewrite (app. Request. Path, app );
}

Protected abstract void Rewrite (string requestedPath,
HttpApplication app );
}
Note that the BaseModuleRewriter class will execute URL rewriting in the AuthorizeRequest event. As mentioned above, if you use Windows Authentication in combination with file authorization, you need to make changes so that you can perform URL rewriting in the BeginRequest or AuthenticateRequest event.
The ModuleRewriter class extends the BaseModuleRewriter class and is responsible for performing actual URL rewriting. ModuleRewriter contains a single overwrite () method, as shown below:
Protected override void Rewrite (string requestedPath,
System. Web. HttpApplication app)
{
// Obtain configuration rules
RewriterRuleCollection rules =
RewriterConfiguration. GetConfig (). Rules;

// Traverse each rule...
For (int I = 0; I <rules. Count; I ++)
{
// Obtain the search mode and
// Parse the Url (convert to the corresponding directory)
String lookFor = "^" +
RewriterUtils. ResolveUrl (app. Context. Request. ApplicationPath,
Rules [I]. LookFor) + "$ ";

// Create a regex (note that IgnoreCase... has been set ...)
Regex re = new Regex (lookFor, RegexOptions. IgnoreCase );

// Check whether matching rules are found
If (re. IsMatch (requestedPath ))
{
// Matched rule found -- make necessary replacement
String sendToUrl =
RewriterUtils. ResolveUrl (app. Context. Request. ApplicationPath,
Re. Replace (requestedPath, rules [I]. SendTo ));

// Rewrite the URL
RewriterUtils. RewriteUrl (app. Context, sendToUrl );
Break; // exit the For Loop
}
}
}
 

 

The Rewrite () method starts from obtaining a set of Rewrite rules in the Web. config file. Then, it will traverse the rewrite rule and traverse one at a time. For each rule, it will obtain the LookFor attribute of the rule, the regular expression is used to determine whether matching rules are found in the requested URL.
If a matching rule is found, replace the regular expression in the requested path with the value of SendTo. Then, the replaced URL is passed to the RewriterUtils. RewriteUrl () method. RewriterUtils is a helper class that provides a pair of static methods used by the URL rewrite HTTP module and HTTP handler. The RewriterUrl () method only calls the RewriteUrl () method of the HttpContext object.
Note: You may have noticed that RewriterUtils. ResolveUrl () will be called during regular expression matching and replacement (). This helper method only replaces all ~ Instance.
The whole code of the URL rewriting engine can be downloaded with this article. We have introduced most closely related components, but there are some other components (for example, for Web. the XML format rewriting rules in the config file are deserialized to make it the class of the object), and the HTTP handler factory for URL rewriting.

Summary:
In this article, we discuss how to use the RewriteUrl () method of the HttpContext class to execute URL rewriting at the ASP. NET level. As we can see, RewriteUrl () updates the specific HttpContext's Request attribute, thus updating the requested file and path. The final result is that, from the user's perspective, they want to access a specific URL, but from the Web server side, the requested URL is another.
You can rewrite the URL in the HTTP module or HTTP processing program. This article describes how to use the HTTP module to perform rewriting.
Of course, if ASP. NET rewrite is executed, URL rewriting will only occur if the request has been successfully passed from IIS to the ASP. NET engine. In fact, this happens only when the user requests a page with the. aspx extension. However, if you want to enable the user to access a URL that does not actually exist, but want to rewrite it to the existing ASP.. NET page, you must create a virtual directory and Default. aspx page, or configure IIS to route all incoming requests to ASP.. NET engine.
From msdns