Web サイトのルールとグローバル Web 設定

Web サイトルールは、Web サイトの編成を保つために使用する文書です。それらは、Web サイト文書への返答文書として表示され、該当する Web サイトにだけ適用されます。複数の Web サイトにルールを適用するには、Web サイトから別の Web サイトにルール文書をコピーして貼り付けます。

Web サイトルールには 2 つの主要な用途があります。

  • サイトの実際の物理的な編成にとらわれずに、一貫したユーザーフレンドリな Web サイトのナビゲーションスキームを作成する。
  • 既存のリンクやブラウザーのブックマークなどを壊すことなく、サイトの各部を再配置または再編成する。

着信 URL に対して Web サイトルールを適用する前に、着信 URL は、事前に定義されたフィルタルールと有効性検査ルール、プロシージャに基づいて正規化されます。これらのプロシージャにより、着信 URL は安全な形式に変換されてから、処理を行うアプリケーションに渡されます。URL が正規化されると、HTTP タスクは、Web サイトのために定義されたルールに照らし合わせて、URL に対して何らかの変更を加える必要があるかどうかを判別します。

注: パターンの検索では、URL パスだけが使用されます。照会文字列は、アプリケーションが使用するときのために保存されます。[受け取る URL パターン] フィールドに指定するパターンには、ホスト名や照会文字列を含めることはできません。

ルールには、以下の 4 種類があります。1 つの Web サイト文書に対して複数のタイプの Web サイトルールが定義されている場合、ルール文書は以下の順序で適用されます。

  • 置換
  • リダイレクト
  • ディレクトリー
  • HTTP 応答ヘッダー

置換ルール

置換ルールは、受信した URL の 1 つまたは複数個の部分を新しい文字列に置き換えます。Web サイトの編成を変更したいものの Web サイト内のすべてのリンクを書き直したくはない場合や、複雑な URL にユーザーフレンドリーな別名を与えたい場合は、置換ルールを使用します。

たとえば、置換ルールは、運用中の Web サイトの多数のファイルを 1 つのディレクトリーから別のディレクトリーに移動した場合などに効果的です。古いディレクトリーを参照するすべてのリンクを修正しなくても、置換ルールを使用すれば、古いディレクトリーを新しいディレクトリーにマッピングできます。

置換ルールに指定する着信パターンと置換パターンには、それぞれ最低 1 つのワイルドカードを指定する必要があります。パターンにワイルドカードが明示的に含まれていない場合は、HTTP タスクが内部テーブルにルールを格納するときに、自動的に /* がパターンに追加されます。

リダイレクトルール

リダイレクトルールは、着信 URL を他の URL にリダイレクトします。リダイレクトルールには、外部リダイレクトと内部リダイレクトの二種類があります。外部リダイレクトルールは、ブラウザーにより要求されたファイルまたは他のリソースが別の URL に置かれていることを、要求元のブラウザーに通知します。着信 URL パスが外部リダイレクトルールに一致した場合、HTTP タスクは、リダイレクトパターンに基づいて新しい URL を生成し、生成した URL を即時にブラウザーに返送します。外部リダイレクトルールを使用すると、既存のリンクやブックマークを無効にすることなく、新しいブックマークに新しいロケーションを参照させることができます。

内部リダイレクトルールは置換ルールと同じように機能するため、HTTP タスクは新しい URL を生成し、生成した URL を再び正規化します。ただし、相違点が 2 つほどあります。まず、第一に、リダイレクトテーブルは再帰的に検索されるため、複数のリダイレクトルールを定義およびネスト化できます。第二に、内部リダイレクトルールではワイルドカード文字の使用は求められていません。このため、URL パスに対して完全一致検索を適用する場合は、置換ルールの代わりに内部リダイレクトルールを使用できます。

着信 URL パスが内部リダイレクトルールに一致する場合、HTTP タスクは新しいパスを生成し、生成したパスを正規化し、リダイレクトルールテーブルを再度検索します。HTTP タスクはリダイレクトルールテーブルに対して再帰的に検索を実行するため、既に実行された置換やリダイレクトに関わりなく、URL をキャプチャする広範囲なリダイレクトルールを定義できます。

注: 検索を再帰的に実行するということは、相互に一致する複数のルールを定義すると、無限ループが発生する可能性があることを意味します。この可能性を回避するために、HTTP タスクには 10 回という再帰回数の制限が組み込まれています。

リダイレクトルールではワイルドカードが使用可能ですが、必須ではありません。

ディレクトリー・ルール

ディレクトリー・ルールは、ファイルシステムディレクトリーを URL パターンにマッピングします。Web サーバーがパターンに一致する URL を受け取ると、サーバーは、URL によりディレクトリー内のリソースが要求されているものと解釈します。

Domino® Web サーバーをインストールすると、いくつかのファイルリソースディレクトリーが自動的に作成されます。これらのデフォルトディレクトリーは、Web サイト文書の [設定] タブで事前に定義されたディレクトリー・ルールによりマッピングされます。Web サーバーが起動すると、それらのディレクトリーを URL パターンにマッピングするための内部ルールが自動的に作成されます。デフォルトのディレクトリーは、以下の 3 つです。

  • 非グラフィックファイル用の HTML ディレクトリ
  • GIF などのグラフィック画像用の Icon ディレクトリ
  • CGI プログラム用の CGI ディレクトリ

ディレクトリー・ルールは、直接読み取る形式のファイル (HTML ファイルやグラフィックファイルなど)、およびオペレーティングシステムにより読み込みおよび実行する実行可能プログラム (CGI プログラムなど) のロケーションをマッピングする場合にのみ使用します。Domino® データベースや Java サーブレットなど、他のタイプのリソースのロケーションをマッピングするためには使用できません。

ディレクトリ Web サイトルールを定義する際、ファイルシステムディレクトリーに対して参照アクセスまたは実行アクセスを指定します。ここで適切なアクセス権を選択するのは、非常に重要なことです。CGI プログラムが含まれるディレクトリーにのみ実行アクセスを選択します。それ以外のディレクトリーには参照アクセスを選択してください。適切でないアクセスレベルを指定すると、予期せぬ結果が生じる恐れがあります。たとえば、CGI ディレクトリーに対して参照アクセスを指定した場合、ある CGI プログラムの URL がブラウザーのユーザーから送信されると、サーバーはプログラムを実行する代わりにプログラムのソースコードを返送してしまい、重大なセキュリティ欠陥になりかねません。

ディレクトリー・ルールにより、オペレーティングシステムが適用するファイルアクセス許可が上書きされることはありません。

注: アクセスレベルは、指定されたディレクトリーの下にあるすべてのサブディレクトリーにも継承されます。

HTTP 応答ヘッダールール

すべての HTTP ブラウザ要求とサーバー応答の先頭には、送信する対象のデータについて説明した一連のヘッダーが付けられています。HTTP 応答ヘッダールールを使用すると、アプリケーションの設計者は、Domino® が送信するヘッダー (Expires ヘッダーや、HTTP 応答に対するカスタムヘッダーなど) を、指定された URL パターンに一致する要求への応答を使用してカスタマイズできます。

応答ルールを使用する最も重要な目的は、ブラウザキャッシュのパフォーマンスを向上させることです。アプリケーションの設計者は、ヘッダーを追加して、キャッシュに入れられているデータの揮発性に関して重要な情報をブラウザーに提供できます。

キャッシュに入れられるヘッダーには、Last-Modified ヘッダー、Expires ヘッダー、Cache-Control ヘッダーが含まれます。Last-Modified ヘッダーは、応答を生成するためにリソースが最後に変更された日時を提供します。Expires ヘッダーは、リソースが次回変更される予定の日時をブラウザーに提供します。設計者は、リソースを変更する予定の日時を記述した Expires ヘッダーを応答に追加するためにルールを定義できます。Cache-Control ヘッダーは、ブラウザキャッシュやプロキシサーバーキャッシュに対する明示的な指示を提供します。たとえば、キャッシュに入れない応答には「no-cache」、キャッシュには入れるが特定のブラウザー設定に固有の応答には「private」という指示を出します。

応答ルールを使用して、ヘッダーをカスタマイズすることもできます。たとえば、ユーザーがアプリケーションへのアクセス権を有していない場合に特定のエラーメッセージを表示する、カスタムヘッダー用の応答ルールを作成できます。

他の Web サイトルールとは異なり、応答ルールは、HTTP タスクが応答をブラウザーに送信する直前に、送信メッセージに適用されます。応答ヘッダールールの場合、置換ルールとリダイレクトルールが適用された後で、最終的な形式の URL に対してパターンが検索されます。たとえば、/help/*/support.nsf/helpview/* に変換する置換ルールが定義されている場合、応答メッセージに一致する応答ルールを定義するには、パターンを /support.nsf/helpview/* にする必要があります。

URL パターンには、ワイルドカード文字としてアスタリスクを使用できます。たとえば、/*/catalog/*.htm と指定すると、/petstore/catalog/food.htm や /clothing/catalog/clothing/catalog/thumbnails.htm などの URL が該当します。ワイルドカードの使用は、応答ルールでは必須ではありません。当然のことながら、/cgi-bin/account.pl など、特定のリソースに対して適用されるルールを定義することもできます。また、他のルールと同じですが、着信パターンに照会文字列を含めることはできません。

応答ヘッダールールは、他のルールと異なる点として、URL パターンだけでなく HTTP 応答ステータスコードも突き合わせられます。そのため、HTTP 応答コードフィールドには 1 つまたは複数のステータスコードを指定する必要があります。

グローバル Web 設定

グローバル Web 設定では、Web ルールを複数の Web サイトに適用できます。最初に、グローバル Web 設定文書に名前を付け、グローバル Web 設定を適用するサーバーを指定します。次に、グローバル Web 設定文書用の Web ルール文書を作成します。定義された Web ルールは、グローバル Web 設定文書で指定されたサーバーで運営されているすべての Web サイトに適用されます。

グローバル Web 設定文書と関連する Web サイトルール文書は、自動的には作成されません。グローバル Web 設定文書と Web サイトルールは、Web 環境で使用する場合、手動で作成する必要があります。