In previous articles we have talked about several main aspects of URL Rewrite. In the last article of this series, we will discuss some details and characteristics of different levels of URL Rewrite.
Theoretically, IIS-level URL Rewrite written in C or C++ has higher performance than ASP.NET-level URL Rewrite written in managed code. But I think the difference in this area is negligible in most cases, and it is almost impossible for this performance to become a performance bottleneck. Therefore, the level of URL Rewrite chosen is generally not determined by the performance requirements of your application. So which level of URL Rewrite should be used? After using different levels of URL Rewrite, what should we pay attention to? I'm here to talk about my personal views.
Although the current URL Rewrite component can meet most applications in terms of functionality, at some point, we do still need some special functions. For example, URL Rewrite based on the domain name is not easy to achieve with the current URL Rewrite component. The commercial ISAPI Rewrite can currently support this. Unfortunately, the open source UrlRewriter.NET and IIRF have insufficient functions in this regard. They are all matched based on the path of the request relative to the site, and the domain name requested cannot be used as a matching condition. This requires us to extend the URL Rewrite component. For most .NET developers, managed code is naturally the first choice for development. At this time, it may be necessary to choose the ASP.NET-level URL Rewrite rewriting component. However, many extension examples can be found on the Internet, whether it is UrlRewriter.NET at the ASP.NET level or IIRF at the IIS level.
But in fact, if we want to achieve the above functions, we can also do it in two steps. First we use IIRF for URL Rewrite at the IIS level, and then further URL Rewrite at the ASP.NET level. For example, if we now want to rewrite " http://jeffz.domain.com/articles " to "/ArticleList.aspx?owner=jeffz", we can first let IIRF do the first URL Rewrite, with the purpose of rewriting " /articles" is rewritten 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 inside ASP.NET, we can do the second URL Rewrite (for convenience, I still write it in Global.asax, and it is recommended to use 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, the effect we want has been achieved (in actual projects, the above code cannot be used directly because it needs to be judged whether there is a Query String, etc.).
In addition, ASP.NET-level URL Rewrite can only work in ASP.NET (obvious thing). If you want URL Rewrite to support other server technologies such as PHP, RoR, etc., you can only use IIS-level URL Rewrite (or other URL Rewrite function provided by server technology).
Some special characters are not allowed to appear in URLs, or once they appear in URLs, the meaning of the request is changed. For example, we need to perform URL Rewrite on the search page, rewrite "/Search/xxx" to "/Search.aspx?xxx", and then obtain the keywords provided by the user based on the string after the question mark. If using UrlRewriter.NET, we will use the following configuration:
< rewriter >
< rewrite url = " ^/Search/(.+)$ " to = " ~/Search.aspx?$1 " processing = " stop " />
</ rewriter >
Under normal circumstances, this URL Rewrite works normally. But if the user uses "%" as the keyword, the situation is 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" is followed by "%"), and most of them will find "400 Bad Request" errors. However, it is legal to put "%" in the Query String - yes, didn't we rewrite the keyword into the Query String? Why doesn't it still work? This is also determined by the way ASP.NET is executed.
Bad Request is determined in step 3 of the above figure, that is, while it is still being initialized. Our URL Rewrite only occurs in the BeginRequest event in step 4. When the request contains illegal characters, we have no chance to perform URL Rewrite at all.
So how do we deal with this problem? Under normal circumstances, it won't be a big problem if we remove % on the client (some sites do do this), but what if we have to keep it? Then use Query String to pass parameters, or we can also use IIS level URL Rewrite. Still taking IIRF as an example:
RewriteRule ^/Search/(.+)$ /Search.aspx?$1 [I, L, U]
When the request is sent to IIS (step 1), and after selecting which ISAPI should be handed over for execution (Step 2) URL Rewrite occurred before. After URL Rewrite, the "%" in the address has been transferred to the Query String, and it is naturally legal when it is handed over to ASP.NET for processing.
Finally, let’s discuss the configuration of the error page. For example, generally we will configure a 404 error page for the application, so that when the user accesses a non-existent resource, we can show him a specific page instead of the default error prompt. But at this point, different levels of URL Rewrite must be configured using different methods.
If we use ASP.NET level URL Rewrite, generally speaking we have set up Wildcard Mapping in IIS, so that any request (including html, jpg, etc.) will be processed by ASP.NET. If a resource that does not exist is requested, a 404 error will be issued by ASP.NET, so 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. In other words, the ASP.NET engine will only start working when the address after Rewrite is aspx (or other things that should have been handled by ASP.NET ISAPI). If the user requests a resource that does not exist, a 404 error will be issued by IIS. At this time, the 404 error page should be configured in IIS:
So far, the topic of URL Rewrite has been discussed. In actual development, you will definitely encounter various different situations, but as long as you understand the key to the URL Rewrite method and think according to the way the program runs, I believe that generally you will not encounter difficult problems.