Repeat URL Rewrite (4): details and features of different levels of URL Rewrite

In previous articles, we have discussed several main aspects of URL Rewrite. In the last article of this series, we will discuss some details and features about different levels of URL Rewrite.

Theoretically, IIS-level URL Rewrite is written in C or C ++, which is better than ASP. NET-level URL Rewrite written in managed code. However, I think this gap is negligible in most cases. This performance is almost impossible to become a performance bottleneck. Therefore, the level of URL Rewrite is generally not determined by the performance requirements of your application. What level of URL Rewrite should be used? What should we pay attention to after using different levels of URL Rewrite? Here I will talk about my personal views.

Requirements on the URL Rewrite Function

Although the current URL Rewrite component can satisfy most applications in terms of functions, in some cases, we still need some special functions. For example, to implement URL Rewrite based on the domain name, it is not easy for the current URL Rewrite component. Commercial ISAPI Rewrite supports this currently. Unfortunately, open-source UrlRewriter. NET and IIRF are insufficient in this regard. They are all matched based on the request's path relative to the site. The requested domain name cannot be used as a matching condition. This requires us to extend the URL Rewrite component. For most. NET developers, hosting code is naturally the preferred choice for development. In this case, you may need to select the ASP. NET-level URL Rewrite component. However, many examples of extensions can be found on the Internet, whether it is ASP. NET-level UrlRewriter. NET or IIS-level IIRF.

But in fact, if we want to implement the above functions, we can also do it in two steps. First, we use IIRF for URL Rewrite at the IIS level, and then perform further URL Rewrite at the ASP. NET level. For example, we want to rewrite "http://jeffz.domain.com/articles#as #/articlelist.aspx? Owner = jeffz ", You can first let IIRF do the first URL Rewrite, the purpose is to Rewrite"/articles "to"/ArticleList. aspx ".

RewriteRule ^/Articles $/ArticleList. aspx [I, L, U]

In this way, the ASP. NET engine will directly receive a request for/ArticleList. aspx. Then in ASP. NET internal, we can make the second URL Rewrite (for convenience, I am still in Global. in asax, we recommend that you use an additional HttpModule in the project ).

Protected void Application_BeginRequest (object sender, EventArgs e)
{
HttpContext context = HttpContext. Current;
 
String host = context. Request. Url. Host;
String owner = host. Substring (0, host. IndexOf ('.'));
 
Context. RewritePath (context. Request. RawUrl + "? Owner = "+ owner );
}

After two URL rewrites, we have achieved the desired results (in actual projects, the above Code cannot be used directly, because we need to determine whether there is a Query String, etc ).

In addition, ASP.. NET-level URL Rewrite can only be performed in ASP. NET (apparently), If You Want To enable URL Rewrite to support other server technologies such as PHP and RoR, you can only use IIS-level URL Rewrite (or URL Rewrite function provided by other server technologies ).

Processing of special characters in a URL

Some special characters are not allowed to appear in the URL, or the meaning of the request is changed once it appears in the URL. For example, we need to perform URL Rewrite on the Search page and Rewrite "/Search/xxx" to "/Search. aspx? Xxx ", then you can obtain the keywords provided by the user based on the strings following the question mark. If UrlRewriter. NET is used, the following configuration will be used:

<Rewriter>
<Rewrite url = "^/Search/(. +) $" to = "~ /Search. aspx? $1 "processing =" stop "/>
</Rewriter>

In general, this URL Rewrite works normally. However, if you use "%" as the keyword, the situation will be different, because we will receive the following error page prompt:

This is because "%" is not allowed in the URL. You can go to various websites and try to request some paths such as "ABC % 25DEF" ("% 25" and "% "), "400 Bad Request" error can be found. However, it is legal to put "%" in the Query String-Right? Didn't we rewrite the keyword into the Query String? Why not? This is determined by the ASP. NET execution method.

Bad Request is in step 3, that is, it is determined during initialization. Our URL Rewrite occurs only in step 1 BeginRequest. When a request contains invalid characters, we do not have the opportunity to perform URL Rewrite.

So how can we solve this problem? In general, removing % on the client won't be too problematic (some sites do), but what if they have to be retained? Use Query String to pass parameters, or use IIS-level URL Rewrite. Take IIRF as an example:

RewriteRule ^/Search/(. +) $/Search. aspx? $1 [I, L, U]

After the request is sent to IIS (step 1), URL Rewrite occurs before you select the ISAPI to be handed over to (step 2. After URL Rewrite, the "%" has been transferred to the Query String. At this time, it is legal when it is handled by ASP. NET.

Error page configuration

Finally, we will discuss the configuration of the error page. For example, we usually configure a 404 error page for the application, so that users can view a specific page when accessing a nonexistent resource, rather than the default error prompt. However, different levels of URL Rewrite must be configured using different methods.

If ASP. NET-level URL Rewrite. In general, we have set Wildcard Mapping in IIS, so any request (including html, jpg, etc.) will be submitted to ASP.. NET Processing. If a nonexistent resource is requested, the 404 error will be sent by ASP. NET. Therefore, the 404 error page should be configured in web. config:

<CustomErrors mode = "On" defaultRedirect = "GenericErrorPage.htm">
<Error statusCode = "404" redirect = "FileNotFound.htm"/>
</CustomErrors>

If we use IIS-level Url Rewrite, we will not configure Wildcard Mapping. That is to say, the ASP. NET engine will start to work only when the address after Rewrite is aspx (or other requests should be handled by ASP. net isapi. If the user requests a resource that does not exist, the 404 error will be sent by IIS. At this time, the 404 error page should be configured in IIS:

 

Now, the URL Rewrite topic has been discussed. In actual development, there will certainly be a variety of different situations, but as long as you understand the key of the URL Rewrite method, you can think about it by running the program, I believe that it is generally difficult to solve problems.