No one may use the method in the previous article to perform URL Rewrite, because the component that provides URL Rewrite is already overwhelming.
The principle of the ASP. NET-level URL Rewrite component is very simple. In fact, it only listens to the BeginRequest event and determines the target URL according to the configuration. In my previous projects, I found that URLRewriter is frequently used as the URL Rewrite component. I think it may be because it is something provided by Microsoft.
To use URLRewriter, configure an HttpModule in web. config:
<HttpModules>
<Add name = "ModuleRewriter"
Type = "URLRewriter. ModuleRewriter, URLRewriter"/>
</HttpModules>
Then the configuration is completed. (Note: we strongly recommend that you use the configPath attribute to extract the configuration into additional files for ease of management ):
<ConfigSections>
<Section name = "RewriterConfig"
Type = "URLRewriter. Config. RewriterConfigSerializerSectionHandler, URLRewriter"/>
</ConfigSections>
<RewriterConfig>
<Rules>
<RewriterRule>
<LookFor> ~ /Tag/([\ w] +)/</LookFor>
<SendTo> ~ /Tags. aspx? Tag = $1 </SendTo>
</RewriterRule>
</Rules>
</RewriterConfig>
A regular expression is a very bad thing. It can be matched and captured. In the preceding example, we locate/tag/xxx that meets the LookFor condition to Tags. on the aspx page, xxx is used as the value of the Tag QueryString item, so that you can use HttpContext in the code. request. queryString ["Tag"] to obtain this value.
The URLRewriter feature is sufficient for most applications, but I always don't like it. But if I have to ask why I don't like it, it's hard for me to say it's ugly. This configuration method may be the only problem. When URL Rewriter is used, the configuration segment is often very long. Each configuration item requires four lines of code from <RewriterRule> to </RewriterRule>, for a small project, hundreds of rows of configuration are easily displayed. "This is too XML." I think, why not use XML Attribute? In this way, each configuration item can be shortened to one line.
Therefore, if I want to do URL Rewrite, I usually use the open source component UrlRewriter. NET produced by Intelligencia. Although this name is very similar to the previous one, it has far more functions than the former. This component is similar to URLRewriter in use (in fact, it seems that all URL Rewrite components are similar). All we need to do is configure:
<ConfigSections>
<Section name = "rewriter"
Type = "Intelligencia. UrlRewriter. Configuration. RewriterConfigurationSectionHandler,
Intelligencia. UrlRewriter "/>
</ConfigSections>
<Rewriter>
<Rewrite url = "^/User/(\ d +) $" to = "~ /User. aspx? Id = $1 "processing =" stop "/>
<Rewrite url = "^/User/(\ w +) $" to = "~ /User. aspx? Name = $1 "processing =" stop "/>
</Rewriter>
<System. web>
<HttpModules>
<Add name = "UrlRewriter"
Type = "Intelligencia. UrlRewriter. RewriterHttpModule,
Intelligencia. UrlRewriter "/>
</HttpModules>
</System. web>
We mainly look at the configuration item of the rewrite rule <rewriter/>. Unlike URLRewriter, UrlRewriter. NET uses each of my favorite rules as a node, which simplifies the rewrite rules for the entire project. But what does processing = "stop" mean? This will talk about UrlRewriter. NET's method for processing rewrite rules. When UrlRewriter. NET finds a matching rewrite rule, it will not stop, but will continue to look for other matching items. The final effect is that it can match the last rewrite rule of the current request. If we need UrlRewriter. NET to take effect after a match is found, we need to set the processing attribute to stop. For example, in the preceding configuration, if "/User/" is followed by a number, the User ID is used for search. Otherwise, the User name is used.
If UrlRewriter. NET is simple in configuration, it has no advantages over URLRewriter. However, the capabilities of UrlRewriter. NET are far more powerful than that. What we just used is actually one of the actions it provides. For the first time, it also provides many actions:
- If
- Unless
- Rewrite
- Redirect
- Setstatus
- Forbidden
- Gone
- Not-allowed
- Not-found
- Not-implemented
- Addheader
- Setcookie
- Setproperty
Action alone is not enough. UrlRewriter. NET also provides Condition, Transform, Default Document, Parser, Error Handler, Logger, and other functions, and can "Express" complex logic through Expression. This is still the configuration. It's just programming! Yes, you can use UrlRewriter. NET to express the request-reply logic through configuration, which undoubtedly brings us great convenience. Here, I cannot elaborate on all aspects of UrlRewriter. NET. If you are interested, you can refer to the Reference provided on its official website.
"I have to say this to components, but I still want to recommend another component here. In some special cases, UrlRewriter. NET cannot meet our requirements. Hmm? Can it be expanded by itself? That's right, but -- sell a token first. This issue is described in the last part of this series. UrlRewriter. NET provides URL Rewriter at the ASP. NET level. If you want to perform URL Rewrite at the IIS level, you must use other methods. ISAPI Rewrite is a famous component for URL Rewrite at the IIS level. Unfortunately, this is a commercial component and we need to buy it with a US knife. So here I recommend another open-source product: IIRF (Ionic's Isapi Rewrite Filter ).
Because URL Rewrite is performed on IIS, The IIRF configuration method is different from UrlRewriter. NET. If you want to use IIRF, you need to add IsapiRewrite4.dll to the ISAPI Filter list of the Web Site:
IIRF is configured through the INI file. Put IsapiRewrite4.ini and IsapiRewrite4.dll in the same directory:
RewriteRule ^/User/(\ d +) $/User. aspx? Id = $1 [I, L]
RewriteRule ^/User/(\ w +) $/User. aspx? Name = $1 [I, L]
The IIRF rewrite rule is "RewriteRule <url-pattern> <destination> [<modifiers>]". There is no limit on the number of spaces between each part, but it must be a space, it cannot be other blank characters such as Tab. The key to "url-pattern" and "destination" is modifier. There are many modifiers in IIRF. Here I will only introduce the two mentioned above. "I" indicates that uppercase and lowercase letters are irrelevant to the matching. "L" is used as the UrlRewriter. similar to processing = "stop" in.
Although IIRF is an open-source component, it is still powerful. Especially after combining RewriteCond (Rewrite Condition), you can implement complicated Rewrite rules. For example, the following configuration overwrites the root directory request of UserAgent containing Googlebot to a specific resource:
RewriteCond % {HTTP_USER_AGENT} ^ Googlebot .*
RewriteRule ^/$/Googlebot.html [L]
Finally, let's take a look at the difference between the two Rewrite components. Obviously, the biggest difference is that they are rewritten at different levels, the following two pictures describe how they rewrite the "/User/jeffz" request that originally expected "404 Resource Not Found" result to "/User/ name = jeffz.
First, UrlRewriter. net url Rewrite on the ASP. NET layer:
Next, the iirf url Rewrite at the IIS level:
With these two components, we believe that we no longer need anything else to implement URL Rewrite.