Caching Proxy はクライアント要求を受信すると、要求されたメソッドが使用可能であれば、 URL フィールドに指定されたオブジェクト上のメソッド・フィールドで指定されたアクションを実行します。 プロキシー・サーバーは管理者が定義したマッピング・ルール・セットに従って URL を変換します。 これらのマッピング・ルールによって、Caching Proxy を Web サーバーとして機能させ、 ローカル・ファイル・システムのオブジェクトを検索するように指示したり、 あるいはプロキシー・サーバーとして機能させ、起点サーバーのオブジェクトを検索するように指示したりできます。
このトピックでは、メソッドを使用可能にする方法、マッピング・ルールを定義する方法、および代理プロキシー・サーバーを構成する方法について説明します。
クライアントがサーバーに送信する要求には、指定されたオブジェクトでサーバーが実行するアクションを示すメソッド・フィールドが含まれています。
以下に、プロキシー・サーバーがサポートするメソッドのリストを示し、メソッドが使用可能にされている場合にそのメソッドを含むクライアント要求に対して、どのように応答するかについて説明します。
Enable CONNECT メソッドのフォーマットおよび使用可能なオプションについては、 SSL トンネリングの構成を参照してください。
POST メソッドは、既存のリソースの注釈を扱うように設計されています。例には、掲示板、ニュースグループ、メーリング・リスト、または同様なリソースの グループに対するメッセージの送付、データ・ブロックの提供 (例えば、フォーム からデータ処理プログラムへ)、あるいは付加操作による データベースの拡張が含まれます。 Caching Proxy では、POST メソッドは「構成および管理」フォームを処理するために使用されます。
このメソッドは、持続接続の間、取り扱うことができます。
PUT メソッドを使用可能にすると、HTTP および FTP を使用して、Caching Proxy にファイルを書き込むことができます。 PUT によってクライアントが Caching Proxy に書き込むことができるため、サーバー保護設定を使用して、PUT を使用できる担当者および PUT を使用できるファイルを定義する必要があります。 (サーバー保護セットアップを参照してください)
以下のディレクティブで HTTP/FTP メソッドを使用可能にします。
詳細については、ibmproxy.conf ファイルの手作業での編集を参照してください。
以下の「構成および管理」フォームを使用して関連するディレクティブの値を編集します。
詳細については、「構成および管理」フォームの使用を参照してください。
これは、リバース・プロキシー構成にのみ適用されます。
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 アプリケーションに適用されます。
標準サロゲートを構成するには、次のようにします。
Port 80
Proxy /* http://our.content.server.com/* :80
AdminPort 8080
これにより、起点サーバーに対する、ポート 80 のすべての HTTP トラフィックが代行されます。 管理ポートに入ったトラフィックは、初期のワイルドカード・プロキシー・ルールとは突き合わされないため、 影響を受けません。要求は、残りのマッピング・ルールを使用して処理されます。
以下のディレクティブでマッピング・ルールを定義します。
詳細については、ibmproxy.conf ファイルの手作業での編集を参照してください。
以下の「構成および管理」フォームを使用して関連するディレクティブの値を編集します。
詳細については、「構成および管理」フォームの使用を参照してください。
これは、リバース・プロキシー構成にのみ適用されます。
JunctionRewrite ディレクティブにより、Caching Proxy 内の ジャンクション再書き込みルーチンは、発信元サーバーからの応答を再書き 込みし、ジャンクションが使用された場合にサーバーに関連した URL が適切な発信元サーバーにマップされるようにします。 ジャンクション再書き込みプラグインも使用可能にする必要があります。ジャンクションは、プロキシー・マッピング・ルールによって定義されます。
プロキシー・マッピング規則を使用してジャンクションを定義するときは、 JunctionPrefix オプションを使用する場合も、しない場合も、Proxy ディレクティブを使用できます。
以下は、ジャンクション再書き込みルーチンによって行われる、有効なジャンクションの例です。
以下は、ジャンクション再書き込みルーチンが作用しない、有効なジャンクションの例です。
以下は、無効なジャンクションの例です。
これらのマッピング・ルールでは、shopserver、authserver、および b2bserver 用のジャンクションが作成されています。 該当する HTML タグ内に、以下の URL が含まれた HTML 文書を shopserver が戻すものとします。
ジャンクション再書き込みルーチンは、以下のように、プロキシー・マッピング・ルールを使用して、サーバー相対参照を再書き込みします。
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
ジャンクション再書き込みルーチンは、以下のタグに影響を与えます。
タグ | 属性 |
---|---|
!— | 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 |
以下のディレクティブは、ジャンクション再書き込みルーチンおよびプラグインを使用可能にするために使用されます。
詳細については、ibmproxy.conf ファイルの手作業での編集を参照してください。
以下の「構成および管理」フォームを使用して、ジャンクション再書き込みプラグインを使用可能にすることができます。
詳細については、「構成および管理」フォームの使用を参照してください。
次のように、Cookie を使用して、バックエンド・サーバー情報を保管できます。 Cookie は、クライアント・ブラウザーに送信されます。ブラウザーが HTML ページのリソースに要求を送信すると、 Cookie が添付されるため、Caching Proxy は要求を正しいバックエンド・サーバーに転送します。
JunctionRewrite の代わりに Cookie を使用する場合は、ibmproxy.conf ファイルを 次のように変更します。
以下は、JunctionRewrite プラグインと Cookie の実装の比較です。
Proxy /no-juntion.jpg http://login-server/no-junction.jpg
HTML ファイル内の JavaScript™ (SCRIPT) およびアプレット (APPLET) タグ・ブロックを再書き込みおよび構文解析する、カスタマイズ可能なサンプル・コードが提供されています。JunctionRewrite プラグインは、JavaScript 内または Java™ のパラメーター値へのリソース・リンクを単独で処理することはできません。
Caching Proxy をインストールした後は、同じコードをコンパイルおよび構成し、JunctionRewrite で実行することができます。
次のサンプル・ファイルは、フィックスパックをダウンロードしたディレクトリー内の ...samples/cp/ サブディレクトリーに配置されています。