ASP.NETMVCでIISレベルのURL書き換えを使用する

約1年半前、私はブログに一連URL Rewriteの記事（2、3、4）を書き、ASP.NETプラットフォームURL Rewriteでの方法とそれぞれの特性をより詳細に説明しました。言われていることは非常に具体的であり、対処90%することができると言わなければなりません。実際IIS Rewrite、原理は非常に理解しやすいです。いくつかの簡単な変更と推論の後、いくつかの問題の原因と解決策を引き出すことができます。次に、実際のケースを見てみましょう。でASP.NET MVCIISレベルを使用しますURL Rewrite。

その時の記事で、2つのレベルと2つのレベルがあり、それぞれに独自の特性と制限URL Rewriteがあると述べました。で私たちの一般的な方法があるのミドルレベル、その役割からでキャプチャしたデータやプログラムを使用する（もちろん「構築」機能、話に待機があります）。したがって、多くの場合、のレベルを使用する必要はありません。そして今、IISレベルが使用されているので、避けられない特別な問題がいくつかあるため、「それをしなければならない」のです。IISASP.NETASP.NET MVCASP.NETURL RoutingURLASP.NET MVCASP.NETURL RewriteURL Rewrite

以下URLはすべてhttp://51programming.com例として取り上げています。このドメイン名は私が解決しました127.0.0.1。必要に応じて、実験に使用できます。

何年も前に、その1つURLはPath共通パスであり、クエリパスなどの動的パラメータは、次のようにQuery String提供されます。

http://51programming.com/products?keywords=helloworld

混乱を避けるために、最初にいくつかの概念を明確にしましょう。とはURL、とはPath、とはQueryString。たとえば、上記のアドレスでは、これら3つは次のとおりです。

URL：http://51programming.com/products?keywords=helloworld
道：http://51programming.com/products
クエリ文字列：keywords=helloworld

その後、SEOの台頭後、このような「動的アドレス」は検索エンジンの重みの最適化に役立たないと言う人もいるため、キーワードをPathその一部として使用することをお勧めします。だからこれが現れたURL：

http://51programming.com/products/helloworld

問題はそれほど大きくないようですが、キーワードはユーザーが入力することが多く、特殊文字が入力される場合があることを知っておく必要があります。たとえば、ユーザーがキーワードとして「200％」を入力した場合、2つの形式URLは次のようになります。

http://51programming.com/products?keywords=200%25
http://51programming.com/products/200%25

試してみると、最初の文字はURL正常にアクセスでき、2番目の文字は例外URLをスローBad Requestすることがわかります。
ここに画像の説明を挿入
これはPath、URLに特殊文字があり、そのような文字はにしか表示されないためQuery Stringです。

この写真を見て、他にどのような情報に気づきましたか？問題の原因を突き止めて問題を解決しようとするとき、最初に明確にする必要があるのは、問題がどこにあるかです。たとえば、この画面を参照してください。これはASP.NETスローされた例外です。つまり、IIS違法として扱わないでください。URLそれでも正直URLにASP.NET ISAPI対処します。したがって、実行エンジンに入る前に、IISレベルを使用してURLを受け入れ可能な形式に置き換えることができます。URL RewriteASP.NET

RewriteRule  ^/products/([^\?]*)\?(.+)    /products?$2&keywords=$1     [I,L,U]
RewriteRule  ^/products/([^\?]*)          /products?keywords=$1     [I,L,U]

最初の行はQuery Stringある場合を扱い、2番目の行はQuery Stringない場合を扱います。ここで使用しているコンポーネントはIIRF（Ionic's Isapi Rewrite Filter）、これが1年半前の記事で推奨したオープンソース製品であるということです。現在はアップグレードされています。その機能は、入力するASP.NET ISAPI前にURL他の形式に書き換えることです。
ここに画像の説明を挿入

Bad Requestステップ2ですでにURL Rewrite合法的な形式になっているため、元々はステップ3で表示されます。したがって、残りの処理に問題はありません。

これらの内容は1年半前の記事で言及されていましたが、現在はそこにあるためASP.NET MVC、事態はさらに複雑になっています。ASP.NET RoutingURLを「照合」する機能に加えて、URLを「アセンブル」する機能もあるためです。したがって、後者ASP.NET Routingを認識するRewriteことはURL難しくありませんが、Rewrite前者を同時に「組み立てる」方法にURLはいくつかのトリックが必要です。たとえば、次のRoute構成では、URL入力（/products?keywords=xxx）のみを認識できますが、必要なURL（/products/xxx）をアセンブルできません。

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

したがって、これを行う必要があります。

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

バックエンドのコンテンツ全体をkeywords一致させることに注意してください。Path提供しkeywordsたデフォルト値のため、「/products」のようなPath入力でもこのRouteルールに正しく一致できますが、現時点でRoute Valueは、のkeywordsフィールドはユーザーではありません。入力コンテンツ（ユーザー入力/products/xxxが/products?keywords=xxx）として書き直されているためです。つまり、次のAction場合、そのkeywordsパラメータは常に空の文字列になります。

public ActionResult List(string keywords) {
    
     ... }

幸い、ASP.NET MVCModel Binderにはメカニズムがあり、Model Binderこのパラメーターを取得する場所を指定するメカニズムを作成できます。

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

その後にそれを適用するパラメータ：Listkeywords

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

パラメータ名のでkeywords、そうbindingContext.ModelNameもkeywords、その後からQuery Stringコンテンツ我々は、必要に取ることができるようになります。URL生成keywordsに関してRoute Valueは、同じ方法でフィールドを追加できるため、以前に構成したRouteルールで適切なPath（つまり/products/xxx）にアセンブルされます。

この例では、バックエンドのコンテンツ全体をkeywords一致させますPathが、Path中央の段落に特殊文字がある場合はどうなりますか？実際、それは同じですが、プロセス中に、URL Rewrite次のRouteルールのように、最終的な書き換えで「false」値を入力する必要があります。

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

IISレベルURL Rewriteでの書き換えのルールは次のとおりです。

RewriteRule  ^/products/([^/]*)/(.*)     /products/useless-segement/$2?keywords=$1     [I,L,U]

このようにして、ユーザー入力/products/xxx/2が書き換えられる場合、/products/useless-token/2?keywords=xxx実際には、最初の例でもこれを行うことができますが、私は偽の値を追加することに「慣れていません」。

上記の解決策ではIIS 6との通常の使用が、残念ながらで途中、おそらくに引き継ぐため、ロングスロー、論理の一部ではなく、「ASP.NETレベル」よりも「レベルをIIS」例外。この方法に遭遇した場合、この厄介な問題を取り除くには、次の3つの手順を実行する必要があります。IIS 7Classic ModeIIS 7Intergrated ModeASP.NETIISBad Request

設定AllowRestrictedChars：KB820129（IIS 7に特殊文字を受け入れさせる）
設定VerificationCompatibility：KB826437の「インストール.NET 1.1 SP1」以外の手順（ASP.NET特殊文字を受け入れます）
ASP.NETページValidateRequestをに設定しますFalse

実際、これらの3つの変更手順を実行している限り、現在のケースでは、IISレベルURL Rewriteを使用しなくても問題はありません。

ASP.NETMVCでIISレベルのURL書き換えを使用する

おすすめ