Shulou(Shulou.com)06/02 Report--

In this issue, the editor will bring you about and analyze the implementation of URL Rewrite in ASP.NET MVC. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

Now let's look at a real case: using IIS-level URL Rewrite in ASP.NET MVC.

In the article at that time, I mentioned that URL Rewrite has two levels: IIS and ASP.NET, and each has its own characteristics and limitations. The common way we use ASP.NET MVC is ASP.NET-level URL Routing, which captures data from URL and gives it to the program to use (and, of course, the "construct" function, which we'll talk about later). Therefore, we often do not need to use ASP.NET-level URL Rewrite in ASP.NET MVC. Today, the use of IIS-level URL Rewrite is precisely because there are some special problems that can not be avoided.

The following URL all take http://51programming.com as an example, this domain name has been parsed to 127.0.0.1, you can use it to experiment if you need it.

Many years ago, the Path of a URL was a normal path, while dynamic parameters, such as query paths, were provided through Query String, such as:

Http://51programming.com/products?keywords=helloworld to avoid confusion, let's clarify some concepts here. What is URL, what is Path, and what is QueryString. For example, at the above address, these three are:

URL: http://51programming.com/products?keywords=helloworld Path: http://51programming.com/products Query String:keywords=helloworld

Later, after the rise of SEO, some people said that such "dynamic addresses" were not conducive to weight optimization in search engines, so it was suggested that keywords be used as part of Path. So the URL appears like this:

Http://51programming.com/products/helloworld doesn't seem to be a big problem in this way, but you should know that keywords are often typed by the user, and special characters may be entered. For example, if the user enters "200%" as the keyword, the URL in the two forms is:

If you try it, you will know that the first URL can be accessed normally, while the second URL will throw a Bad Request exception:

This is because special characters appear in the Path part of URL, which can only be seen in Query String.

What other information do you realize when you see this picture? In identifying the cause of the problem and trying to solve it, the first thing to do is to make it clear where the problem is. For example, when you see this picture, you should be well aware that this is an exception thrown by ASP.NET, in other words, IIS does not treat it as an illegal URL, it honestly hands over URL to ASP.NET ISAPI. Therefore, we can use the IIS-level URL Rewrite to replace URL with an acceptable form before entering the ASP.NET execution engine:

RewriteRule ^ / products/ ([^\?] *)\? (. +) / products?$2&keywords=$1 [Imam LMagu]

The RewriteRule ^ / products/ ([^\?] *) / products?keywords=$1 [IMagneLMagneU] * * line deals with the case with Query String, while the second line deals with the case without Query String. The component used here is IIRF (Ionic's Isapi Rewrite Filter), an open source product that I recommended in my article a year and a half ago, and now it has been upgraded. Its function is to rewrite URL into other forms before entering ASP.NET ISAPI:

Bad Request, which would have appeared in step 3, has been made legal by URL Rewrite in step 2. So there will be no problem with the rest of the treatment.

This was mentioned in the article a year and a half ago, but now that ASP.NET MVC is available, things are getting more complicated. Because in addition to "matching" the functions of URL, ASP.NET Routing is also responsible for "assembling" URL. Therefore, it is not difficult for ASP.NET Routing to recognize the URL after Rewrite, but it takes some tricks to make it "assemble" the URL before Rewrite at the same time. For example, the following Route configuration can only recognize the URL input (/ products?keywords=xxx) but cannot assemble the URL (/ products/xxx) we need:

Routes.MapRoute ("Product.List", "products", new {controller = "Product", action = "List"})

So we have to do this:

Routes.MapRoute ("Product.List", "products/ {* keywords}", new {controller = "Product", action = "List", keywords = ""})

Notice that we let keywords match all the contents of the Path backend, and because we provide the default value for keywords, even Path input such as "/ products" correctly matches this Route rule-- except that the keywords field in Route Value is no longer what the user entered (because the user entered / products/xxx, has been rewritten to / products?keywords=xxx). In other words, if there is an Action like this, its keywords parameter is always an empty string:

Public ActionResult List (string keywords) {...} fortunately, there is a Model Binder mechanism in ASP.NET MVC, so we can write a Model Binder to specify where to get this parameter:

Public class FromQueryBinder: IModelBinder {public object BindModel (ControllerContext controllerContext, ModelBindingContext bindingContext) {return controllerContext.HttpContext.Request.QueryString [bindingContext.ModelName];}}

Then apply it to the keywords parameter of List:

Public ActionResult List ([ModelBinder (typeof (FromQueryBinder))] string keywords)

Because the parameter name is keywords, bindingContext.ModelName is also keywords, so we can get what we need from Query String. As for the URL generation, we can still add a keywords field to the Route Value, so the appropriate Path will be assembled in the Route rules we configured earlier (that is, / products/xxx).

In this example, we asked keywords to match all the contents of the Path backend, but what if a special character is needed in the middle of the Path? In fact, the same is true, except that you need to enter a "false" value when you finally rewrite the URL Rewrite, such as the Route rule:

Routes.MapRoute ("Product.List", "products/ {keywords} / page", new {controller = "Product", action = "List"})

The rule for URL Rewrite rewriting at the IIS level can be:

RewriteRule ^ / products/ ([^ /] *) / (. *) / products/useless-segement/$2?keywords=$1 [IMagneLMagu] so that if the user enters / products/xxx/2, it will be rewritten as / products/useless-token/2?keywords=xxx--. In fact, we can do the same in * examples, but I'm just not used to adding a fake value.

The above solution can be used normally in the Classic Mode of IIS 6 and IIS 7, but in the Intergrated Mode of IIS 7, it may be because ASP.NET takes over part of the logic of IIS that a "IIS level" rather than a "ASP.NET level" Bad Request exception is thrown early. If you encounter this way, you must take the following three steps to get rid of this troublesome problem:

Set AllowRestrictedChars:KB820129 (let IIS 7 accept special characters)

Set up steps in VerificationCompatibility:KB826437 other than "install .NET 1.1 SP1" (let ASP.NET accept special characters)

Set the ValidateRequest of the ASP.NET page to False

In fact, as long as you have gone through these three steps of modification, for the current case, there should be no problem even if you do not use an IIS-level URL Rewrite.

The above is the editor for you to share and analyze the implementation of URL Rewrite in ASP.NET MVC, if you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.