以前の記事では、URL 書き換えのいくつかの主要な側面について説明しました。このシリーズの最後の記事では、さまざまなレベルの URL 書き換えの詳細と特徴について説明します。
理論的には、C または C++ で記述された IIS レベルの URL リライトは、マネージ コードで記述された ASP.NET レベルの URL リライトよりもパフォーマンスが高くなります。ただし、この領域の違いはほとんどの場合無視できるものであり、このパフォーマンスがパフォーマンスのボトルネックになることはほとんど不可能であると思います。したがって、選択される URL 書き換えのレベルは、通常、アプリケーションのパフォーマンス要件によって決まりません。それでは、どのレベルの URL 書き換えを使用する必要があるのでしょうか?さまざまなレベルの URL 書き換えを使用した後、何に注意する必要がありますか?ここでは私の個人的な見解についてお話します。
現在の URL 書き換えコンポーネントは、機能の点でほとんどのアプリケーションを満たすことができますが、ある時点では、依然としていくつかの特別な機能が必要になります。たとえば、ドメイン名に基づく URL 書き換えは、現在の URL 書き換えコンポーネントでは簡単に実現できません。商用の ISAPI Rewrite は現在これをサポートできますが、残念ながら、オープン ソースの UrlRewriter.NET と IIRF にはこの点で十分な機能がありません。これらはすべて、サイトに対するリクエストの相対パスに基づいて照合されます。要求されたドメイン名を照合条件として使用することはできません。これには、URL Rewrite コンポーネントを拡張する必要があります。ほとんどの .NET 開発者にとって、現時点ではマネージ コードが開発の最初の選択肢になります。ASP.NET レベルの URL Rewrite 書き換えコンポーネントを選択する必要がある場合があります。ただし、ASP.NET レベルの UrlRewriter.NET であっても、IIS レベルの IIRF であっても、多くの拡張機能の例がインターネット上で見つかります。
しかし実際には、上記の機能を実現したい場合は、2 つのステップで実行することもできます。まず、IIS レベルで URL 書き換えに IIRF を使用し、次に ASP.NET レベルでさらに URL 書き換えを使用します。たとえば、「 http://jeffz.domain.com/articles 」を「/ArticleList.aspx?owner=jeffz」に書き換えたい場合、まず、書き換えを目的として、IIRF に最初の URL 書き換えを実行させることができます。 「/articles」は「/ArticleList.aspx」に書き換えられます。
RewriteRule ^/Articles$ /ArticleList.aspx [I、L、U]
このようにして、ASP.NET エンジンは /ArticleList.aspx の要求を直接受信します。次に、ASP.NET 内で 2 回目の URL 書き換えを実行できます (便宜上、引き続き Global.asax に書きます。プロジェクト内で追加の HttpModule を使用することをお勧めします)。
protected void Application_BeginRequest(オブジェクト送信者, EventArgs e)
{
HttpContextコンテキスト = HttpContext .Current;
文字列ホスト = context.Request.Url.Host;
文字列所有者 = host.Substring(0, host.IndexOf( '.' ));
context.RewritePath(context.Request.RawUrl + "?owner=" + owner);
2 回の URL 書き換えにより、目的の効果が得られました (実際のプロジェクトでは、クエリ文字列の有無などを判断する必要があるため、上記のコードを直接使用することはできません)
。
さらに、ASP.NET レベルの URL 書き換えは ASP.NET でのみ機能します (当然のことですが) URL 書き換えで PHP や RoR などの他のサーバー テクノロジをサポートしたい場合は、IIS レベルの URL 書き換えのみを使用できます。 (またはサーバーテクノロジーによって提供される他の URL 書き換え機能)。
一部の特殊文字は URL に使用することが許可されていないか、URL に使用されるとリクエストの意味が変更されます。たとえば、検索ページで URL 書き換えを実行し、「/Search/xxx」を「/Search.aspx?xxx」に書き換えて、疑問符の後の文字列に基づいてユーザーが指定したキーワードを取得する必要があります。 UrlRewriter.NET を使用する場合は、次の構成を使用します:
< rewriter >
<書き換える URL = " ^/検索/(.+)$ " to = " ~/Search.aspx?$1 " 処理= "停止" />
</ rewriter >
通常の状況では、この URL 書き換えは正常に機能します。ただし、ユーザーがキーワードとして「%」を使用した場合は、次のエラー ページ プロンプトが表示されるため、状況は異なります。
これは、URL に「%」が許可されていないためです。さまざまな Web サイトにアクセスして、「ABC%25DEF」(「%25」の後に「%」が続く) などのパスをリクエストしようとすると、ほとんどの Web サイトで「400 Bad Request」エラーが見つかります。ただし、クエリ文字列に「%」を入れることは合法です。はい、キーワードをクエリ文字列に書き換えませんでしたか?まだ機能しないのはなぜですか?これは、ASP.NET の実行方法によっても決まります。
不正なリクエストは、上図のステップ 3、つまり初期化中に判断されます。 URL 書き換えは、ステップ 4 の BeginRequest イベントでのみ発生します。リクエストに不正な文字が含まれている場合、URL 書き換えを実行する機会はまったくありません。
では、この問題にどう対処すればよいでしょうか?通常の状況では、クライアントで % を削除しても大きな問題はありません (一部のサイトではこれを行っています)。しかし、% を保持しなければならない場合はどうすればよいでしょうか。次に、クエリ文字列を使用してパラメータを渡すか、IIS レベルの URL 書き換えを使用することもできます。引き続き IIRF を例に挙げます:
RewriteRule ^/Search/(.+)$ /Search.aspx?$1 [I, L, U]
リクエストが IIS に送信されるとき (ステップ 1)、どの ISAPI を渡すかを選択した後実行のためのオーバー (ステップ 2) URL 書き換えが前に行われました。 URL 書き換え後、アドレスの「%」はクエリ文字列に転送され、処理のために ASP.NET に渡されるときは当然のことながら正当です。
最後に、エラーページの構成について説明します。たとえば、通常はアプリケーションの 404 エラー ページを構成して、ユーザーが存在しないリソースにアクセスしたときに、デフォルトのエラー プロンプトの代わりに特定のページを表示できるようにします。ただし、この時点では、異なる方法を使用して、異なるレベルの URL 書き換えを構成する必要があります。
ASP.NET レベルの URL 書き換えを使用する場合、一般に、IIS でワイルドカード マッピングを設定し、あらゆる要求 (html、jpg などを含む) が ASP.NET によって処理されるようにします。存在しないリソースが要求された場合、ASP.NET によって 404 エラーが発行されるため、web.config で 404 エラー ページを構成する必要があります:
< customErrors モード= 「オン」 defaultRedirect = " GenericErrorPage.htm " >
<エラー ステータスコード= " 404 " リダイレクト= " FileNotFound.htm " />
</customErrors> IISレベル
の URL 書き換えを使用する場合、ワイルドカード マッピングは構成されません。つまり、ASP.NET エンジンは、Rewrite 後のアドレスが aspx (または ASP.NET ISAPI によって処理されるべき他のもの) の場合にのみ動作を開始します。ユーザーが存在しないリソースを要求すると、IIS によって 404 エラーが発行されます。この時点で、IIS で 404 エラー ページを構成する必要があります。
ここまで、URL 書き換えのトピックについて説明してきました。実際の開発では、さまざまな場面に遭遇することになるでしょうが、URL Rewrite メソッドのポイントを理解し、プログラムの動作に合わせて考えれば、通常は難しい問題に遭遇することはないと思います。