要求処理の管理

Caching Proxy はクライアント要求を受信すると、要求されたメソッドが使用可能であれば、 URL フィールドに指定されたオブジェクト上のメソッド・フィールドで指定されたアクションを実行します。 プロキシー・サーバーは管理者が定義したマッピング・ルール・セットに従って URL を変換します。 これらのマッピング・ルールによって、Caching Proxy を Web サーバーとして機能させ、 ローカル・ファイル・システムのオブジェクトを検索するように指示したり、 あるいはプロキシー・サーバーとして機能させ、起点サーバーのオブジェクトを検索するように指示したりできます。

このでは、メソッドを使用可能にする方法マッピング・ルールを定義する方法、および代理プロキシー・サーバーを構成する方法について説明します。

HTTP/FTP メソッドを使用可能にする

クライアントがサーバーに送信する要求には、指定されたオブジェクトでサーバーが実行するアクションを示すメソッド・フィールドが含まれています。

以下に、プロキシー・サーバーがサポートするメソッドのリストを示し、メソッドが使用可能にされている場合にそのメソッドを含むクライアント要求に対して、どのように応答するかについて説明します。

注:
メソッドの中には HTTP の場合でも FTP 要求の場合でも同じものがあります。これらのメソッドを HTTP に対して使用可能にすると、FTP に対しても使用可能になります。

CONNECT
CONNECT メソッドを使用すると、 要求および応答をプロキシー・サーバー経由でトンネルすることができます。 これは、フォワード・プロキシー構成にのみ適用されます。

Enable CONNECT メソッドのフォーマット および使用可能なオプションについては、 SSL トンネリングの構成を参照してください。

DELETE
プロキシー・サーバーが、URL によって識別されたオブジェクトを削除します DELETE によって クライアントは Caching Proxy からファイルを消去することができます。サーバー保護セットアップを使用して、 だれがどのファイルに DELETE を使用できるかを定義します。詳しくは、サーバー保護セットアップを参照してください。
GET
プロキシー・サーバーは、URL によって識別されるすべてのデータを戻します。URL が実行可能なプログラムを参照すると、プロキシーはそのプログラムの出力を戻します。 このメソッドは、パーシスタント接続の間、取り扱うことができます。
HEAD
プロキシー・サーバーは URL によって識別される HTTP 文書ヘッダーだけを戻し、文書本文は戻しません。
OPTIONS
プロキシー・サーバーは、URL によって識別される要求応答チェーンの通信オプションに関する情報を戻します。 このメソッドを使用すると、クライアントは、オブジェクトを処理したり検索しなくても、そのオブジェクトと関連したオプションと要件、またはサーバーの能力を判別することができます。
POST
要求にはデータおよび URL が含まれます。プロキシー・サーバーは、要求に含まれているデータについて、 そのデータを処理する URL で識別されたリソースの新しい従属データとして受け入れます。 リソースとしては、データを受け入れるプログラム、他のプロトコルなどへのゲートウェイ、 または注釈を受け入れる別個のプログラムが考えられます。

POST メソッドは、既存のリソースの注釈を扱うように設計されています。例には、掲示板、ニュースグループ、メーリング・リスト、または同様なリソースの グループに対するメッセージの送付、データ・ブロックの提供 (例えば、フォーム からデータ処理プログラムへ)、あるいは付加操作による データベースの拡張が含まれます。 Caching Proxy では、POST メソッドは「構成および管理」フォームを処理するために使用されます。

このメソッドは、パーシスタント接続の間、取り扱うことができます。

PUT
要求にはデータおよび URL が含まれます。プロキシー・サーバーは URL で識別されたリソースにデータを保管します。リソースが既に存在していれば、PUT はそれを要求に含まれるデータで置き換えます。リソースが存在しない場合には、PUT はそれを作成して、要求に含まれるデータをそれに移植します。 このメソッドは、パーシスタント接続の間、取り扱うことができます。

PUT メソッドを使用可能にすると、HTTP および FTP を使用して、Caching Proxy にファイルを書き込むことができます。 PUT によってクライアントが Caching Proxy に書き込むことができるため、サーバー保護設定を使用して、PUT を使用できる担当者および PUT を使用できるファイルを定義する必要があります。 (サーバー保護セットアップを参照してください)

TRACE
プロキシー・サーバーは、クライアントが送信した要求メッセージをエコーします。このメソッドを使用すると、クライアントは、要求チェーンの他方の端で受信されているデータを見ることができ、そのデータをテストや診断に使用することができます。 プロキシー応答のコンテンツ・タイプは message/http です。

関連するディレクティブ

以下のディレクティブで HTTP/FTP メソッドを使用可能にします。

詳細については、ibmproxy.conf ファイルの手作業での編集を参照してください。

構成および管理フォーム

以下の「構成および管理」フォームを使用して関連するディレクティブの値を編集します。

注:
POST メソッドを使用不可にすると、「構成および管理」フォームを使用して Caching Proxy を構成することはできなくなります。

詳細については、「構成および管理」フォームの使用を参照してください。

WebDAV メソッド、MS Exchange メソッド、 およびユーザー定義のメソッドを使用可能にする

これは、リバース・プロキシー構成にのみ適用されます。

Caching Proxy では、標準 HTTP メソッドのサポートがあるほか、 RFC で定義されたメソッドや、なんらかのアプリケーションで使用されるメソッドなど、 その他のメソッドの転送もサポートしています。 また、Caching Proxy は、カスタマー定義のメソッドもサポートしており、 プロキシー・サーバー経由でそれらのメソッドを転送することもできます。

Web-based Distributed Authoring and Versioning (WebDAV) は、 HTTP プロトコルへの拡張セットです。 この拡張セットを使用すると、 リモート Web サーバー上でファイルの編集と管理を円滑に行うことができます。 Caching Proxy は、WebDAV メソッド、Microsoft Exchange Server で使用されるメソッド、 およびユーザー定義 (カスタマイズ) メソッドをサポートしています。

これらのメソッドは、ハードコーディングされており、 Enable ディレクティブと Disable ディレクティブによって管理します。 管理者は、PROTECT ディレクティブで定義された、 対応するメソッド・マスクを使用して、これらのメソッドの使用を許可することもできます。

サポートされる WebDAV メソッド (RFC 2518): PROPFIND、PROPPATCH、MKCOL、COPY、MOVE、LOCK、UNLOCK、SEARCH

サポートされる MS Exchange メソッド: BMOVE、BCOPY、BDELETE、BPROPFIND、BPROPPATCH、POLL、NOTIFY、 SUBSCRIBE、UNSUBSCRIBE、ACL、SUBSCRIPTIONS、X_MS_ENUMATTS

WebDAV メソッドまたは MS Exchange Server メソッドが有効であると、 Caching Proxy は、要求をターゲット・サーバーにのみ転送し、 要求本体にリソース・リンクを再書き込みすることはありません。

また、Caching Proxy は、 ユーザー定義のメソッドをバックエンド・サーバーに転送することもできます。 ibmproxy.conf ファイルで Enable ディレクティブの以下の構文を使用すると、 カスタマイズ・メソッドを使用可能にできます。

Enable   user-defined-method [WithBody | WithoutBody]
WithBody

または WithoutBody の値を設定して、 ユーザー定義メソッドが要求本体を必要とするかどうかをプロキシーに指示します。

次の例では、ユーザー定義メソッド My_METHOD を有効にしており、 そのメソッドが要求本体を必要とすることをプロキシーに指示しています。

Enable MY_METHOD WithBody

関連するディレクティブ

以下のディレクティブで、WebDAV メソッド、MS Exchange メソッド、 およびユーザー定義メソッドを有効にします。

詳細については、ibmproxy.conf ファイルの手作業での編集を参照してください。

マッピング・ルールの定義

マッピング・ルールはクライアント要求を、例えば起点サーバーに (代行して) 渡す、 リダイレクトする、拒否するなど、何らかの方法で Caching Proxy に処理させる構成ディレクティブです。 Caching Proxy を適切に機能させるためには、マッピング・ルールを正しく設定することが重要です。マッピング・ルールが影響を与えるのは、以下の機能です。

マッピング・ルール・ディレクティブは次のような形式を使用します。

rule template target [IP_address | host_name]:[port]

指定のテンプレートと IP ポートの組み合わせに一致する要求だけが、そのルールの対象となります。 テンプレートには、例えば https://**/*.asp のように、ワイルドカードを入れることができます。

構成ファイルでルールが現れる順序は、重要です。 Map ディレクティブを除いて、要求はテンプレートに一致するとすぐに処理され、後のルールは評価されません。 Map ディレクティブは、要求にある URL を置き換えます。この新規の要求が、引き続き残りのマッピング・ルールと比較されます。

マッピング・ルール

以下のマッピング・ルールは、指定のテンプレートと一致するクライアント要求に適用されます。

以下のマッピング・ルールは、起点サーバーの応答に適用されます。

以下のマッピング・ルールは、API アプリケーションに適用されます。

サロゲート・サーバーの構成

標準サロゲートを構成するには、次のようにします。

これにより、起点サーバーに対する、ポート 80 のすべての HTTP トラフィックが代行されます。 管理ポートに入ったトラフィックは、初期のワイルドカード・プロキシー・ルールとは突き合わされないため、 影響を受けません。要求は、残りのマッピング・ルールを使用して処理されます。

関連するディレクティブ

以下のディレクティブでマッピング・ルールを定義します。

詳細については、ibmproxy.conf ファイルの手作業での編集を参照してください。

構成および管理フォーム

以下の「構成および管理」フォームを使用して関連するディレクティブの値を編集します。

注:
「構成および管理」フォームでは、ポート番号引数をサポートしていません。

詳細については、「構成および管理」フォームの使用を参照してください。

ジャンクション再書き込みの使用可能化 (オプショナル)

これは、リバース・プロキシー構成にのみ適用されます。

JunctionRewrite ディレクティブにより、Caching Proxy 内の ジャンクション再書き込みルーチンは、発信元サーバーからの応答を再書き 込みし、ジャンクションが使用された場合にサーバーに関連した URL が適切な発信元サーバーにマップされるようにします。 ジャンクション再書き込みプラグインも使用可能にする必要があります。ジャンクションは、プロキシー・マッピング・ルールによって定義されます。

プロキシー・マッピング規則を使用してジャンクションを定義するときは、 JunctionPrefix オプションを使用する場合も、しない場合も、Proxy ディレクティブを使用できます。

JunctionPrefix オプションを使用しないジャンクションの定義

以下は、ジャンクション再書き込みルーチンによって行われる、有効なジャンクションの例です。

以下は、ジャンクション再書き込みルーチンが作用しない、有効なジャンクションの例です。

以下は、無効なジャンクションの例です。

これらのマッピング・ルールでは、shopserver、authserver、および b2bserver 用のジャンクションが作成されています。 該当する HTML タグ内に、以下の URL が含まれた HTML 文書を shopserver が戻すものとします。

ジャンクション再書き込みルーチンは、以下のように、プロキシー・マッピング・ルールを使用して、サーバー相対参照を再書き込みします。

JunctionPrefix オプションを使用するジャンクションの定義 (推奨される方法)

JunctionPrefix オプションを Proxy ディレクティブと併用するときは、 Proxy 規則内の最初の URL パターンから JunctionPrefix を割り出すようにする代わりに、 次のフォーマットを用いて、Proxy 規則内でジャンクションの接頭部を宣言することができます。

Proxy url_patern1 url_pattern2 JunctionPrefix:url_prefix

JunctionPrefix を使用しているときは、 最初の URL パターンのフォーマットに制限はありません。 JunctionPrefix オプションを使用していないときに ジャンクションの再書き込みをサポートするには、プロキシー URL は次のフォ ーマットを持つ必要があります。Proxy /market/* http://b2bserver/*。 しかし、JunctionPrefix の使用時は、次の Proxy 規則がジャンクション 再書き込みにおいて有効です。

Proxy  /market/partners/*.html http://b2bserver.acme.com/*.html
       junctionprefix:/market/partners

ジャンクション再書き込みルーチンは、以下のタグに影響を与えます。

表 3. ジャンクション再書き込みルーチンによって影響されるタグ
タグ 属性
!— URL
a href
applet archive、codebase
area href
base href
body background
del cite
embed pluginspage
form action
input src
frame src、longdesc
iframe src、longdesc
ilayer src、background
img src、usemap、lowsrc、longdesc、dynsrc
layer src、background
link href
meta url
object data、classid、codebase、codepage
script src
table background
td background
th background
tr background
注:
ジャンクション再書き込みルーチンは、JavaScript またはブラウザー内のプラグインによって生成されたタグには影響を与えません。

関連するディレクティブ

以下のディレクティブは、ジャンクション再書き込みルーチンおよびプラグインを使用可能にするために使用されます。

詳細については、ibmproxy.conf ファイルの手作業での編集を参照してください。

構成および管理フォーム

以下の「構成および管理」フォームを使用して、ジャンクション再書き込みプラグインを使用可能にすることができます。

注:
「構成および管理」フォームは、JunctionRewrite ディレクティブをサポートしていません。

詳細については、「構成および管理」フォームの使用を参照してください。

JunctionRewrite に代わる UseCookie

次のように、Cookie を使用して、バックエンド・サーバー情報を保管できます。 Cookie は、クライアント・ブラウザーに送信されます。ブラウザーが HTML ページのリソースに要求を送信すると、 Cookie が添付されるため、Caching Proxy は要求を正しいバックエンド・サーバーに転送します。

JunctionRewrite の代わりに Cookie を使用する場合は、ibmproxy.conf ファイルを 次のように変更します。

  1. JunctionRewrite on」を「JunctionRewrite on UseCookie」に変更します。
  2. JunctionRewrite プラグインをコメント化します。

以下は、JunctionRewrite プラグインと Cookie の実装の比較です。

JunctionRewrite 機能を拡張する Transmogrifier プラグインのサンプル

HTML ファイル内の JavaScript™ (SCRIPT) およびアプレット (APPLET) タグ・ブロックを再書き込みおよび構文解析する、カスタマイズ可能なサンプル・コードが提供されています。JunctionRewrite プラグインは、JavaScript 内または Java™ のパラメーター値へのリソース・リンクを単独で処理することはできません。

Caching Proxy をインストールした後は、同じコードをコンパイルおよび構成し、JunctionRewrite で実行することができます。

次のサンプル・ファイルは、フィックスパックをダウンロードしたディレクトリー内の ...samples/cp/ サブディレクトリーに配置されています。