ASP.NET での URL の書き換え

[アーティクル]
06/05/2013

Scott Mitchell
4GuysFromRolla.com

2004 年 3 月

適用先:
Microsoft® ASP.NET

概要：Microsoft ASP.NET を使用して動的 URL の書き換えを実行する方法について説明します。 URL 書き換えは、受信 Web 要求をインターセプトし、それを別の URL に自動的にリダイレクトするプロセスです。 URL の書き換えを実装するためのさまざまな手法について説明し、URL 書き換えの実際のシナリオについて説明します。 (31ページ印刷)

この記事のソースコードをダウンロードします。

内容

はじめに
URL 書き換えの一般的な用途
要求が IIS に到達した場合の動作
URL 書き換えの実装
URL 書き換えエンジンの構築
URL 書き換えエンジンを使用した単純な URL 書き換えの実行
真に "ハッキング可能" な URL の作成
まとめ
関連書籍

はじめに

少し時間を取って、Web サイトの URL の一部を確認してください。 type=summary などのhttp://yoursite.com/info/dispEmployeeInfo.aspx?EmpID=459-099\& URL は見つかりますか? または、あるディレクトリまたは Web サイトから別のディレクトリまたは Web サイトに移動された多数の Web ページがあり、古い URL をブックマークした訪問者のリンクが壊れている可能性があります。この記事では、URL の書き換えを使用して、type=summary を次のようなものに置き換えることでhttp://yoursite.com/info/dispEmployeeInfo.aspx?EmpID=459-099\&、それらの見苦しい URL を意味のある覚えやすい URL に短縮する方法について説明します。http://yoursite.com/people/sales/chuck.smith また、インテリジェントな 404 エラーを作成するために URL 書き換えを使用する方法についても説明します。

URL 書き換えは、受信 Web 要求をインターセプトし、要求を別のリソースにリダイレクトするプロセスです。 URL の書き換えを実行する場合、通常、要求される URL がチェックされ、その値に基づいて、要求が別の URL にリダイレクトされます。たとえば、Web サイトの再構築によって /people/ ディレクトリ内のすべての Web ページが /info/employees/ ディレクトリに移動された場合は、URL の書き換えを使用して、Web 要求が /people/ ディレクトリ内のファイルを対象としているかどうかを確認します。要求が /people/ ディレクトリ内のファイルに対して行われた場合は、要求を同じファイルに自動的にリダイレクトする必要がありますが、代わりに /info/employees/ ディレクトリにリダイレクトされます。

従来の ASP では、URL 書き換えを利用する唯一の方法は、ISAPI フィルターを記述するか、URL 書き換え機能を提供するサードパーティ製品を購入することでした。ただし、Microsoft® ASP.NET では、さまざまな方法で独自の URL 書き換えソフトウェアを簡単に作成できます。この記事では、URL の書き換えを実装するために ASP.NET 開発者が使用できる手法について説明し、URL 書き換えのいくつかの実際の使用方法に目を向けます。 URL 書き換えの技術的な詳細を詳しく調べる前に、URL の書き換えを使用できる日常的なシナリオをいくつか見てみましょう。

URL 書き換えの一般的な用途

データドリブン ASP.NET Web サイトを作成すると、多くの場合、クエリ文字列パラメーターに基づいてデータベースのデータのサブセットを表示する単一の Web ページが作成されます。たとえば、eコマースサイトを設計する場合、タスクの 1 つは、ユーザーが販売する製品を参照できるようにすることです。これを容易にするために、特定のカテゴリの製品を表示する displayCategory.aspx というページを作成できます。表示するカテゴリの製品は、querystring パラメーターによって指定されます。つまり、ユーザーが販売のためにウィジェットを閲覧する必要があり、すべてのウィジェットに CategoryID が 5 の場合、ユーザーは次の場所にアクセスします http://yousite.com/displayCategory.aspx?CategoryID=5。

このような URL を使用して Web サイトを作成するには、2 つの欠点があります。まず、エンドユーザーの観点から見ると、URL http://yousite.com/displayCategory.aspx?CategoryID=5 は混乱しています。ユーザビリティの専門家である Jakob Neilsen は、次のように URL を選択することをお勧めします。

短い。
入力が簡単です。
サイト構造を視覚化します。
"Hackable" を使用すると、ユーザーは URL の一部をハッキングしてサイト内を移動できます。

その一覧に、URL も覚えやすいものに追加します。 URL http://yousite.com/displayCategory.aspx?CategoryID=5 は Neilsen の条件を満たしません。また、覚えやすいものもありません。ユーザーにクエリ文字列値の入力を求めることにより、URL の入力が困難になり、クエリ文字列パラメーターの目的とその名前と値のペア構造を理解している経験豊富な Web 開発者のみが URL を "ハッキング可能" にします。

より良いアプローチは、次のような http://yoursite.com/products/Widgets賢明で思い出深いURLを可能にすることです。 URL を見るだけで、表示されるウィジェットに関する情報を推測できます。 URL は覚えやすく、共有も簡単です。私は同僚に「チェックアウト yoursite.com/products/Widgets」と言うことができ、URLが何であるかをもう一度聞く必要なくページを表示できる可能性があります。 (たとえば、Amazon.com ページで試してみてください)。URL も表示され、"hackable" と動作します。つまり、ユーザーが URL の末尾をハッキングして入力 http://yoursite.com/productsすると、 すべての 製品の一覧、または表示できる製品のすべてのカテゴリの少なくとも一覧が表示されます。

メモ "ハッキング可能な" URL の主な例として、多くのブログエンジンによって生成される URL を考えてみましょう。 2004 年 1 月 28 日の投稿を表示するには、次のような http://someblog.com/2004/01/28URL にアクセスします。 URL がハッキングされた http://someblog.com/2004/01場合、ユーザーには 2004 年 1 月のすべての投稿が表示されます。さらに http://someblog.com/2004 それを切り捨て、2004年のすべての投稿を表示します。

URL の簡略化に加えて、URL の書き換えは、Web サイトの再構築を処理するためによく使用されます。そうしないと、多数のリンクが壊れ、ブックマークが古くなります。

要求が IIS に到達した場合の動作

URL 書き換えを実装する方法を正確に調べる前に、Microsoft® インターネットインフォメーションサービス (IIS) によって受信要求がどのように処理されるかを理解しておく必要があります。 IIS Web サーバーに要求が到着すると、IIS は要求されたファイルの拡張子を調べて、要求の処理方法を決定します。要求は、HTML ページ、イメージ、その他の静的コンテンツと同様に、IIS によってネイティブに処理することも、IIS が要求を ISAPI 拡張機能にルーティングすることもできます。 (ISAPI 拡張機能は、受信 Web 要求を処理するアンマネージコンパイル済みクラスです。そのタスクは、要求されたリソースのコンテンツを生成することです)。

たとえば、Info.asp という名前の Web ページに対して要求が送信された場合、IIS はメッセージを asp.dll ISAPI 拡張機能にルーティングします。この ISAPI 拡張機能は、要求された ASP ページを読み込んで実行し、レンダリングされた HTML を IIS に返します。これにより、要求元のクライアントに送信されます。 ASP.NET ページの場合、IIS はメッセージを aspnet_isapi.dll ISAPI 拡張機能にルーティングします。その後、aspnet_isapi.dll ISAPI 拡張機能は、マネージド ASP.NET ワーカープロセスに処理を受け取り、要求を処理し、ASP.NET Web ページのレンダリングされた HTML を返します。

IIS をカスタマイズして、どの拡張機能が ISAPI 拡張機能にマップされているかを指定できます。図 1 は、インターネットインフォメーションサービス管理ツールの [アプリケーション構成] ダイアログボックスを示しています。 ASP.NET 関連の拡張機能 (.aspx、.ascx、.config、.asmx、.rem、.cs、.vb など) はすべて、aspnet_isapi.dll ISAPI 拡張機能にマップされることに注意してください。

ms972974.urlrewriting_fig01(en-us,MSDN.10).gif

図 1. ファイル拡張子の構成済みマッピング

IIS が受信要求を管理する方法の詳細については、この記事の範囲外です。ただし、ミケーレ・ルルー・バスタマンテの記事「IIS と ASP.NET 内」で詳しい説明があります。 ASP.NET エンジンは、拡張機能が IIS のaspnet_isapi.dllに明示的にマップされている受信 Web 要求に対してのみその手を取得することを理解しておくことが重要です。

ISAPI フィルターを使用した要求の確認

受信 Web 要求のファイル拡張子を適切な ISAPI 拡張機能にマッピングするだけでなく、IIS は他にも多くのタスクを実行します。たとえば、IIS は要求を行うユーザーの認証を試み、認証されたユーザーが要求されたファイルにアクセスするための承認を持っているかどうかを判断します。要求の処理の有効期間中に、IIS はいくつかの状態を通過します。各状態で、IIS は ISAPI フィルターを使用してプログラムで処理できるイベントを発生させます。

ISAPI 拡張機能と同様に、ISAPI フィルターは、Web サーバーにインストールされているアンマネージドコードのブロックです。 ISAPI 拡張機能は、特定のファイルの種類に対する要求に対する応答を生成するように設計されています。一方、ISAPI フィルターには、IIS によって発生したイベントに応答するコードが含まれています。 ISAPI フィルターは、受信データと送信データをインターセプトして変更することもできます。 ISAPI フィルターには、次のような多数のアプリケーションがあります。

認証と認可。
ログ記録と監視。
HTTP 圧縮。
URL の書き換え。

ISAPI フィルターを使用して URL の書き換えを実行できますが、この記事では、ASP.NET を使用した URL 書き換えの実装について説明します。ただし、URL 書き換えを ISAPI フィルターとして実装することと、ASP.NET で使用できる手法を使用する場合のトレードオフについて説明します。

要求が ASP.NET エンジンに入った場合の動作

ASP.NET する前に、IIS Web サーバーでの URL 書き換えを ISAPI フィルターを使用して実装する必要があります。 ASP.NET エンジンは IIS とよく似ているため、ASP.NET では URL の書き換えが可能です。類似点は、ASP.NET エンジンが次の理由で発生します。

要求の処理時にイベントを発生させます。
IIS の ISAPI フィルターと同じ、発生したイベントを任意の数の HTTP モジュール が処理できるようにします。
要求されたリソースのレンダリングを、IIS の ISAPI 拡張機能と同じ HTTP ハンドラーに委任します。

IIS と同様に、要求の有効期間中に、ASP.NET エンジンは、ある状態の処理から別の状態への変更を通知するイベントを発生させます。たとえば、BeginRequest イベントは、ASP.NET エンジンが最初に要求に応答したときに発生します。 AuthenticateRequest イベントは次に発生します。これは、ユーザーの ID が確立されたときに発生します。 (他にも多数のイベント (AuthorizeRequest、 ResolveRequestCache、 EndRequest など) があります。これらのイベントは System.Web.HttpApplication クラスのイベントです。詳細については、 HttpApplication クラスの概要に関する技術ドキュメントを参照してください)。

前のセクションで説明したように、IIS によって発生したイベントに応答する ISAPI フィルターを作成できます。同様に、ASP.NET は、ASP.NET エンジンによって発生したイベントに応答できる HTTP モジュールを提供します。 ASP.NET Web アプリケーションは、複数の HTTP モジュールを持つよう構成できます。 ASP.NET エンジンによって処理される要求ごとに、構成された各 HTTP モジュールが初期化され、要求の処理中に発生したイベントにイベントハンドラーを接続できます。要求ごとに多数の組み込み HTTP モジュールが使用されていることを確認します。組み込みの HTTP モジュールの 1 つは FormsAuthenticationModule です。フォーム認証が使用されているかどうかを最初に確認し、使用されている場合は、ユーザーが認証されているかどうかを確認します。そうでない場合、ユーザーは指定されたログオンページに自動的にリダイレクトされます。

IIS では、着信要求は最終的に ISAPI 拡張機能に送信され、そのジョブは特定の要求のデータを返すということです。たとえば、従来の ASP Web ページの要求が到着すると、IIS は要求を asp.dll ISAPI 拡張機能に送信します。この拡張機能は、要求された ASP ページの HTML マークアップを返すタスクです。 ASP.NET エンジンも同様のアプローチを利用します。 HTTP モジュールを初期化した後、ASP.NET エンジンの次のタスクは、要求を処理する HTTP ハンドラーを決定することです。

ASP.NET エンジンを通過するすべての要求は、最終的に HTTP ハンドラーまたは HTTP ハンドラーファクトリに到着します (HTTP ハンドラーファクトリは、要求の処理に使用される HTTP ハンドラーのインスタンスを返すだけです)。最後の HTTP ハンドラーは、要求されたリソースをレンダリングし、応答を返します。この応答は IIS に返送され、要求を行ったユーザーに返されます。

ASP.NET には、多数の組み込み HTTP ハンドラーが含まれています。たとえば、PageHandlerFactory は、Web ページ ASP.NET レンダリングするために使用されます。 WebServiceHandlerFactory は、ASP.NET Web サービスの応答 SOAP エンベロープをレンダリングするために使用されます。 TraceHandler は、trace.axd への要求の HTML マークアップをレンダリングします。

図 2 は、ASP.NET リソースに対する要求の処理方法を示しています。最初に、IIS は要求を受信し、aspnet_isapi.dllにディスパッチします。次に、ASP.NET エンジンによって、構成された HTTP モジュールが初期化されます。最後に、適切な HTTP ハンドラーが呼び出され、要求されたリソースがレンダリングされ、生成されたマークアップが IIS に返され、要求元のクライアントに返されます。

ms972974.urlrewriting_fig02(en-us,MSDN.10).gif

図 2. IIS と ASP.NET による要求処理

カスタム HTTP モジュールと HTTP ハンドラーの作成と登録

カスタム HTTP モジュールと HTTP ハンドラーの作成は比較的単純なタスクであり、適切なインターフェイスを実装するマネージドクラスを作成する必要があります。 HTTP モジュールは System.Web.IHttpModule インターフェイスを実装する必要があります。一方、HTTP ハンドラーと HTTP ハンドラーファクトリは、それぞれ System.Web.IHttpHandler インターフェイスと System.Web.IHttpHandlerFactory インターフェイスを実装する必要があります。 HTTP ハンドラーと HTTP モジュールの作成の詳細については、この記事では説明しません。良い背景については、ASP.NET のマンソル・アーメッド・シディキの記事「HTTP ハンドラーと HTTP モジュール」を参照してください。

カスタム HTTP モジュールまたは HTTP ハンドラーが作成されたら、Web アプリケーションに登録する必要があります。 Web サーバー全体に対して HTTP モジュールと HTTP ハンドラーを登録するには、machine.config ファイルに簡単に追加するだけで済みます。特定の Web アプリケーションの HTTP モジュールまたは HTTP ハンドラーを登録するには、アプリケーションの Web.config ファイルに数行の XML を追加する必要があります。

具体的には、WEB アプリケーションに HTTP モジュールを追加するには、Web.configの configuration/system.web セクションに次の行を追加します。

<httpModules>
   <add type="type" name="name" />
</httpModules>

型の値は HTTP モジュールのアセンブリ名とクラス名を提供しますが、名前の値は、Global.asax ファイルで HTTP モジュールを参照できるフレンドリ名を提供します。

HTTP ハンドラーと HTTP ハンドラーファクトリは、次のように、Web.configの configuration/system.web セクションの httpHandlers> タグによって<構成されます。

<httpHandlers>
   <add verb="verb" path="path" type="type" />
</httpHandlers>

受信要求ごとに、ASP.NET エンジンが要求のレンダリングに使用する HTTP ハンドラーを決定することを思い出してください。この決定は、受信要求の動詞とパスに基づいて行われます。動詞は、行われた HTTP 要求の種類 (GET または POST) を指定しますが、パスは要求されたファイルの場所とファイル名を指定します。そのため、.scott 拡張子を持つファイルのすべての要求 (GET または POST) を HTTP ハンドラーで処理する必要がある場合は、Web.config ファイルに次のコードを追加します。

<httpHandlers>
   <add verb="*" path="*.scott" type="type" />
</httpHandlers>

ここで、型は HTTP ハンドラーの型でした。

メモHTTP ハンドラーを登録するときは、HTTP ハンドラーで使用される拡張機能が IIS で ASP.NET エンジンにマップされていることを確認することが重要です。つまり、.scott の例では、.scott 拡張子が IIS で aspnet_isapi.dll ISAPI 拡張子にマップされていない場合、foo.scott ファイルに対する要求によって IIS が foo.scott ファイルの内容を返そうとします。 HTTP ハンドラーがこの要求を処理するには、.scott 拡張機能を ASP.NET エンジンにマップする必要があります。 ASP.NET エンジンは、要求を適切な HTTP ハンドラーに正しくルーティングします。

HTTP モジュールと HTTP ハンドラーの登録の詳細については、httpModules> 要素のドキュメントと httpHandlers 要素のドキュメントを参照してください<。<>

URL 書き換えの実装

URL の書き換えは、IIS Web サーバーレベルの ISAPI フィルターを使用するか、ASP.NET レベルの HTTP モジュールまたは HTTP ハンドラーを使用して実装できます。この記事では、ASP.NET を使用した URL 書き換えの実装に焦点を当てているため、ISAPI フィルターを使用した URL 書き換えの実装の詳細については説明しません。

system.Web.HttpContext クラスの RewritePath() メソッドを使用して、ASP.NET レベルで URL 書き換えを実装できます。 HttpContext クラスには、特定の HTTP 要求に関する HTTP 固有の情報が含まれています。 ASP.NET エンジンによって受信された要求ごとに、その要求に対して HttpContext インスタンスが作成されます。このクラスには、 受信要求 と送信応答へのアクセスを提供する Request と Response などのプロパティがあります。 アプリケーション 変数と セッション変数へのアクセスを提供するアプリケーションとセッション。 認証されたユーザーに関する情報を提供するユーザー。およびその他の関連プロパティ。

Microsoft® .NET Framework バージョン 1.0 では、RewritePath() メソッドは、使用する新しいパスである 1 つの文字列を受け入れます。内部的には、 HttpContext クラスの RewritePath(string) メソッドは 、Request オブジェクトの Path プロパティと QueryString プロパティを更新します。 RewritePath(string)に加えて、.NET Framework バージョン 1.1 には、3 つの文字列入力パラメーターを受け取る RewritePath() メソッドの別の形式が含まれています。この代替オーバーロードフォームは、Request オブジェクトの Path プロパティと QueryString プロパティを設定するだけでなく、PhysicalPath、PathInfo、および FilePath プロパティの Request オブジェクトの値を計算するために使用される内部メンバー変数も設定します。

ASP.NET で URL 書き換えを実装するには、次の HTTP モジュールまたは HTTP ハンドラーを作成する必要があります。

要求されたパスを確認して、URL を書き換える必要があるかどうかを判断します。
RewritePath() メソッドを呼び出して、必要に応じてパスを 書き換 える。

たとえば、Web サイトには、/info/employee.aspx?empID=employeeID を介してアクセスできる各従業員の情報があるとします。 URL をより "ハッキング可能" にするために、/people/EmployeeName.aspx で従業員のページにアクセスできるようにする場合があります。 URL の書き換えを使用する場合を次に示します。つまり、ページ /people/ScottMitchell.aspx が要求されたときに、代わりにページ /info/employee.aspx?empID=1001 が使用されるように URL を書き換えます。

HTTP モジュールを使用した URL の書き換え

ASP.NET レベルで URL 書き換えを実行する場合は、HTTP モジュールまたは HTTP ハンドラーを使用して書き換えを実行できます。 HTTP モジュールを使用する場合は、URL を書き換える必要があるかどうかを確認するために、要求のライフサイクル中にどの時点で決定する必要があります。一見すると、これは任意の選択のように見えるかもしれませんが、決定は重要な方法と微妙な方法の両方でアプリケーションに影響を与える可能性があります。組み込みの ASP.NET HTTP モジュールは Request オブジェクトのプロパティを使用して職務を実行するため、書き換えを実行する場所の選択が重要です。 (パスを書き換えることで 、Request オブジェクトのプロパティ値が変更されることを思い出してください)。これらのドイツ語の組み込み HTTP モジュールと関連するイベントを次に示します。

HTTP モジュール	Event	説明
FormsAuthenticationModule	AuthenticateRequest	ユーザーがフォーム認証を使用して認証されているかどうかを判断します。そうでない場合、ユーザーは指定されたログオンページに自動的にリダイレクトされます。
FileAuthorizationMoudle	AuthorizeRequest	Windows 認証を使用する場合、この HTTP モジュールは、Microsoft® Windows ® アカウントが要求されたリソースに対して適切な権限を持っていることを確認します。
UrlAuthorizationModule	AuthorizeRequest	要求者が指定した URL にアクセスできることを確認します。 URL 承認は、Web.config ファイル内の <承認> 要素と <場所> 要素によって指定されます。

BeginRequest イベントは AuthenticateRequest の前に発生し、AuthorizeRequest の前に発生することを思い出してください。

URL の書き換えを実行できる安全な場所の 1 つは、 BeginRequest イベントです。つまり、URL を書き換える必要がある場合は、組み込みの HTTP モジュールが実行される時点までに行われます。この方法の欠点は、フォーム認証を使用する場合に発生します。以前にフォーム認証を使用したことがある場合、ユーザーが制限されたリソースにアクセスすると、指定したログインページに自動的にリダイレクトされます。ログインに成功すると、ユーザーは最初にアクセスしようとしたページに戻されます。

BeginRequest イベントまたは AuthenticateRequest イベントで URL の書き換えが実行された場合、ログインページは送信されると、ユーザーを書き換えられたページにリダイレクトします。つまり、ユーザーがブラウザーウィンドウ /people/ScottMitchell.aspx に入力すると、/info/employee.aspx?empID=1001 に書き換えられます。フォーム認証を使用するように Web アプリケーションが構成されている場合、ユーザーが最初に /people/ScottMitchell.aspx にアクセスすると、最初に URL が /info/employee.aspx?empID=1001 に書き換えられます。次に、 FormsAuthenticationModule が実行され、必要に応じてユーザーがログインページにリダイレクトされます。ただし、ユーザーが正常にログインしたときに送信される URL は /info/employee.aspx?empID=1001 になります。 これは、FormsAuthenticationModule が実行されたときの要求の URL であるためです。

同様に、 BeginRequest イベントまたは AuthenticateRequest イベントで書き換えを実行すると、 UrlAuthorizationModule に書き換えられた URL が表示されます。つまり、Web.config ファイル内の場所>要素を使用<して特定の URL の承認を指定する場合は、書き換えられた URL を参照する必要があります。

これらの微妙な問題を修正するには、 AuthorizeRequest イベントで URL の書き換えを実行する場合があります。この方法では URL 承認が修正され、認証の異常が発生しますが、新しいしわが発生します。ファイル承認は機能しなくなりました。 Windows 認証を使用する場合、FileAuthorizationModule は、認証されたユーザーが特定の ASP.NET ページにアクセスするための適切なアクセス権を持っていることを確認します。

Imagine一連のユーザーが C:\Inetput\wwwroot\info\employee.aspx へのWindowsレベルのファイルアクセス権を持っていない場合、そのようなユーザーが /info/employee.aspx?empID=1001 にアクセスしようとすると、承認エラーが発生します。ただし、URL の書き換えを AuthenticateRequest イベントに移動した場合、 FileAuthorizationModule がセキュリティ設定を確認しても、URL はまだ書き換えられていないため、要求されているファイルは /people/ScottMitchell.aspx と見なされます。したがって、ファイル承認チェックが成功し、このユーザーは書き換えられた URL /info/employee.aspx?empID=1001 の内容を表示できます。

では、HTTP モジュールで URL 書き換えを実行する必要があるのはいつですか? 使用している認証の種類によって異なります。認証を使用していない場合、BeginRequest、AuthenticateRequest、または AuthorizeRequest で URL の書き換えが行われるかどうかは関係ありません。フォーム認証を使用していて、Windows 認証を使用していない場合は、AuthorizeRequest イベントハンドラーに URL の書き換えを配置します。最後に、Windows 認証を使用している場合は、BeginRequest イベントまたは AuthenticateRequest イベント中に URL の書き換えをスケジュールします。

HTTP ハンドラーでの URL 書き換え

URL の書き換えは、HTTP ハンドラーまたは HTTP ハンドラーファクトリでも実行できます。 HTTP ハンドラーは、特定の種類の要求のコンテンツを生成するクラスであることを思い出してください。HTTP ハンドラーファクトリは、特定の種類の要求のコンテンツを生成できる HTTP ハンドラーのインスタンスを返すクラスです。

この記事では、ASP.NET Web ページ用の URL 書き換え HTTP ハンドラーファクトリの作成について説明します。 HTTP ハンドラーファクトリは、GetHandler() メソッドを含む IHttpHandlerFactory インターフェイスを実装する必要があります。適切な HTTP モジュールを初期化した後、ASP.NET エンジンは、指定された要求に対して呼び出す HTTP ハンドラーまたは HTTP ハンドラーファクトリを決定します。 HTTP ハンドラーファクトリを呼び出す場合、ASP.NET エンジンは、その HTTP ハンドラーファクトリの GetHandler() メソッドを呼び出して、Web 要求の HttpContext を他の情報と共に渡します。その後、HTTP ハンドラーファクトリは、要求を処理できる IHttpHandler を実装するオブジェクトを返す必要があります。

HTTP ハンドラーを使用して URL の書き換えを実行するために、 GetHandler() メソッドが要求されたパスをチェックして書き換える必要があるかどうかを判断する HTTP ハンドラーファクトリを作成できます。その場合は、前に説明したように、渡された HttpContext オブジェクトの RewritePath() メソッドを呼び出すことができます。最後に、HTTP ハンドラーファクトリは 、System.Web.UI.PageParser クラスの GetCompiledPageInstance() メソッドによって返される HTTP ハンドラーを返すことができます。 (これは、組み込みの ASP.NET Web ページ HTTP ハンドラーファクトリである PageHandlerFactory が機能するのと同じ手法です)。

すべての HTTP モジュールは、カスタム HTTP ハンドラーファクトリがインスタンス化される前に初期化されるため、HTTP ハンドラーファクトリを使用すると、イベントの後半の段階で URL の書き換えを行うときに同じ課題が発生します。つまり、ファイル承認は機能しません。そのため、Windows 認証とファイルの承認に依存している場合は、URL の書き換えに HTTP モジュールアプローチを使用する必要があります。

次のセクションでは、再利用可能な URL 書き換えエンジンの構築について説明します。この記事のコードダウンロードで利用可能な URL 書き換えエンジンの調査に従って、残りの 2 つのセクションで、URL 書き換えの実際の使用方法を調べていきます。まず、URL 書き換えエンジンを使用する方法と、簡単な URL 書き換えの例を見ていきます。その後、書き換えエンジンの正規表現機能の機能を利用して、真に "ハッキング可能" な URL を提供します。

URL 書き換えエンジンの構築

ASP.NET Web アプリケーションで URL 書き換えを実装する方法を説明するために、URL 書き換えエンジンを作成しました。この書き換えエンジンには、次の機能があります。

URL 書き換えエンジンを使用する ASP.NET ページ開発者は、Web.config ファイルで書き換え規則を指定できます。
書き換えルールでは、正規表現を使用して、強力な書き換えルールを使用できます。
URL の書き換えは、HTTP モジュールまたは HTTP ハンドラーを使用するように簡単に構成できます。

この記事では、HTTP モジュールだけで URL の書き換えを調べます。 HTTP ハンドラーを使用して URL の書き換えを実行する方法については、この記事でダウンロードできるコードを参照してください。

URL 書き換えエンジンの構成情報の指定

Web.config ファイル内の書き換え規則の構造を調べてみましょう。まず、HTTP モジュールまたは HTTP ハンドラーを使用して URL の書き換えを実行する場合は、Web.config ファイルで指定する必要があります。ダウンロードでは、Web.config ファイルには、コメントアウトされた 2 つのエントリが含まれています。

<!--
<httpModules>
   <add type="URLRewriter.ModuleRewriter, URLRewriter" 
        name="ModuleRewriter" />
</httpModules>
-->

<!--
<httpHandlers>
   <add verb="*" path="*.aspx" 
        type="URLRewriter.RewriterFactoryHandler, URLRewriter" />
</httpHandlers>
-->

<書き換えに HTTP モジュールを使用するには httpModules> エントリをコメントアウトします。代わりに httpHandlers> エントリをコメントアウト<して、書き換えに HTTP ハンドラーを使用します。

書き換えに HTTP モジュールまたは HTTP ハンドラーを使用するかどうかを指定するだけでなく、Web.config ファイルには書き換え規則が含まれます。書き換えルールは、要求された URL で検索するパターンと、パターンを置き換える文字列 (見つかった場合) の 2 つの文字列で構成されます。この情報は、次の構文を使用して、Web.config ファイルで表されます。

<RewriterConfig>
   <Rules>
   <RewriterRule>
      <LookFor>pattern to look for</LookFor>
      <SendTo>string to replace pattern with</SendTo>
   </RewriterRule>
   <RewriterRule>
      <LookFor>pattern to look for</LookFor>
      <SendTo>string to replace pattern with</SendTo>
   </RewriterRule>
   ...
   </Rules>
</RewriterConfig>

各書き換えルールは、RewriteerRule> 要素によって<表されます。検索するパターンは LookFor> 要素によって<指定され、見つかったパターンを置き換える文字列は SentTo> 要素に<入力されます。これらの書き換えルールは、上から下に評価されます。一致するものが見つかった場合は、URL が書き換えられ、書き換えルールによる検索が終了します。

LookFor> 要素で<パターンを指定する場合は、正規表現を使用して一致と文字列の置換を実行します。 (ここでは、正規表現を使用してパターンを検索する方法を示す実際の例を少し見ていきます)。パターンは正規表現であるため、正規表現で予約文字である文字は必ずエスケープしてください。 (正規表現の予約文字には、.、?、^、$などがあります。これらは、\のような円記号で前に付けることでエスケープできます。リテラル期間に一致します。

HTTP モジュールを使用した URL の書き換え

HTTP モジュールの作成は、 IHttpModule インターフェイスを実装するクラスを作成するのと同じくらい簡単です。 IHttpModule インターフェイスは、次の 2 つのメソッドを定義します。

Init(HttpApplication). このメソッドは、HTTP モジュールが初期化されるときに発生します。このメソッドでは、イベントハンドラーを適切な HttpApplication イベントに関連付けます。
Dispose()。このメソッドは、要求が完了し、IIS に送信されたときに呼び出されます。最終的なクリーンアップはここで実行する必要があります。

URL 書き換え用の HTTP モジュールの作成を容易にするために、抽象基本クラス である BaseModuleRewriter を作成することから始めました。このクラスは IHttpModule を実装します。 Init() イベントでは、HttpApplication の AuthorizeRequest イベントを BaseModuleRewriter_AuthorizeRequest メソッドに接続します。 BaseModuleRewriter_AuthorizeRequest メソッドは、Init() メソッドに渡された HttpApplication オブジェクトと共に、要求された Path を渡すクラスの Rewrite() メソッドを呼び出します。 Rewrite() メソッドは抽象です。つまり、BaseModuleRewriter クラスでは、Rewrite() メソッドにはメソッド本体がありません。代わりに、BaseModuleRewriter から派生するクラスは、このメソッドをオーバーライドし、メソッド本体を提供する必要があります。

この基底クラスを配置すると、Rewrite() をオーバーライドし、そこで URL 書き換えロジックを実行する BaseModuleRewriter から派生したクラスを作成する必要があります。 BaseModuleRewriter のコードを次に示します。

public abstract class BaseModuleRewriter : IHttpModule
{
   public virtual void Init(HttpApplication app)
   {
      // WARNING!  This does not work with Windows authentication!
      // If you are using Windows authentication, 
      // change to app.BeginRequest
      app.AuthorizeRequest += new 
         EventHandler(this.BaseModuleRewriter_AuthorizeRequest);
   }

   public virtual void Dispose() {}

   protected virtual void BaseModuleRewriter_AuthorizeRequest(
     object sender, EventArgs e)
   {
      HttpApplication app = (HttpApplication) sender;
      Rewrite(app.Request.Path, app);
   }

   protected abstract void Rewrite(string requestedPath, 
     HttpApplication app);
}

BaseModuleRewriter クラスが AuthorizeRequest イベントで URL の書き換えを実行することに注意してください。ファイルの承認でWindows 認証を使用する場合は、BeginRequest イベントまたは AuthenticateRequest イベントで URL の書き換えが実行されるように、これを変更する必要があることを思い出してください。

ModuleRewriter クラスは BaseModuleRewriter クラスを拡張し、実際の URL の書き換えを実行します。 ModuleRewriter には、次に示す 1 つのオーバーライドされたメソッド (Rewrite()) が含まれています。

protected override void Rewrite(string requestedPath, 
   System.Web.HttpApplication app)
{
   // get the configuration rules
   RewriterRuleCollection rules = 
     RewriterConfiguration.GetConfig().Rules;

   // iterate through each rule...
   for(int i = 0; i < rules.Count; i++)
   {
      // get the pattern to look for, and 
      // Resolve the Url (convert ~ into the appropriate directory)
      string lookFor = "^" + 
        RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, 
        rules[i].LookFor) + "$";

      // Create a regex (note that IgnoreCase is set...)
      Regex re = new Regex(lookFor, RegexOptions.IgnoreCase);

      // See if a match is found
      if (re.IsMatch(requestedPath))
      {
         // match found - do any replacement needed
         string sendToUrl = 
RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, 
            re.Replace(requestedPath, rules[i].SendTo));

         // Rewrite the URL
         RewriterUtils.RewriteUrl(app.Context, sendToUrl);
         break;      // exit the for loop
      }
   }
}

Rewrite() メソッドは、最初に、Web.config ファイルから一連の書き換えルールを取得します。その後、書き換えルールを一度に 1 つずつ反復処理し、ルールごとに LookFor プロパティを取得し、正規表現を使用して、要求された URL で一致が見つかったかどうかを判断します。

一致するものが見つかった場合は、要求されたパスに対して SendTo プロパティの値を使用して正規表現の置換が実行されます。この置換された URL は、 RewriteerUtils.RewriteUrl() メソッドに渡されます。 RewriterUtils は、URL 書き換え HTTP モジュールと HTTP ハンドラーの両方で使用される静的メソッドをいくつか提供するヘルパークラスです。 RewriteerUrl() メソッドは、HttpContext オブジェクトの RewriteUrl() メソッドを呼び出すだけです。

メモ正規表現の一致と置換を実行するときに、 RewriterUtils.ResolveUrl() の呼び出しが行われていることに気付いたかもしれません。このヘルパーメソッドは、文字列内のすべてのインスタンスをアプリケーションの ~ パスの値に置き換えるだけです。

この記事では、URL 書き換えエンジンのコード全体をダウンロードできます。最もドイツ語的な部分を調べましたが、他にも、Web.config ファイル内の XML 形式の書き換え規則をオブジェクトに逆シリアル化するためのクラスや、URL 書き換え用の HTTP ハンドラーファクトリなどのコンポーネントもあります。この記事の残りの 3 つのセクションでは、URL 書き換えの実際の使用方法について説明します。

URL 書き換えエンジンを使用した単純な URL 書き換えの実行

URL 書き換えエンジンの動作を示すために、単純な URL 書き換えを利用する ASP.NET Web アプリケーションを構築しましょう。 Imagine、各種製品をオンラインで販売する会社で働いています。これらの製品は、次のカテゴリに分類されます。

カテゴリ ID	カテゴリ名
1	飲み物
2	調味料
3	菓子
4	乳製品
...	...

既に ListProductsByCategory.aspx という名前の ASP.NET Web ページが作成されており、クエリ文字列でカテゴリ ID 値を受け取り、そのカテゴリに属するすべての製品が表示されているとします。では、販売のために飲料を表示したいユーザーは ListProductsByCategory.aspx にアクセスしますか?CategoryID=1。酪農製品を表示したいユーザーは ListProductsByCategory.aspx にアクセスしますか?CategoryID=4。また、販売する製品のカテゴリを一覧表示する ListCategories.aspx というページがあるとします。

ユーザーが表示される URL は、ユーザーにとって重要な意味を持たず、"ハッキング可能性" も提供されないため、URL の書き換えの場合は明らかです。代わりに、ユーザーが /Products/Beverages.aspx にアクセスすると、その URL が ListProductsByCategory.aspx に書き換えられるように、URL の書き換えを採用しましょう。CategoryID=1。これは、Web.config ファイル内の次の URL 書き換え規則で実現できます。

<RewriterConfig>
   <Rules>
      <!-- Rules for Product Lister -->
      <RewriterRule>
         <LookFor>~/Products/Beverages\.aspx</LookFor>
         <SendTo>~/ListProductsByCategory.aspx?CategoryID=1</SendTo>
      </RewriterRule>
      <RewriterRule>
   </Rules>
</RewriterConfig>

ご覧のように、このルールでは、ユーザーが要求したパスが /Products/Beverages.aspx であるかどうかを検索します。その場合は、URL を /ListProductsByCategory.aspx として書き換えてください。CategoryID=1。

メモLookFor> 要素は<、Beverages.aspx のピリオドをエスケープします。これは、 <LookFor> 値は正規表現パターンで使用され、ピリオドは正規表現の特殊文字であり、"任意の文字に一致する" ことを意味します。たとえば、/Products/BeveragesQaspx の URL が一致するためです。 (\.を使用して) ピリオドをエスケープすることで、古い文字ではなく、リテラル期間に一致することを示しています。

このルールを設定すると、ユーザーが /Products/Beverages.aspx にアクセスすると、販売対象の飲料が表示されます。図 3 は、/Products/Beverages.aspx にアクセスしているブラウザーのスクリーンショットを示しています。ブラウザーのアドレスバーでは、URL が /Products/Beverages.aspx と読み取られますが、ユーザーには実際には ListProductsByCategory.aspx の内容が表示されていることに注意してください。CategoryID=1。 (実際には、Web サーバーに /Products/Beverages.aspx ファイルもまったく存在しません)。

ms972974.urlrewriting_fig03(en-us,MSDN.10).gif

図 3: URL の書き換え後のカテゴリの要求

/Products/Beverages.aspx と同様に、次に他の製品カテゴリの書き換え規則を追加します。これには、Web.config ファイルの Rules> 要素内に<書き換えツール>要素を追加<するだけです。デモの書き換えルールの完全なセットについては、ダウンロードのWeb.config ファイルを参照してください。

URL をより "ハッキング可能" にするには、ユーザーが単に /Products/Beverages.aspx から Beverages.aspx をハックし、製品カテゴリの一覧を表示できれば便利です。一見すると、これは簡単な作業のように見えることがあります。/Products/ を /ListCategories.aspx にマップする書き換えルールを追加するだけです。ただし、細かい微妙さがあります。最初に /Products/ ディレクトリを作成し、/Products/ ディレクトリに空の Default.aspx ファイルを追加する必要があります。

これらの追加の手順を実行する必要がある理由を理解するには、URL 書き換えエンジンが ASP.NET レベルにあることを思い出してください。つまり、ASP.NET エンジンに要求を処理する機会がない場合、URL 書き換えエンジンが受信 URL を検査する方法はありません。さらに、IIS は、要求されたファイルに適切な拡張子がある場合にのみ、ASP.NET エンジンに受信要求を送信します。そのため、ユーザーが /Products/にアクセスした場合、IIS にはファイル拡張子が表示されないため、ディレクトリをチェックして、既定のファイル名の 1 つを持つファイルが存在するかどうかを確認します。 (Default.aspx、Default.htm、Default.asp など。これらの既定のファイル名は、[IIS 管理] ダイアログボックスの [Web サーバーのプロパティ] ダイアログボックスの [ドキュメント] タブで定義されます)。もちろん、/Products/ ディレクトリが存在しない場合、IIS は HTTP 404 エラーを返します。

そのため、/Products/ ディレクトリを作成する必要があります。さらに、このディレクトリ Default.aspx に 1 つのファイルを作成する必要があります。このようにして、ユーザーが /Products/にアクセスすると、IIS はディレクトリを検査し、Default.aspx という名前のファイルが存在することを確認し、ASP.NET エンジンに処理を渡します。 URL 書き換えツールでは、URL の書き換えに問題が発生します。

ディレクトリと Default.aspx ファイルを作成したら、次の書き換えルールを Rules> 要素に<追加します。

<RewriterRule>
   <LookFor>~/Products/Default\.aspx</LookFor>
   <SendTo>~/ListCategories.aspx</SendTo>
</RewriterRule>

このルールを適用すると、ユーザーが /Products/ または /Products/Default.aspx にアクセスすると、製品カテゴリの一覧が表示されます (図 4 を参照)。

ms972974.urlrewriting_fig04(en-us,MSDN.10).gif

図 4: URL への "ハッキング可能性" の追加

ポストバックの処理

書き換える URL にサーバー側の Web フォームが含まれており、ポストバックを実行する場合、フォームがポストバックするときに、基になる URL が使用されます。つまり、ユーザーがブラウザー /Products/Beverages.aspx に入ると、ブラウザーのアドレスバー /Products/Beverages.aspx に引き続き表示されますが、ListProductsByCategory.aspx のコンテンツが表示されます。CategoryID=1。 ListProductsByCategory.aspx がポストバックを実行すると、ユーザーは ListProductsByCategory.aspx にポストバックされます。CategoryID=1。/Products/Beverages.aspx ではありません。これは何も壊れませんが、ボタンをクリックすると URL が突然変更されるのをユーザーの観点から見ると混乱する可能性があります。

この動作が発生する理由は、Web フォームがレンダリングされるときに、そのアクション属性を Request オブジェクト内のファイルパスの値に明示的に設定するためです。もちろん、Web フォームがレンダリングされる時点で、URL は /Products/Beverages.aspx から ListProductsByCategory.aspx に書き換えられますか?CategoryID=1。 つまり、Request オブジェクトは、ユーザーが ListProductsByCategory.aspx にアクセスしていることを報告していますか?CategoryID=1。この問題は、単にアクション属性をレンダリングしないサーバー側のフォームを持つことで解決できます。 (フォームにアクション属性が含まれていない場合、ブラウザーは既定でポストバックされます)。

残念ながら、Web フォームではアクション属性を明示的に指定することはできません。また、アクション属性のレンダリングを無効にするためのプロパティを設定することもできません。代わりに、 System.Web.HtmlControls.HtmlForm クラスを自分自身で拡張し、 RenderAttribute() メソッドをオーバーライドし、アクション属性をレンダリングしないことを明示的に示す必要があります。

継承の力のおかげで、 HtmlForm クラスのすべての機能を取得でき、必要な動作を実現するためにスキャンされた数行のコードを追加するだけで済みます。カスタムクラスの完全なコードを次に示します。

namespace ActionlessForm {
  public class Form : System.Web.UI.HtmlControls.HtmlForm
  {
     protected override void RenderAttributes(HtmlTextWriter writer)
     {
        writer.WriteAttribute("name", this.Name);
        base.Attributes.Remove("name");

        writer.WriteAttribute("method", this.Method);
        base.Attributes.Remove("method");

        this.Attributes.Render(writer);

        base.Attributes.Remove("action");

        if (base.ID != null)
           writer.WriteAttribute("id", base.ClientID);
     }
  }
}

オーバーライドされた RenderAttributes() メソッドのコードには、 HtmlForm クラスの RenderAttributes() メソッドの正確なコードが含まれていますが、アクション属性は設定されません。 (私はLutz Roederのリフレクターを使用して HtmlForm クラスのソースコードを表示しました)。

このクラスを作成してコンパイルしたら、それを ASP.NET Web アプリケーションで使用するには、まず Web アプリケーションの References フォルダーに追加します。次に、HtmlForm クラスの代わりに使用するには、ASP.NET Web ページの上部に次のコードを追加します。

<%@ Register TagPrefix="skm" Namespace="ActionlessForm" 
   Assembly="ActionlessForm" %>

次に、お持ちの <form runat="server">場所で、次のように置き換えます。

<skm:Form id="Form1" method="post" runat="server">

終了 </form> タグを次のように置き換えます。

</skm:Form>

このカスタム Web フォームクラスは、この記事のダウンロードに含まれている ListProductsByCategory.aspx で実際に確認できます。また、ダウンロードには、アクションレス Web フォームのVisual Studio .NET プロジェクトも含まれています。

メモ書き換える URL がポストバックを実行しない場合は、このカスタム Web フォームクラスを使用する必要はありません。

真に "ハッキング可能な" URL を作成する

前のセクションで示した簡単な URL 書き換えは、URL 書き換えエンジンを新しい書き換え規則で簡単に構成できる方法を示しました。ただし、このセクションで説明するように、正規表現を使用する場合、書き換えルールの真の力が輝きます。

最近、ブログはますます人気が高まり、 誰もが 独自のブログを持っているようです。ブログに慣れていない場合、通常はオンラインジャーナルとして機能する個人用ページが更新されることが多いです。ほとんどのブロガーは、日常の状況について書くだけで、映画のレビュー、スポーツチーム、コンピューター技術など、特定のテーマに関するブログに焦点を当てています。

作成者に応じて、ブログは 1 日に数回から週 2 回まで、どこでも更新されます。通常、ブログのホームページには最新の10のエントリが表示されますが、ほぼすべてのブログソフトウェアは、訪問者が古い投稿を読むことができるアーカイブを提供します。ブログは、"ハッキング可能な" URL に最適なアプリケーションです。 Imagine、ブログのアーカイブを検索しているときに、URL /2004/02/14.aspx で見つかりました。 2004 年 2 月 14 日に行われた投稿を読んでいると、驚くことでしょうか? さらに、2004 年 2 月のすべての投稿を表示することもできます。その場合は、URL を /2004/02/にハッキングしてみてください。 2004 件の投稿をすべて表示するには、/2004/にアクセスしてみてください。

ブログを維持する場合は、このレベルの URL "ハッキング可能性" を訪問者に提供すると便利です。多くのブログエンジンがこの機能を提供していますが、URL の書き換えを使用して実現する方法を見てみましょう。

まず、日、月、または年別にブログエントリを表示する単一の ASP.NET Web ページが必要です。このようなページ ShowBlogContent.aspx があり、クエリ文字列パラメーターの年、月、および日を受け取るとします。 2004 年 2 月 14 日の投稿を表示するには、ShowBlogContent.aspx?year=2004&month=2&day=14 を参照してください。 2004 年 2 月のすべての投稿を表示するには、ShowBlogContent.aspx?year=2004&month=2 にアクセスします。最後に、2004 年のすべての投稿を表示するには、ShowBlogContent.aspx?year=2004 に移動します。 (ShowBlogContent.aspx のコードは、この記事のダウンロードにあります)。

そのため、ユーザーが /2004/02/14.aspx にアクセスした場合、URL を ShowBlogContent.aspx?year=2004&month=2&day=14 に書き換える必要があります。 3 つのケースすべて (URL で年、月、日が指定されている場合)。URL が年と月のみを指定する場合。URL で yes のみが指定されている場合は、次の 3 つの書き換えルールで処理できます。

<RewriterConfig>
   <Rules>
      <!-- Rules for Blog Content Displayer -->
      <RewriterRule>
         <LookFor>~/(\d{4})/(\d{2})/(\d{2})\.aspx</LookFor>
         <SendTo>~/ShowBlogContent.aspx?year=$1&amp;month=$2&amp;day=$3</SendTo>
      </RewriterRule>
      <RewriterRule>
         <LookFor>~/(\d{4})/(\d{2})/Default\.aspx</LookFor>
         <SendTo><![CDATA[~/ShowBlogContent.aspx?year=$1&month=$2]]></SendTo>
      </RewriterRule>
      <RewriterRule>
         <LookFor>~/(\d{4})/Default\.aspx</LookFor>
         <SendTo>~/ShowBlogContent.aspx?year=$1</SendTo>
      </RewriterRule>
   </Rules>
</RewriterConfig>

これらの書き換え規則は、正規表現の力を示しています。最初のルールでは、パターン (\d)/(\d{4})/(\d{2}{2})\.aspx を含む URL を探します。プレーン英語では、4 桁の数字の後にスラッシュが続き、2 桁の数字が続き、スラッシュが続き、2 桁の後に .aspx が続く文字列と一致します。各桁のグループ化を囲むかっこは重要です。これにより、対応する <SendTo> プロパティ内のかっこ内の一致する文字を参照できます。具体的には、1 番目、2 番目、および 3 番目のかっこグループに対してそれぞれ $1、$2、および $3 を使用して、一致するかっこグループを参照できます。

メモWeb.config ファイルは XML 形式であるため、要素のテキスト部分に含まれる、、<>などの&文字をエスケープする必要があります。最初のルールの <SendTo> 要素で、 & amp; に &エスケープされます。 2 番目のルールの <SendTo> では、 <![CDATA[...]]> 要素内の内容をエスケープする必要はありません。どちらの方法でも受け入れ可能であり、同じ終わりを達成します。

図 5、6、7 は、動作中の URL の書き換えを示しています。データは実際に私のブログから引き出されています. http://ScottOnWriting.NET 図 5 では、2003 年 11 月 7 日の投稿を示します。図 6 では、2003 年 11 月のすべての投稿が示されています。図 7 は、2003 年のすべての投稿を示しています。

ms972974.urlrewriting_fig05(en-us,MSDN.10).gif

図 5: 2003 年 11 月 7 日の投稿

ms972974.urlrewriting_fig06(en-us,MSDN.10).gif

図 6: 2003 年 11 月のすべての投稿

ms972974.urlrewriting_fig07(en-us,MSDN.10).gif

図 7: 2003 のすべての投稿

メモURL 書き換えエンジンでは、LookFor> 要素に正規表現パターンが<必要です。正規表現に慣れていない場合は、前の記事「正規表現の概要」を参照することを検討してください。また、一般的に使用される正規表現や、独自の細工された正規表現を共有するためのリポジトリを手に入れるのに最適な場所が RegExLib.com。

必要なディレクトリ構造の構築

/2004/03/19.aspx に対して要求が送信されると、IIS は .aspx 拡張機能をメモし、要求を ASP.NET エンジンにルーティングします。要求が ASP.NET エンジンのパイプラインを通過すると、URL が ShowBlogContent.aspx?year=2004 month=03&day=19 に書き換えられ、訪問者には 2004&年 3 月 19 日のブログエントリが表示されます。しかし、ユーザーが /2004/03/に移動するとどうなりますか? ディレクトリ /2004/03/がない限り、IIS は 404 エラーを返します。さらに、要求が ASP.NET エンジンに渡されるように、このディレクトリに Default.aspx ページが必要です。

そのため、この方法では、ディレクトリに Default.aspx ページを含むブログエントリがある年ごとに手動でディレクトリを作成する必要があります。さらに、各年のディレクトリでは、Default.aspx ファイルを含む 12 個のディレクトリ (01、02、..、12) を手動で作成する必要があります。 (前のデモでは、/Products/ にアクセスして ListCategories.aspx が正しく表示されるように、Default.aspx ファイルを含む /Products/ ディレクトリを追加するなど、同じことを行う必要があったことを思い出してください)。

明らかに、このようなディレクトリ構造を追加することは痛みになる可能性があります。この問題の回避策は、すべての受信 IIS 要求を ASP.NET エンジンにマップすることです。このようにして、URL /2004/03/にアクセスした場合でも、IIS は /2004/03/ ディレクトリが存在しない場合でも、ASP.NET エンジンに要求を忠実に渡します。ただし、この方法を使用すると、ASP.NET エンジンは、画像、CSS ファイル、外部 JavaScript ファイル、Macromedia Flash ファイルなど、Web サーバーへのすべての種類の受信要求を処理します。

すべてのファイルの種類の処理に関する徹底的な説明は、この記事の範囲をはるかに超えています。ただし、この手法を使用する ASP.NET Web アプリケーションの例については、次を参照してください。テキスト。オープンソースのブログエンジンです。 .テキストは、すべての要求を ASP.NET エンジンにマップするように構成できます。一般的な静的ファイルの種類 (イメージ、CSS ファイルなど) を処理する方法を認識するカスタム HTTP ハンドラーを使用して、すべてのファイルの種類を処理できます。

まとめ

この記事では、HttpContext クラスの RewriteUrl() メソッドを使用して、ASP.NET レベルで URL 書き換えを実行する方法について説明しました。見たように、 RewriteUrl() は特定 の HttpContext のRequest プロパティを更新し、要求されているファイルとパスを更新します。実際には、ユーザーの観点から、特定の URL にアクセスしていますが、実際には Web サーバー側で別の URL が要求されているということです。

URL は、HTTP モジュールまたは HTTP ハンドラーで書き換えることができます。この記事では、HTTP モジュールを使用して書き換えを実行し、パイプラインのさまざまな段階で書き換えを実行した結果を調べました。

もちろん、ASP.NET レベルの書き換えでは、要求が IIS から ASP.NET エンジンに正常に渡された場合にのみ、URL の書き換えが行われます。これは、ユーザーが .aspx 拡張子を持つページを要求したときに自然に発生します。ただし、実際には存在しない可能性がある URL を入力できるようにしたいが、既存の ASP.NET ページに書き換える場合は、モックディレクトリと Default.aspx ページを作成するか、すべての受信要求が ASP.NET エンジンに盲目的にルーティングされるように IIS を構成する必要があります。

ASP.NET: ヒント、チュートリアル、およびコード

Microsoft ASP.NET チームでコーディング戦略をMicrosoft ASP.NET する

C の例に関する重要な ASP.NET#

相談された作品

URL の書き換えは、ASP.NET と競合するサーバー側 Web テクノロジの両方で大きな注目を集めているトピックです。たとえば、Apache Web サーバーには、mod_rewriteと呼ばれる URL 書き換え用のモジュールが用意されています。 mod_rewriteは堅牢な書き換えエンジンであり、HTTP ヘッダーやサーバー変数などの条件に基づく書き換えルールと、正規表現を使用する書き換えルールを提供します。 mod_rewriteの詳細については、「 Apache Web Server での URL 書き換えに関するユーザーガイド」を参照してください。

ASP.NET を使用した URL の書き換えに関する記事がいくつかあります。 Rewrite.NET - .NET 用 URL 書き換えエンジンは、mod_rewriteの正規表現規則を模倣する URL 書き換えエンジンの作成を調べます。 ASP.NET を使用した URL 書き換えでは、ASP.NET の URL 書き換え機能の概要も確認できます。 Ian Griffiths には、この記事で説明するポストバックの問題など、ASP.NET での URL の書き換えに関連するいくつかの注意事項に関するブログエントリがあります。 Fabrice Marguerie (続きを読む) と Jason Salas (続きを読む) には、URL の書き換えを使用して検索エンジンの配置を向上させるブログ全体があります。

筆者について

5 冊の書籍の著者であり、4GuysFromRolla.com の創始者である Scott Mitchell は、過去 5 年間 Microsoft Web テクノロジと協力してきました。 Scott は、独立したコンサルタント、トレーナー、ライターとして働いています。彼は彼のブログで mitchell@4guysfromrolla.com 、または彼のブログを介して到達することができます, で見つけることができます http://ScottOnWriting.NET.

ASP.NET での URL の書き換え

内容

はじめに

URL 書き換えの一般的な用途

要求が IIS に到達した場合の動作

ISAPI フィルターを使用した要求の確認

要求が ASP.NET エンジンに入った場合の動作

カスタム HTTP モジュールと HTTP ハンドラーの作成と登録

URL 書き換えの実装

HTTP モジュールを使用した URL の書き換え

HTTP ハンドラーでの URL 書き換え

URL 書き換えエンジンの構築

URL 書き換えエンジンの構成情報の指定

HTTP モジュールを使用した URL の書き換え

URL 書き換えエンジンを使用した単純な URL 書き換えの実行

ポストバックの処理

真に "ハッキング可能な" URL を作成する

必要なディレクトリ構造の構築

まとめ

相談された作品

その他のリソース

その他のリソース