Home>Network programming tutorial>ASP.NET tutorial

URL Rewrite(2): Using components for URL Rewrite

Author：Eve Cole Update Time：2009-06-29 23:46:44
The principle of the asp.net level URL Rewrite component is very simple. In fact, it just listens to the BeginRequest event and determines the target URL according to the configuration. In the projects I have been involved in before, I found that the frequency of using URLRewriter as the URL Rewrite component is very high. I think it may be because it is something provided by Microsoft.
If you want to use URLRewriter, the first natural step is to configure an HttpModule in web.config:

<httpModules>​​
< add
name = " ModuleRewriter "
type = " URLRewriter.ModuleRewriter, URLRewriter " />
</httpModules>​​

Then it’s time to configure (Note: It is strongly recommended to use the configPath attribute to extract the configuration into additional files for easier 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>​​

Regular expressions are an amazing thing, they can match and capture. In the above example, we relocate "/tag/xxx" that meets the LookFor conditions to the Tags.aspx page, and use xxx as the value of the Tag QueryString item, so that we can pass HttpContext.Request.QueryString in the code. ["Tag"] to get the value.
URLRewriter 's functionality is sufficient for most applications, but I've always disliked it. But if you have to ask me why I don't like it, I can't tell you the ugly Yinmao. Maybe it's just a problem with this configuration method. When using URL Rewriter, the configuration section is often very long. Each configuration item requires a total of 4 lines of code from <RewriterRule> to </RewriterRule>. A small-scale project can easily have hundreds of lines of configuration. "This is too XML", I thought, why not use XML Attribute? This reduces each configuration item to 1 line - but that's a digression.
So if I currently want to do URL Rewrite, I often use the open source component UrlRewriter.NET produced by Intelligencia . Although this name is very similar to the previous one, its functionality is far superior to the former one. This component is relatively close to URLRewriter in use (in fact, it seems that all URL Rewrite components are similar). All we have 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 >
Let's mainly look at the configuration item <rewriter /> of the rewrite rules. Different from URLRewriter, UrlRewriter.NET uses my favorite method of one node per rule, which makes the rewriting rules of the entire project much simpler. But what does processing="stop" mean? This is about the way UrlRewriter.NET handles rewriting rules. When UrlRewriter.NET finds a matching rewrite rule, it will not stop here, but will continue to look for other matches. The last rewrite rule that can match the current request will eventually take effect. If we need UrlRewriter.NET to take effect after finding a match, we need to set the processing attribute to stop. For example, in the above configuration, if "/User/" is followed by a number, the user ID will be used for search, otherwise the currently provided user name will be considered.
If UrlRewriter.NET is just simpler in configuration, it has no advantage over URLRewriter. But the capabilities of UrlRewriter.NET go far beyond that. What we just used is actually just one of the Actions it provides. In addition, 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 pass Expression to "represent" complex logic. This is not configuration, it is simply programming! That's right, UrlRewriter.NET can be used to express some request-reply logic through configuration, which undoubtedly brings us great convenience. It is impossible for me to explain all aspects of UrlRewriter.NET in detail here. Interested friends can get a closer look from the Reference provided by its official website. "If you have components like this, what more could you ask for?" However, I still want to recommend another component here. Because in some special cases, UrlRewriter.NET cannot meet our requirements. Um? Can't it expand on its own? That's right, but - let's get this out of the way first, and I will explain this issue in the last article 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 well-known component for URL Rewrite at the IIS level. Unfortunately, this is a commercial component and requires us to purchase it with US dollars. Therefore I recommend another open source product here: IIRF (Ionic's Isapi Rewrite Filter) .
Since URL Rewrite is performed at the IIS level, the configuration method of IIRF 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. IsapiRewrite4.ini and IsapiRewrite4.dll can be placed in the same directory:
RewriteRule ^/User/(d+)$ /User.aspx?id=$1 [I, L]
RewriteRule ^/User/(w+)$ /User.aspx?name=$1 [I, L]
The rewriting rule of IIRF is "RewriteRule <url-pattern> <destination> [<modifiers>]". There is no limit on the number of spaces between each part, but it must be a space, not other whitespace characters such as Tab. Needless to say, "url-pattern" and "destination", the key lies in the modifier. There are many modifiers for IIRF. Here I will only introduce the two used above. "I" means that the matching is case-independent. The function of "L" is similar to processing="stop" in UrlRewriter.NET. IIRF will take effect immediately when the match is found and will not continue to search.
Although IIRF is an open source component, its functions are still relatively powerful. Especially after combining RewriteCond (Rewrite Condition), more complex rewriting rules can be implemented. For example, the following configuration rewrites the root directory request containing the word Googlebot in the UserAgent 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 components Rewrite. Obviously, the biggest difference is that they are rewrites at different levels. The two schematic diagrams below describe how in the two cases they change the "/User/jeffz" that should have obtained the "404 Resource Not Found" result. Requesting rewrite to "/User/name=jeffz".
The first is URL Rewrite by UrlRewriter.NET at the ASP.NET level:
Next is IIRF’s URL Rewrite at the IIS level:

With these two components, I believe we no longer need anything else to implement URL Rewrite.
Related Articles