Caching Proxy プラグイン・プログラムを作成する前に、 プロキシー・サーバーがどのように機能するのかを理解する必要があります。プロキシー・サーバーの動作 は、いくつかの異なる処理ステップに分けることができます。これらのそれぞれのステップで、API を使用して独自にカスタマイズした機能を使用することが可能です。 例えば、 ある処理をクライアント要求の読み取り後、他の処理を行う前に行う、あるいは特殊ルーチンを認証時に実行してから、 要求ファイルの送信後に再度行うなどを決めます。
この API と共に、事前定義された関数のライブラリーが提供されています。 作成するプラグイン・プログラムで これらの事前定義された API 関数を呼び出すことによって、プロキシー・サーバーのプロセスと対話 する (例えば、要求の操作、要求ヘッダーの読み取り/書き込み、 プロキシー・サーバーのログへの書き込みを行う) ことができます。これらの関数を、自分で作成するプラグイン関数 (これらは、プロキシー・サーバー によって呼び出されます) と混同しないでください。事前定義された 関数については、事前定義関数およびマクロに説明があります。
適切なステップでユーザー作成のプラグイン関数を呼び出すようにプロキシー・サーバーに指示するために、 対応する Caching Proxy API ディレクティブをサーバー構成ファイル内で 使用します。これらのディレクティブについては、API ステップ用の Caching Proxy 構成ディレクティブに説明があります。
本書には、次の内容が含まれています。
これらのコンポーネントおよび手順を 使用して、独自の Caching Proxy プラグイン・プログラムを書くことができます。
プロキシー・サーバーの基本的な操作 は、そのフェーズ中にサーバーが実行する処理のタイプに基づいて、いくつかの ステップに分割することができます。各ステップには、プログラムの指定された部分を実行できる接続点があります。Caching Proxy 構成 ファイル (ibmproxy.conf) に API ディレクティブを追加することによって、特定のステップ中にどのプラグイン関数が呼び出される ようにするのかを指定できます。そのステップに複数のディレクティブを組み込むことによって、特定のプロセス・ステップで 複数のプラグイン関数を呼び出すことができます。
いくつかのステップはサーバー要求プロセスの一部です。 言い換えると、プロキシー・サーバーは、要求を処理するたびにこれらの ステップを実行します。その他のステップは要求処理とは無関係に実行されます。 すなわち、要求が処理されているかどうかにかかわらず、 サーバーはこれらのステップを実行します。
コンパイルされたプログラムは、オペレーティング・システムに応じて、 いずれかの共有オブジェクト (例えば、DLL または .so ファイル) に入っています。 サーバーは、その要求プロセス・ステップを進めながら、いずれかの関数が要求の 処理を終えたことを示すまでは、各ステップに関連付けられたプラグイン関数を呼び出します。 特定のステップのプラグイン関数が複数ある場合は、これらの関数は構成ファイル内に あるディレクティブの順序で呼び出されます。
要求を処理するプラグイン関数がない (その ステップ用に Caching Proxy API ディレクティブを組み込まなかったか、 そのステップ用のプラグイン関数が HTTP_NOACTION を戻した) 場合、サーバーはそのステップに対するデフォルトのアクションを 実行します。
注 : これは、Service ステップを除くすべてのステップに当てはまります。Service ステップにはデフォルト・アクションはありません。
図 1 は、プロキシー・サーバー・プロセスのステップを表し、 要求処理に関するステップの処理順序を定義しています。
この図の中の 4 つのステップは、クライアント要求の処理とは無関係に実行されます。 これらのステップは、プロキシー・サーバーの実行および保守に関連しています。これらのステップには以下が含まれます。
図 1 に示された各ステップの目的を以下に示します。ある特定の要求に対して必ずすべてのステップが呼び出される わけではないことに注意してください。
要求が読み込まれた後、まだ何も実行されないうちに処理を実行します。
このステップで要求が処理されたことを示す標識 (HTTP_OK) が戻された場合には、 サーバーは要求プロセスの他のステップをバイパスし、Transmogrifier、Log、および PostExit ステップだけを実行します。
保管されたセキュリティー・トークンを使用して保護、ACL、およびその他のアクセス制御用の 物理パスを検査し、基本認証に必要な WWW 認証ヘッダーを生成します。 独自のプラグイン関数を作成してこのステップを置き換える場合は、これらのヘッダーを 自分で生成しなければなりません。
詳しくは、認証および許可を参照してください。
セキュリティー・トークンのデコード、検査、および保管を行います。
詳しくは、認証および許可を参照してください。
許可およびオブジェクト検索後に (ただし要求が満たされる前に) 処理を実行します。
このステップで要求が処理されたことを示す標識 (HTTP_OK) が戻された場合には、 サーバーは要求プロセスの他のステップをバイパスし、Transmogrifier、Log、および PostExit ステップだけを実行します。
AIX® システムでは、 プラグイン関数をリストするエクスポート・ファイル (例えば libmyapp.exp) が必要であり、 Caching Proxy API インポート・ファイル libhttpdapi.exp とリンクする必要があります。
Linux、HP-UX、および Solaris システムでは、libhttpdapi および libc ライブラリーと リンクする必要があります。
Windows システムでは、プラグイン関数を リストするモジュール定義ファイル (.def) が必要であり、HTTPDAPI.LIB とリンクする必要があります。
関数定義に HTAPI.h を組み込み、HTTPD_LINKAGE マクロを使用します。このマクロを使用すると、すべての関数で必ず同じ呼び出し規則を使用できます。
以下のコンパイル・コマンドおよびリンク・コマンドを、ガイドラインとして使用します。
cc_r -c -qdbxextra -qcpluscmt foo.c
cc_r -bM:SRE -bnoentry -o libfoo.so foo.o -bI:libhttpdapi.exp -bE:foo.exp
(このコマンドは、読みやすくするために 2 行にわたって示されています。)
cc -Ae -c +Z +DAportable
aCC +Z -mt -c +DAportable
gcc -c foo.c
ld -G -Bsymbolic -o libfoo.so foo.o -lhttpdapi -lc
cc -mt -Bsymbolic -c foo.c
cc -mt -Bsymbolic -G -o libfoo.so foo.o -lhttpdapi -lc
cl /c /MD /DWIN32 foo.c
link httpdapi.lib foo.obj /def:foo.def /out:foo.dll /dll
エクスポートを指定するには、以下のいずれかの方法を使用します。
定義された要求処理の各ステップ用に独自のプログラム関数を書く場合は、プラグイン関数プロトタイプに示されている 構文に従ってください。
各ユーザー関数では、実行されたアクションを示す値が 戻りコード・パラメーターに使用される必要があります。
各 Caching Proxy ステップ用の関数プロトタイプは、使用する形式を示し、 実行できる処理のタイプを記述します。関数名は事前定義されないので、注意してください。関数には固有の名前を指定する必要がありますが、 命名規則は自由に決めることができます。 わかりやすくするため、本書では、サーバーの処理ステップに関連する名前を使用しています。
各プラグイン関数で、特定の事前定義 API 関数が有効です。 すべてのステップで無効な事前定義関数もあります。 以下の事前定義 API 関数は、これらのどのプラグイン関数からでも呼び出すことができます。
その他の有効または無効な API 関数については、関数のプロトタイプの説明に 示されています。
関数に送られる handle パラメーターの値は、 最初の引数として事前定義関数に渡すことができます。 事前定義 API 関数は、事前定義関数およびマクロに説明されています。
void HTTPD_LINKAGE ServerInitFunction ( unsigned char *handle, unsigned long *major_version, unsigned long *minor_version, long *return_code )
このステップに定義された関数は、サーバー初期化の間のモジュールのロード時に一度呼び出されます。初期化を行うことができるのはいずれかの要求が受け入れられる前です。
すべてのサーバー初期化関数が呼び出されますが、このステップの関数から エラー戻りコードが戻されると、サーバーはエラー・コードを戻した関数と 同じモジュールで構成された他のすべての関数を無視します。 (すなわち、エラーを戻した関数と同じ共有オブジェクトに入っている 関数はどれも呼び出されません。)
バージョンに関するパラメーターは プロキシー・サーバーのバージョン番号を含んでいて、 Caching Proxy によって提供されます。
void HTTPD_LINKAGE PreExitFunction ( unsigned char *handle, long *return_code )
このステップに定義された関数は、要求が読み取られた後、処理が行われる前に それぞれの要求ごとに呼び出されます。 このステップでプラグインを使用して、クライアントの要求 に、要求が Caching Proxy によって処理される前にアクセスできます。
preExit 関数の有効な戻りコードは次のとおりです。
その他の戻りコードは使用しないでください。
この関数が HTTP_OK を戻す 場合、プロキシー・サーバーは、要求が処理されたものと想定します。それ以降のすべての要求処理ステップはバイパスされ、応答ステップ (Transmogrifier、 Log、および PostExit) のみが実行されます。
このステップ中は、事前定義 API 関数はすべて有効です。
void HTTPD_LINKAGE MidnightFunction ( unsigned char *handle, long *return_code )
このステップに定義された関数は毎日、真夜中に実行されます。要求コンテキストは含まれていません。 例えば、この関数はログを分析する子プロセスを起動するために使用できます。 (このステップで処理が長引くと、ロギングの妨げになる可能性があることに注意してください。)
void HTTPD_LINKAGE AuthenticationFunction ( unsigned char *handle, long *return_code )
このステップに定義された関数は、要求の認証方式に基づいて要求ごとに呼び出されます。 この関数は、要求とともに送信されるセキュリティー・トークンの検査を カスタマイズするために使用できます。
void HTTPD_LINKAGE NameTransFunction ( unsigned char *handle, long *return_code )
このステップに定義された関数は、要求ごとに呼び出されます。 テンプレートと一致する要求のみについてプラグイン関数が呼び出されるようにしたい場合は、 URL テンプレートを構成ファイル・ディレクティブに指定します。 Name Translation ステップは要求が処理される前に実行され、URL を ファイル名などのオブジェクトにマッピングするためのメカニズムを提供します。
void HTTPD_LINKAGE AuthorizationFunction ( unsigned char *handle, long *return_code )
このステップに定義された関数は、要求ごとに呼び出されます。 テンプレートと一致する要求のみについてプラグイン関数が呼び出されるようにしたい場合は、 URL テンプレートを構成ファイル・ディレクティブに指定します。 Authorization ステップは要求が処理される前に実行され、 識別されたオブジェクトをクライアントに戻すことができるかどうかを 検査するために使用できます。基本認証を行う場合は、必要な WWW 認証ヘッダーを生成しなければなりません。
void HTTPD_LINKAGE ObjTypeFunction ( unsigned char *handle, long *return_code )
このステップに定義された関数は、要求ごとに呼び出されます。 テンプレートと一致する要求のみについてプラグイン関数が呼び出されるようにしたい場合は、 URL テンプレートを構成ファイル・ディレクティブに指定します。 Object Type ステップは要求が処理される前に実行され、 オブジェクトが存在するかどうかを調べてオブジェクトの型定義を行うために使用できます。
void HTTPD_LINKAGE PostAuthFunction ( unsigned char *handle, long *return_code )
このステップに定義された関数は、要求が許可された後、処理が起こる前に呼び出されます。 この関数が HTTP_OK を戻す 場合、プロキシー・サーバーは、要求が処理されたものと想定します。それ以降のすべての要求ステップはバイパスされ、応答ステップ (Transmogrifier、 Log、および PostExit) のみが実行されます。
このステップ中は、サーバー事前定義関数はすべて有効です。
void HTTPD_LINKAGE ServiceFunction ( unsigned char *handle, long *return_code )
このステップに定義された関数は、要求ごとに呼び出されます。 テンプレートと一致する要求のみについてプラグイン関数が呼び出されるようにしたい場合は、 URL テンプレートを構成ファイル・ディレクティブに指定します。 Service ステップは、要求が PreExit または PostAuthorization ステップで 満たされなかった場合に、この要求を満たします。
このステップ中は、サーバー事前定義関数はすべて有効です。
URL では なく HTTP メソッドに基づいて実行するように Service 関数を構成する方法については、「WebSphere Application Server Caching Proxy 管理ガイド 」内 の Enable ディレクティブについての説明を参照してください。
このステップには、以下の 4 つの関数を実装しなければなりません。 (使用する関数名は、以下で使用されているものと同じでなくてもかまいません。)
void * HTTPD_LINKAGE openFunction ( unsigned char *handle, long *return_code )
open 関数は、このストリームのデータの処理に必要な 初期化 (バッファー割り振りなど) を実行します。 HTTP_OK 以外の戻りコードが戻されると、このフィルターは打ち切りになります (write 関数も close 関数も呼び出されません)。 関数は void ポインターを戻すことができるので、構造にスペースを割り振り、後続の関数の correlator パラメーターで戻されるポインターをもつことができます。
void HTTPD_LINKAGE writeFunction ( unsigned char *handle, unsigned char *data, /* response data sent by the origin server */ unsigned long *length, /* length of response data */ void *correlator, /* pointer returned by the 'open' function */ long *return_code )
write 関数はデータを処理し、新規または変更データを指定して サーバーの事前定義 HTTPD_write() 関数を呼び出すことができます。 プラグイン側では、渡されたバッファーを解放しないでください。 また、サーバーが受け取ったバッファーを解放することもありません。
write 関数の有効範囲でデータを変更しないようにする場合は、open、 write、または close 関数の有効範囲で HTTPD_write() 関数を呼び出して、 クライアントへの応答に対してデータを渡す必要があります。 correlator 引数は データ・バッファーを指すポインターで、open ルーチンで戻されたものです。
void HTTPD_LINKAGE closeFunction ( unsigned char *handle, void *correlator, long *return_code )
close 関数は、このストリームのデータの処理を完了するために必要な クリーンアップ・アクション (correlator バッファーのフラッシュや解放など) を行います。 correlator 引数は データ・バッファーを指すポインターで、open ルーチンで戻されたものです。
void HTTPD_LINKAGE errorFunction ( unsigned char *handle, void *correlator, long *return_code )
error 関数により、エラー・ページが送信される前に、バッファー内にあるデータの フラッシュまたは解放 (あるいはその両方) などのクリーンアップ・アクションを 行うことができるようになります。 この時点で、エラー・ページを 処理するために open、write、および close 関数が呼び出されます。correlator 引数は データ・バッファーを指すポインターで、open ルーチンで戻されたものです。
注 :
void HTTPD_LINKAGE GCAdvisorFunction ( unsigned char *handle, long *return_code )
このステップに定義された関数は、ガーベッジ・コレクションの際、キャッシュ内のファイルごとに呼び出されます。この関数によって、保持するファイルと廃棄するファイルの決定に 影響を与えることができます。 詳細については、GC_* 変数を参照してください。
void HTTPD_LINKAGE ProxyAdvisorFunction ( unsigned char *handle, long *return_code )
このステップに定義された関数は、各プロキシー要求のサービス時に呼び出されます。 例えば、USE_PROXY 変数を設定するために使用することができます。
void HTTPD_LINKAGE LogFunction ( unsigned char *handle, long *return_code )
このステップに定義された関数は、要求が処理され、クライアントへの通信が クローズされた後で、それぞれの要求ごとに呼び出されます。 テンプレートと一致する要求のみについてプラグイン関数が呼び出されるようにしたい場合は、 URL テンプレートを構成ファイル・ディレクティブに指定します。 この関数は、要求処理の成否に関係なく呼び出されます。 ログ・プラグインにデフォルトのログ・メカニズムを変更させたくない場合は、戻りコードを HTTP_OK ではなく HTTP_NOACTION に設定します。
void HTTPD_LINKAGE ErrorFunction ( unsigned char *handle, long *return_code )
このステップに定義された関数は、失敗した要求ごとに呼び出されます。 テンプレートと一致する、失敗した要求のみについてプラグイン関数が呼び出されるようにしたい場合は、 URL テンプレートを構成ファイル・ディレクティブに指定します。 Error ステップを使用して、エラー応答をカスタマイズできます。
void HTTPD_LINKAGE PostExitFunction ( unsigned char *handle, long *return_code )
このステップに定義された関数は、要求の成否に関係なく、 要求ごとに呼び出されます。 このステップを使用して、要求を処理するプラグインによって割り振られたリソースに対して クリーンアップ・タスクを行うことができます。
void HTTPD_LINKAGE ServerTermFunction ( unsigned char *handle, long *return_code )
このステップに定義された関数は、サーバーが正常にシャットダウンしたときに呼び出されます。 これにより、サーバー初期化ステップの際に割り振られたリソースをクリーンアップすることができます。このステップでは、いずれの HTTP_* 関数も呼び出さないでください (呼び出しの結果は保証できません)。Server Termination 用の複数の Caching Proxy API ディレクティブ が構成ファイル内にある場合、それらがすべて呼び出されます。
これらの戻りコードは、World Wide Web Consortium によって公開されている HTTP 1.1 仕様書 (www.w3.org/pub/WWW/Protocols/) の RFC 2616 に準拠しています。 プラグイン関数は、以下のいずれかの値を戻す必要があります。
値 | 戻りコード |
0 | HTTP_NOACTION |
100 | HTTP_CONTINUE |
101 | HTTP_SWITCHING_PROTOCOLS |
200 | HTTP_OK |
201 | HTTP_CREATED |
202 | HTTP_ACCEPTED |
203 | HTTP_NON_AUTHORITATIVE |
204 | HTTP_NO_CONTENT |
205 | HTTP_RESET_CONTENT |
206 | HTTP_PARTIAL_CONTENT |
300 | HTTP_MULTIPLE_CHOICES |
301 | HTTP_MOVED_PERMANENTLY |
302 | HTTP_MOVED_TEMPORARILY |
302 | HTTP_FOUND |
303 | HTTP_SEE_OTHER |
304 | HTTP_NOT_MODIFIED |
305 | HTTP_USE_PROXY |
307 | HTTP_TEMPORARY_REDIRECT |
400 | HTTP_BAD_REQUEST |
401 | HTTP_UNAUTHORIZED |
403 | HTTP_FORBIDDEN |
404 | HTTP_NOT_FOUND |
405 | HTTP_METHOD_NOT_ALLOWED |
406 | HTTP_NOT_ACCEPTABLE |
407 | HTTP_PROXY_UNAUTHORIZED |
408 | HTTP_REQUEST_TIMEOUT |
409 | HTTP_CONFLICT |
410 | HTTP_GONE |
411 | HTTP_LENGTH_REQUIRED |
412 | HTTP_PRECONDITION_FAILED |
413 | HTTP_ENTITY_TOO_LARGE |
414 | HTTP_URI_TOO_LONG |
415 | HTTP_BAD_MEDIA_TYPE |
416 | HTTP_BAD_RANGE |
417 | HTTP_EXPECTATION_FAILED |
500 | HTTP_SERVER_ERROR |
501 | HTTP_NOT_IMPLEMENTED |
502 | HTTP_BAD_GATEWAY |
503 | HTTP_SERVICE_UNAVAILABLE |
504 | HTTP_GATEWAY_TIMEOUT |
505 | HTTP_BAD_VERSION |
サーバーの事前定義関数およびマクロを、 ユーザー独自のプラグイン関数から呼び出すことができます。その事前定義された名前を使用し、以下の形式に従う必要があります。パラメーターの説明で、 i は入力パラメーターを示し、o は出力パラメーターを示し、 i/o はパラメーターが入力と出力の両方であることを示しています。
これらの関数は、要求の結果に応じて、いずれかの HTTPD 戻りコードを戻します。これらのコードについては、事前定義関数およびマクロからの戻りコードに記述されています。
これらの関数を呼び出すときは、プラグインへ提供されたハンドルを最初のパラメーターとして使用します。最初の パラメーターとして使用しない場合、関数は HTTPD_PARAMETER_ERROR エラー・コードを戻します。 NULL は、有効なハンドルとしては受け入れられません。
void HTTPD_LINKAGE HTTPD_authenticate ( unsigned char *handle, /* i; handle */ long *return_code /* o; return code */ )
void HTTPD_LINKAGE HTTPD_cacheable_url ( unsigned char *handle, /* i; handle */ unsigned char *url, /* i; URL to check */ unsigned char *req_method, /* i; request method for the URL */ long *retval /* o; return code */ )
戻り値 HTTPD_SUCCESS は、URL コンテンツがキャッシュできることを示します。HTTPD_FAILURE はコンテンツがキャッシュできないことを示します。また、HTTPD_INTERNAL_ERROR もこの関数の可能な戻りコードです。
void HTTPD_LINKAGE HTTPD_close ( unsigned char *handle, /* i; handle */ long *return_code /* o; return code */ )
void HTTPD_LINKAGE HTTPD_exec ( unsigned char *handle, /* i; handle */ unsigned char *name, /* i; name of script to run */ unsigned long *name_length, /* i; length of the name */ long *return_code /* o; return code */ )
void HTTPD_LINKAGE HTTPD_extract ( unsigned char *handle, /* i; handle */ unsigned char *name, /* i; name of variable to extract */ unsigned long *name_length, /* i; length of the name */ unsigned char *value, /* o; buffer in which to put the value */ unsigned long *value_length, /* i/o; buffer size */ long *return_code /* o; return code */ )
この関数が HTTPD_BUFFER_TOO_SMALL コードを戻した場合、要求したバッファー・サイズは、抽出された値を入れるのに十分な大きさではありませんでした。この場合、 この関数はバッファーを使用せず、この値を正常に抽出するために必要な バッファー・サイズで value_length パラメーターを更新します。 少なくとも、戻された value_length と同じ大きさのバッファーを使用して抽出を再試行します。
void HTTPD_LINKAGE HTTPD_file ( unsigned char *handle, /* i; handle */ unsigned char *name, /* i; name of file to send */ unsigned long *name_length, /* i; length of the name */ long *return_code /* o; return code */ )
const unsigned char * /* o; value of variable */ HTTPD_LINKAGE httpd_getvar( unsigned char *handle, /* i; handle */ unsigned char *name, /* i; variable name */ unsigned long *n /* i; index number for the array containing the header */ )
ヘッダーが入っている配列の指標は 0 から始まります。配列で最初の項目を得るには、n に値 0 を使用します。5 番目の項目を得るには、n には値 4 を使用します。
void HTTPD_LINKAGE HTTPD_log_access ( unsigned char *handle, /* i; handle */ unsigned char *value, /* i; data to write */ unsigned long *value_length, /* i; length of the data */ long *return_code /* o; return code */ )
サーバー・アクセス・ログにパーセント記号 (%) を書き込むときに、 エスケープ記号は必要がない ことに注意してください。
void HTTPD_LINKAGE HTTPD_log_error ( unsigned char *handle, /* i; handle */ unsigned char *value, /* i; data to write */ unsigned long *value_length, /* i; length of the data */ long *return_code /* o; return code */ )
サーバー・エラー・ログにパーセント記号 (%) を書き込むときに、 エスケープ記号は必要がない ことに注意してください。
void HTTPD_LINKAGE HTTPD_log_event ( unsigned char *handle, /* i; handle */ unsigned char *value, /* i; data to write */ unsigned long *value_length, /* i; length of the data */ long *return_code /* o; return code */ )
サーバー・イベント・ログにパーセント記号 (%) を書き込むときに、 エスケープ記号は必要がない ことに注意してください。
void HTTPD_LINKAGE HTTPD_log_trace ( unsigned char *handle, /* i; handle */ unsigned char *value, /* i; data to write */ unsigned long *value_length, /* i; length of the data */ long *return_code /* o; return code */ )
サーバー・トレース・ログにパーセント記号 (%) を書き込むときに、 エスケープ記号は必要がない ことに注意してください。
void HTTPD_LINKAGE HTTPD_open ( unsigned char *handle, /* i; handle */ long *return_code /* o; return code */ )
void HTTPD_LINKAGE HTTPD_proxy ( unsigned char *handle, /* i; handle */ unsigned char *url_name, /* i; URL for the proxy request */ unsigned long *name_length, /* i; length of URL */ void *request_body, /* i; body of request */ unsigned long *body_length, /* i; length of body */ long *return_code /* o; return code */ )
void HTTPD_LINKAGE HTTPD_read ( unsigned char *handle, /* i; handle */ unsigned char *value, /* i; buffer for data */ unsigned long *value_length, /* i/o; buffer size (data length) */ long *return_code /* o; return code */ )
void HTTPD_LINKAGE HTTPD_restart ( long *return_code /* o; return code */ )
この関数で変数を作成することもできますので注意してください。作成する変数 は、変数に説明されている HTTP_ 接頭部および PROXY_ 接頭部の規則に準拠 する必要があります。HTTP_ で始まる変数を作成した場合、この変数は、接頭部 HTTP_ なしで、 クライアントへの応答でヘッダーとして送信されます。 例えば、Location ヘッダーを設定するには、変数名 HTTP_LOCATION で HTTPD_set() を使用します。 接頭部 PROXY_ を付けて作成した変数は、コンテンツ・サーバーへの要求でヘッダーとして送信されます。 接頭部 CGI_ を付けて作成した変数は CGI プログラムに渡されます。
この関数はすべてのステップで有効です。 ただし、すべての変数がすべてのステップで有効であるとは限りません。
void HTTPD_LINKAGE HTTPD_set ( unsigned char *handle, /* i; handle */ unsigned char *name, /* i; name of value to set */ unsigned long *name_length, /* i; length of the name */ unsigned char *value, /* i; buffer with value */ unsigned long *value_length, /* i; length of value */ long *return_code /* o; return code */ )
long /* o; return code */ HTTPD_LINKAGE httpd_setvar ( unsigned char *handle, /* i; handle */ unsigned char *name, /* i; variable name */ unsigned char *value, /* i; new value */ unsigned long *addHdr /* i; add header or replace it */ )addHdr
パラメーターには、以下の 4 つの値を使用できます。
これらの値は HTAPI.h で定義されます。
void HTTPD_LINKAGE httpd_variant_insert ( unsigned char *handle, /* i; handle */ unsigned char *URI, /* i; URI of this object */ unsigned char *dimension, /* i; dimension of variation */ unsigned char *variant, /* i; value of the variant */ unsigned char *filename, /* i; file containing the object */ long *return_code /* o; return code */ )
注 :
Mozilla 4.0 (compatible; BatBrowser 94.1.2; Bat OS)
void HTTPD_LINKAGE httpd_variant_lookup ( unsigned char *handle, /* i; handle */ unsigned char *URI, /* URI of this object */ unsigned char *dimension, /* i; dimension of variation */ unsigned char *variant, /* i; value of the variant */ long *return_code); /* o; return code */
初めてこの関数を呼び出す前にコンテンツ・タイプを設定しなかった場合、 サーバーは、CGI データ・ストリームが送信されるものと想定します。
void HTTPD_LINKAGE HTTPD_write ( unsigned char *handle, /* i; handle */ unsigned char *value, /* i; data to send */ unsigned char *value_length, /* i; length of the data */ long *return_code); /* o; return code */
サーバーは、戻りコード・パラメーターを、 要求の成功に応じて次のいずれかの値に設定します。
値 | 状況コード | 説明 |
---|---|---|
-1 | HTTPD_UNSUPPORTED | この関数はサポートされていません。 |
0 | HTTPD_SUCCESS | この関数は正常に実行され、出力フィールドが有効です。 |
1 | HTTPD_FAILURE | 関数は失敗しました。 |
2 | HTTPD_INTERNAL_ERROR | 内部エラーを検出し、 この要求の処理を続行できません。 |
3 | HTTPD_PARAMETER_ERROR | 1 つ以上の無効なパラメーターが渡されました。 |
4 | HTTPD_STATE_CHECK | この関数はこのプロセス・ステップでは無効です。 |
5 | HTTPD_READ_ONLY | (これを戻すのは HTTPD_set と httpd_setvar だけです。) 変数は読み取り専用であり、プラグインによって設定できません。 |
6 | HTTPD_BUFFER_TOO_SMALL | (これを戻すのは HTTPD_set、 httpd_setvar、および HTTPD_read だけです。)指定のバッファーが小さすぎます。 |
7 | HTTPD_AUTHENTICATE_FAILED | (これを戻すのは HTTPD_authenticate だけです。) 認証は失敗しました。 詳細については、HTTP_RESPONSE および HTTP_REASON 変数を調べてください。 |
8 | HTTPD_EOF | (これを戻すのは HTTPD_read だけです。) 要求本文の終わりを示します。 |
9 | HTTPD_ABORT_REQUEST | クライアントが要求が指定する条件と一致しないエンティティー・タグを指定したために、 要求は打ち切られました。 |
10 | HTTPD_REQUEST_SERVICED | (これを戻すのは HTTPD_proxy だけです。) 呼び出した関数は この要求の応答を完了しました。 |
11 | HTTPD_RESPONSE_ALREADY_COMPLETED | その要求の応答は既に完了しているので、 この関数は失敗しました。 |
12 | HTTPD_WRITE_ONLY | 変数は書き込み専用であり、プラグインによって読み取ることはできません。 |
要求プロセスの各ステップ にはそれぞれ 1 つの構成ディレクティブがあり、それを使用して、そのステップ中に呼び出して実行するプラグイン関数を 指示することができます。 サーバーの構成ファイル (ibmproxy.conf) を手動で編集して更新するか、 または、Caching Proxy の「構成および管理」の各種フォームの中の「API 要求処理」フォームを使用 して、これらのディレクティブを構成ファイルに追加できます。
すなわち、サーバーは、Service、NameTrans、Exec、Fail、Map、Pass、Proxy、 ProxyWAS、および Redirect の各ディレクティブを構成ファイル内に 並んでいる順序で処理します。 サーバーが URL をファイルに正常にマップすると、サーバーはこれらのディレクティブ以外の ディレクティブを読み取ったり、処理したりしません。 (Map ディレクティブは例外です。プロキシー・サーバーのマッピング・ルールについて詳しくは、「WebSphere Application Server Caching Proxy 管理ガイド 」を 参照してください)
これらの構成ファイル・ディレクティブは、ここに明確に指定されたものを除いてスペースを入れずに、ibmproxy.conf ファイル中に 1 行で記述しなければなりません。構文例の一部では 読みやすさのために改行していますが、実際のディレクティブではそこにスペースを入れないでください。
これらのディレクティブの変数には、以下の意味があります。
パス情報にアクセスする場合、Service ディレクティブには、関数名の後に アスタリスク (*) が必要です。
構文など、これらのディレクティブに関する追加情報については、 「WebSphere Application Server Caching Proxy 管理ガイド 」を参照してください。