前へ     目次     索引     DocHome     次へ     
iPlanet Web Server, Enterprise Edition NSAPI プログラマーズガイド



第 2 章   obj.conf の構文と使用法


obj.conf 構成ファイルには、クライアントからの要求を処理する方法を iPlanet Web Server に指示する指令が含まれています。この章では、obj.conf に含まれるサーバの命令、Object タグの使用法、変数の使用法、obj.conf 内の制御のフロー、obj.conf の編集上の構文規則、および指令の例について説明します。

この章は、次の節で構成されています。



obj.conf に含まれるサーバの命令

obj.conf ファイルには、ブラウザなどのクライアントから受け取った要求を処理する方法をサーバに指示する指令が含まれています。指令は、OBJECT タグ内に記述されます。

各指令は、関数の呼び出しの時期とそのための引数を指定して、関数を呼び出します。

各指令の構文を次に示します。

Directive fn=func-name name1="value1"...nameN="valueN"

次に例を示します。

NameTrans fn="document-root" root="D:/Netscape/Server4/docs"

Directive は、要求処理プロセスのどの時点でこの命令を実行するかを示します。値は、次のいずれかになります。AuthTrans、NameTrans、PathCheck、ObjectType、Service、Error、AddLog。

fn 引数の値には、実行対象のサーバアプリケーション関数 (Server Application Function: SAF) の名前を指定します。どの指令にも、fn パラメータの値を 1 つ指定する必要があります。関数がない場合は、命令は何も実行しません。

残りのパラメータは、関数に必要とされる引数であり、これは関数によって異なります。

iPlanet Web Server には、第 3 章「事前定義済みの SAF および要求処理プロセス」に説明されているように、obj.conf で指令の作成や変更を行うために使うことのできる、1 式の組み込みサーバアプリケーション関数 (SAF) があります。第 4 章「カスタム SAF の作成」に説明されているように、新しい SAF を定義することもできます。

magnus.conf ファイルには、サーバを初期化する Init 指令の SAF が含まれています。詳細は、第 7 章「magnus.conf の構文と使用法」を参照してください。


指令の要約

以下にサーバの指令のカテゴリを示し、各指令の用途について説明します。各カテゴリは、要求処理プロセスの特定の段階に対応します。「obj.conf 内の制御のフロー」 の節では、各段階で実行すべき指令をサーバがどのように判断するかを具体的に説明します。

  • AuthTrans

    HTTP 要求に指定された承認情報 (通常、Authorization ヘッダーで送られる) を検証し、その情報をユーザまたはグループ、あるいはその両方に変換します。サーバのアクセス制御は、次の 2 つの段階からなります。AuthTrans は、ユーザの正当性を検証します。その後、PathCheck が、要求されたリソースに対するユーザのアクセス特権をテストします。

    AuthTrans fn=basic-auth userfn=ntauth auth-type=basic userdb=none

    この例では、basic-auth 関数を呼び出し、この関数はクライアントが送信してきた承認情報を検証するためにカスタム関数 (この場合 ntauth) を呼び出します。Authorization ヘッダーは、基本サーバ承認スキーマの一部として送られます。

  • NameTrans

    要求に指定された URL を論理 URL から、要求されたリソースの物理ファイルシステムのパスに変換します。これは、別のサイトへのリダイレクトになることもあります。次に例を示します。

    NameTrans fn="document-root" root="D:/Netscape/Server4/docs"

    この例では、root 引数に D:/Netscape/Server4/docs を設定して、document-root 関数を呼び出します。document-root 関数は、要求されたリソースの URL の http://server_name/ の部分をドキュメントルートに変換します。この場合のドキュメントルートは、D:/Netscape/Server4/docs です。したがって、http://server-name/doc1.html に対する要求は、D:/Netscape/Server4/docs/doc1.html に変換されます。

  • PathCheck

    NameTrans ステップで得られた物理パスをテストします。一般に、このテストは、パスが有効であるかどうかと、要求したリソースにクライアントがアクセスを許可されているかどうかを判定します。次に例を示します。

    PathCheck fn="find-index" index-names="index.html,home.html"

    この例では、index-names 引数に index.html,home.html を設定して、find-index 関数を呼び出します。要求された URL がディレクトリである場合は、この関数は、要求されたディレクトリで index.html または home.html というファイルを検索するようにサーバに指示します。

  • ObjectType

    要求されたリソースの MIME (Multi-purpose Internet Mail Encoding) タイプを判別します。MIME タイプには、属性として type (内容のタイプを示す)、encoding、および language があります。MIME タイプは、クライアントへの応答のヘッダーで送られます。MIME タイプは、サーバがどの Service 指令を実行すべきかを判断する際にも役立ちます。

    MIME タイプには、次のものがあります。

    • 一般的なドキュメントタイプの text/html や image/gif など (たとえば、ファイル名の拡張子の .gif は、MIME タイプの image/gif に変換される)

    • 内部サーバタイプ。内部タイプは、必ず magnus-internal で始まる

    次に例を示します。

    ObjectType fn="type-by-extension"

    この例では、type-by-extension 関数を呼び出します。この関数により、サーバは、要求されたリソースのファイル拡張子に基づいて MIME タイプを判別します。

  • Service

    応答を生成し、クライアントに送信します。これには、HTTP 結果ステータスの設定、応答ヘッダー (内容のタイプや内容の長さなど) の設定、および応答データの生成と送信が含まれます。デフォルトの応答は、send-file 関数を呼び出して、要求されたファイルの内容を適切なヘッダーファイルと共にクライアントに送信します。

    デフォルトの Service 指令を次に示します。

    Service method="(GET|HEAD|POST)" type="*~magnus-internal/*" fn="send-file"

    この指令は、メソッドが GET、HEAD、または POST であり、タイプ が magnus-internal/ で始まらない要求に対する応答として send-file 関数を呼び出すようにサーバに指示します。(特殊文字の *~ は、「一致しない」を示しています。)

    別の例を次に示します。

    Service method="(GET|HEAD)" type="magnus-internal/imagemap" fn="imagemap"

    この場合、要求のメソッドが GET または HEAD のどちらかであり、要求されたリソースのタイプが "magnus-internal/imagemap" である場合は、imagemap 関数が呼び出されます。

  • AddLog

    トランザクションについての情報を記録するためにログファイルにエントリを追加します。次に例を示します。

    AddLog fn="flex-log" name="access"

    この例では、 flex-log 関数を呼び出して、access という名前のログファイルに現在の要求についての情報を記録します。

  • Error

    HTTP エラーに対処します。この指令は、前の指令がエラーになると、呼び出されます。通常、サーバは、問題点と考えられる解決策を示すカスタム HTML ドキュメントをユーザに送信することによりエラーに対処します。

    次に例を示します。

    Error fn="send-error" reason="Unauthorized" path="D:/netscape/server4/errors/unauthorized.html"

    この例では、サーバは、クライアントがアクセスを許可されていないリソースを要求するたびに、D:/netscape/server4/errors/unauthorized.html のファイルを送信します。



Object タグ

obj.conf ファイル内の指令は、<Object> タグで始まり、</Object> タグで終わるオブジェクトのグループに分けられます。デフォルトのオブジェクトは、要求を処理するデフォルトの方法をサーバに指示します。新しい各オブジェクトは、デフォルトのオブジェクトの動作を変更します。

Object タグには、name 属性または ppath 属性を指定できます。どちらのパラメータも、ワイルドカードパターンで指定できます。次に例を示します。

<Object name="cgi">

または

<Object ppath="/usr/netscape/server4/docs/private/*">

サーバは、常にデフォルトのオブジェクトの指令を処理することにより要求の処理を開始します。ただし、サーバは、次の条件のどちらかが真の場合、デフォルトのオブジェクトの NameTrans 段階の後に、別のオブジェクトの指令の処理に切り替えます。

  • 成功した NameTrans 指令が、name 引数を指定する

  • NameTrans 段階で得られた物理パス名が、別のオブジェクトの ppath 属性に一致する

デフォルトのオブジェクト以外のオブジェクトを使うようにサーバが指示されると、サーバはデフォルトのオブジェクトの指令の処理の前に、別のオブジェクトの指令を処理します。要求処理プロセスの一部のステップでは、サーバは、特定の段階の 1 つの指令の実行に成功するとただちにその特定の段階 (Service 段階など) の指令の処理を停止しますが、その他の段階ではサーバはその段階のすべての指令 (デフォルトのオブジェクト内および追加のオブジェクト内の指令を含む) を処理します。詳細は、「obj.conf 内の制御のフロー」を参照してください。


name 属性を使うオブジェクト

デフォルトのオブジェクトの NameTrans 指令が name 引数を指定している場合は、サーバはデフォルトのオブジェクトの残りの指令を処理する前に、その名前のオブジェクトの指令を処理します。

たとえば、デフォルトのオブジェクトに含まれる次の NameTrans 指令は、名前 cgi を URL が http://server_name/cgi/ で始まる要求に割り当てます。

<Object name="default">
NameTrans fn="pfx2dir" from="/cgi" dir="D:/netscape/server4/docs/mycgi" name="cgi"
...
</Object>

この NameTrans 指令が実行されると、サーバは cgi という名前のオブジェクトの指令の処理を開始します。

<Object name="cgi">
more directives...
</Object>


ppath 属性を使うオブジェクト

サーバがデフォルトのオブジェクトの NameTrans 指令の処理を終了したときは、すでに要求の論理 URL は物理パス名に変換されています。この物理パス名が、obj.conf 内の別のオブジェクトの ppath 属性に一致する場合は、サーバはデフォルトのオブジェクトの残りの指令を処理する前に、そのオブジェクトの指令の処理に切り替えます。

たとえば、次の NameTrans 指令は、要求された URL の http://server_name/ の部分を D:/Netscape/Server4/docs/ (ドキュメントルートのディレクトリ) に変換します。

<Object name="default">
NameTrans fn="document-root" root="D:/Netscape/Server4/docs"
...
</Object>

URL の http://server_name/internalplan1.html は、D:/Netscape/Server4/docs/internalplan1.html に変換されます。ただし、obj.conf に次の追加のオブジェクトが含まれているとします。

<Object ppath="*internal*">
more directives...
</Object>

この場合、部分的なパスの *internal* は、パス D:/Netscape/Server4/docs/internalplan1.html に一致します。したがって、サーバは、デフォルトのオブジェクトの残りの指令を処理する前に、このオブジェクトの指令の処理を開始します。



server.xml に定義された変数


server.xml ファイルで変数を定義し、それらの変数を obj.conf ファイルで参照できます。たとえば、次の server.xml コードでは、次のように docroot という変数を定義し、使用しています。

<!DOCTYPE SERVER SYSTEM "server.dtd" [
<!ATTLIST VARS
   docroot CDATA #IMPLIED
>
]>
...
       <VS id="a.com" connections="maingroup" urlhosts="a.com"
             mime="mime1" aclids="std">
          <VARS docroot="/u/server6/a/docs" />
       </VS>
...

次のようにして、この変数を obj.conf で参照できます。

NameTrans fn=document-root root="$docroot"

この docroot 変数を使用すると、obj.conf ファイルで仮想サーバクラス用のドキュメントルートを定義する手間が省けます。また、同じ仮想サーバクラス内で仮想サーバごとに異なるドキュメントルートを定義可能にします。


注   変数の代入は、obj.conf ファイルでのみ許可されています。その他の iPlanet Web Server 構成ファイルでは許可されていません。

obj.conf ファイルで参照される変数は、SERVER、VSCLASS、または VS レベルで server.xml ファイルに定義しておく必要があります。SERVER または VSCLASS レベルで変数をデフォルト値で定義し、それらの値を VS でオーバーライドすることをお勧めします。

 

詳細は、第 8 章「仮想サーバの構成ファイル」を参照してください。



obj.conf 内の制御のフロー


サーバは、要求を正しい仮想サーバに割り当ててからでなければ、要求を処理できません。仮想サーバの決定方法の詳細は、「要求処理のための仮想サーバの選択」を参照してください。

仮想サーバが決定された後、サーバは、仮想サーバが属する仮想サーバクラス用の obj.conf ファイルを実行します。この節では、サーバが obj.conf に含まれているどの指令を実行すべきかを判断する方法について説明します。


AuthTrans

サーバが要求を受け取ると、デフォルトのオブジェクトの AuthTrans 指令を実行して、サーバへのアクセスをクライアントが許可されているかどうかを確認します。

複数の AuthTrans 指令がある場合は、サーバはそれらをすべて (いずれかがエラーにならないかぎり) 実行します。エラーが発生した場合は、サーバは Error 指令以外のその他のすべての指令の実行を省略します。


NameTrans

次に、サーバはデフォルトのオブジェクトの NameTrans 指令を実行して、要求されたリソースの論理 URL をサーバのファイルシステムの物理パス名にマッピングします。サーバは、適用できるものが見つかるまで、デフォルトのオブジェクトの各 NameTrans 指令を 1 つずつ確認していきます。

デフォルトのオブジェクトに複数の NameTrans 指令が含まれている場合は、サーバは、1 つが成功するまで各指令を確認します。

デフォルトのオブジェクトの NameTrans セクションには、document-root 関数を呼び出す指令が 1 つだけ含まれている必要があります。この関数は、要求された URL の http://server_name/ の部分を、サーバのドキュメントルートとして指定された物理ディレクトリに変換します。次に例を示します。

NameTrans fn="document-root" root="D:/Netscape/Server4/docs"

その他の NameTrans 指令が適用されない場合にだけ実行されるように、document-root を呼び出す指令は、NameTrans セクションの最後の指令にする必要があります。

pfx2dir (ディレクトリの接頭辞) 関数は、URL とディレクトリ間の追加のマッピングを設定するために使います。たとえば、次の指令は、URL http://server_name/cgi/ をディレクトリのパス名 D:/netscape/server4/docs/mycgi/ に変換します。

NameTrans fn="pfx2dir" from="/cgi" dir="D:/netscape/server4/docs/mycgi"

この指令が document-root を呼び出す指令の後にくる場合は、この指令は実行されず、その結果のディレクトリのパス名は D:/netscape/server4/docs/cgi/ (mycgi ではなく) になります。これは、document-root を呼び出す指令を、NameTrans セクションの最後の指令にする必要がある理由を示しています。


その他のオブジェクトの処理についてサーバが判断する方法

NameTrans 指令を実行した結果、サーバが別のオブジェクトの指令の処理を開始することがあります。実行に成功した NameTrans 指令が別のオブジェクトの name 属性に一致する名前を指定しているか、別オブジェクトの ppath 属性に一致する部分的なパスを生成する場合に、そのようになります。

成功した NameTrans 指令が、name 引数を指定することにより名前を割り当てると、サーバは、残りの要求処理プロセスのデフォルトのオブジェクトの指令の処理の前に、指定されたオブジェクト (OBJECT タグで定義された) の指令の処理を開始します。

たとえば、デフォルトのオブジェクトに含まれる次の NameTrans 指令は、cgi という名前を URL が http://server_name/cgi/ で始まる要求に割り当てます。

<Object name="default">
...
NameTrans fn="pfx2dir" from="/cgi" dir="D:/netscape/server4/docs/mycgi" name="cgi"
...
</Object>

この NameTrans 指令が実行されると、サーバは cgi という名前のオブジェクトの指令の処理を開始します。

<Object name="cgi">
more directives...
</Object>

NameTrans 指令の実行に成功すると、要求されたリソースに関連付けられた物理パス名が生成されます。生成されたパス名が別のオブジェクトの ppath (部分的なパス) 属性に一致する場合は、サーバは、残りの要求処理プロセスのデフォルトのオブジェクトの指令の処理の前に、他のオブジェクトの指令の処理を開始します。

たとえば、obj.conf に次のようなオブジェクトが含まれているとします。

<Object ppath="*internal*">
more directives...
</Object>

次に、成功した NameTrans 指令が、要求された URL をパス名 D:/Netscape/Server4/docs/internalplan1.html に変換するとします。この場合、部分的なパスの *internal* は、パス D:/Netscape/Server4/docs/internalplan1.html に一致します。したがって、これでサーバは、デフォルトのオブジェクトの残りの指令の処理の前に、このオブジェクトの指令の処理を開始します。


PathCheck

NameTrans ステップで要求されたリソースの論理 URL を物理パス名に変換した後、サーバは PathCheck 指令を実行して、要求したリソースにクライアントがアクセスを許可されているかどうかを検証します。

複数の PathCheck 指令がある場合は、サーバはいずれかの指令がアクセスを拒否しないかぎり、すべての指令を記述されている順に実行します。アクセスが拒否された場合は、サーバは Error セクションの指令の実行に切り替えます。

NameTrans 指令が、別のオブジェクトの name または ppath 属性に一致する名前を割り当てたか、あるいは物理パス名を生成した場合は、サーバはデフォルトのオブジェクトの指令を適用する前に、まず一致するオブジェクトの PathCheck 指令を適用します。


ObjectType

すべての PathCheck 指令がアクセスを許可すると仮定すると、サーバは次に ObjectType 指令を実行して、要求の MIME タイプを判別します。MIME タイプには、type、encoding、および language の 3 つの属性があります。サーバがクライアントに応答を送信するときに、type、language、および encoding の値が応答のヘッダーに入れられて送信されます。また、多くの場合、type は、クライアントへの応答を生成するためにどの Service 指令を実行すべきかをサーバが判断する際に役立ちます。

複数の ObjectType 指令がある場合は、サーバはすべての指令を記述されている順に適用します。ただし、指令が MIME タイプの属性を設定すると、それ以降に同じ属性の設定を試みても無視されます。すべての ObjectType 指令が適用されるのは、1 つの指令がたとえば type などの 1 つの属性を設定し、別の指令が language などの別の属性を設定することがあるためです。

PathCheck 指令と同様、NameTrans ステップの結果別のオブジェクトが要求に一致する場合は、サーバは、デフォルトのオブジェクトの ObjectType 指令の実行の前に、一致するオブジェクトの ObjectType 指令を実行します。


ファイル拡張子によるタイプの設定

通常デフォルトでは、サーバは、MIME タイプを判別するために type-by-extension 関数を呼び出します。この関数は、要求されたリソースのファイル拡張子に従って MIME タイプテーブルで MIME タイプを調べるようにサーバに指示します。このテーブルは、MIME タイプのファイル (通常、mime.types と呼ばれる) によって仮想サーバの初期化時に作成されています。

たとえば、拡張子 .html と .htm に対する MIME タイプテーブルのエントリは、通常次のようになっています。

type=text/html exts=htm,html

これは、拡張子が .htm または html のファイルはすべて、HTML としてフォーマットされたテキストファイルであり、type が text/html であることを示しています。

MIME タイプファイルを変更する場合は、変更を有効にするためにサーバを再構成する必要があります。

MIME タイプについては、付録 B「MIME タイプ」を参照してください。


タイプの強制

前のどの ObjectType 指令もタイプを設定していない場合で、サーバが一致するファイル拡張子を MIME タイプテーブルで見つけることができない場合は、type-by-expression の実行後も type には値がありません。通常、サーバがファイル拡張子を認識できない場合は、タイプを text/plain に強制するのも一案です。そうすると、リソースの内容がプレーンテキストとして取り扱われます。また、指定された CGI ディレクトリ内のすべてのリソースに MIME タイプの magnus-internal/cgi を強制するなど、ファイル拡張子にかかわらずタイプを設定する必要がある場合もあります。

タイプを強制する関数は、force-type です。

たとえば、次の指令は、まず MIME タイプを MIME タイプテーブルで調べるようにサーバに指示し、次に type 属性が設定されていない (つまり、ファイル拡張子が MIME タイプテーブルに見つからなかった) 場合、type 属性を text/plain に設定します。

ObjectType fn="type-by-extension"
ObjectType fn="force-type" type="text/plain"

サーバがファイル abc.dogs に対する要求を受け取り、MIME タイプテーブルを調べたが、拡張子 .dogs に対応するものが見つからない場合は、type 属性は設定されません。type 属性がまだ設定されていないので、2 番目の指令は成功し、type 属性を強制的に text/plain にします。

次の例は、force-type の別の用途を示しています。この例では、サーバが MIME タイプテーブルを調べる前に、type が強制的に magnus-internal/cgi になります。この場合、http://server_name/cgi/ 内のリソースに対するすべての要求は、D:/netscape/server4/docs/mycgi/ ディレクトリ内のリソースに対する要求に変換されます。名前が要求に割り当てられるので、サーバは デフォルトのオブジェクトの指令の処理の前に、cgi という名前のオブジェクトの ObjectType 指令を処理します。このオブジェクトには、1 つの ObjectType 指令があり、この指令が強制的に type を magnus-internal/cgi にします。

NameTrans fn="pfx2dir" from="/cgi" dir="D:/netscape/server4/docs/mycgi" name="cgi"
<Object name="cgi">
ObjectType fn="force-type" type="magnus-internal/cgi"
Service fn="send-cgi"
</Object>

サーバは引き続き、デフォルトのオブジェクトの指令を含むすべての ObjectType 指令を処理しますが、type 属性はすでに設定されているので、ほかの指令がこの属性を別の値に設定することはできません。


Service

次に、サーバは、クライアントへ送信する応答を生成するために、Service 指令を実行する必要があります。サーバは、type、method、および query string が一致する最初の指令を見つけるために、1 つずつ各 Service 指令を調べます。Service 指令が type、method、または query string を指定していない場合は、指定されていない属性は何にでも一致します。

複数の Service 指令がある場合は、サーバは要求の条件に最初に一致する指令を適用し、残りの Service 指令はすべて無視します。

PathCheck や ObjectType 指令と同様、NameTrans ステップの結果、別のオブジェクトが要求に一致する場合、サーバは、一致するオブジェクトの Service 指令に対処します。サーバは、一致するオブジェクトの Service 指令の実行に成功すると、デフォルトのオブジェクトの Service 指令は実行しません。これは、サーバが Service 指令を 1 つだけしか実行しないためです。


Service の例

Service 指令の働きを示す例として、サーバが URL D:/server_name/jos.html に対する要求を受け取ったらどうなるかを考えてみます。この場合、サーバが実行する指令はすべて、デフォルトのオブジェクトに含まれています。

  • 次の NameTrans 指令は、要求された URL を D:/netscape/server4/docs/jos.html に変換する

       NameTrans fn="document-root" root="D:/Netscape/Server4/docs"

  • PathCheck 指令がすべて成功すると仮定する

  • 次の ObjectType 指令は、リソースの MIME タイプを MIME タイプテーブルで調べるようにサーバに指示する

       ObjectType fn="type-by-extension"

  • サーバは、MIME タイプテーブルで次のエントリを見つける。このエントリは、type 属性を text/html に設定する

       type=text/html exts=htm,html

  • サーバは、次の Service 指令を呼び出す。type パラメータの値は magnus-internal/ で始まらないものに一致する。(ワイルドカードパターンの一覧は、付録 C「ワイルドカードパターン」を参照。) この指令は、要求されたファイル jos.html をクライアントへ送信する

    Service method="(GET|HEAD|POST)" type="*~magnus-internal/*" fn="send-file"

    別のオブジェクトを使う例として、サーバが http://server_name/servlet/doCalculation.class に対する要求を受け取ったらどうなるかを考えてみます。この例では、サーブレットがアクティブになっており、ディレクトリ D://netscape/server4/docs/servlet/ がサーブレットディレクトリとして登録されている (つまり、サーバがそのディレクトリ内のすべてのファイルをサーブレットとして取り扱う) と仮定します。

  • 次の NameTrans 指令は、要求された URL を D:netscape/Server4/docs/servlet/doCalculation.class に変換する。また、この指令は、名前 ServletByExt を要求に割り当てる

    NameTrans fn="pfx2dir" from="/servlet" dir="D:/Netscape/Server4/docs/servlet" name="ServletByExt"

  • name の割り当ての結果、サーバは ServletByExt という名前のオブジェクトの指令の処理に切り替える。このオブジェクトは、次のように定義されている

    <Object name="ServletByExt">
    ObjectType fn="force-type" type="magnus-internal/servlet"
    Service type="magnus-internal/servlet" fn="NSServletService"
    </Object>

  • ServletByExt オブジェクトには PathCheck 指令がないので、サーバはデフォルトのオブジェクトの PathCheck 指令を処理する。すべての PathCheck 指令が成功すると仮定する

  • 次に、サーバは、ServletByExt オブジェクトに含まれるものから、ObjectType 指令の処理を開始する。この指令は、type 属性を magnus-internal/servlet に設定する

       ObjectType fn="force-type" type="magnus-internal/servlet"

    サーバは、デフォルトのオブジェクトのすべての ObjectType 指令の処理を続けるが、type 属性はすでに設定されているので、この値を変更することはできない

  • Service 指令を処理するときには、サーバは ServletByExt オブジェクトの次の Service 指令から処理を開始する

       Service type="magnus-internal/servlet" fn="NSServletService"

  • この指令の type 引数は、ObjectType 指令により設定された type の値に一致する。したがって、サーバは、NSServletService 関数を呼び出す、この Service 指令の実行に進む。この関数は、要求されたファイルをサーブレットとして呼び出し、サーブレットからの出力をクライアントへの応答として送信する。 (要求されたリソースがサーブレットでない場合は、エラーが発生する。 )

    Service 指令が実行されているので、サーバはその他の Service 指令を実行しない。(ただし、一致するオブジェクト内に実行された Service 指令がなかった場合は、サーバはデフォルトのオブジェクトの Service 指令の確認を続ける。)


デフォルトの Service 指令

ブラウザが送信した要求に一致する Service 指令がほかにない場合は、通常、デフォルトの操作 (ファイルの送信) を実行する Service 指令があります。このデフォルトの指令は、その他の Service 指令が成功していない場合にだけ呼び出されるように、デフォルトのオブジェクト内の Service 指令のリストの最後に記述する必要があります。デフォルトの Service 指令は、通常次のようになります。

Service method="(GET|HEAD|POST)" type="*~magnus-internal/*" fn="send-file"

この指令は、メソッドが GET、HEAD、または POST である要求に一致します。これは、ブラウザが送信するほとんどすべての要求に当てはまります。type 引数の値は、パターンマッチング用の特殊文字を使います。パターンマッチング用の特殊文字の詳細は、付録 C「ワイルドカードパターン」を参照してください。

文字 *~ は、「この後に続く文字に一致しないすべてのもの」を意味するので、*~magnus-internal/ は「magnus-internal/ に一致しないすべてのもの」を意味します。アスタリスク (*) 単独では、すべてのものに一致するので、*~magnus-internal/* 全体は、magnus-internal/ で始まらないすべてのものに一致します。

したがって、サーバがこの指令にたどり着くまでに Service 指令をまだ実行していない場合は、要求のメソッドが GET、HEAD、または POST であり、type 属性の値が magnus-internal/ で始まらないかぎり、この指令を実行します。呼び出される関数は send-file であり、この関数は要求されたファイルの内容をクライアントに送信するだけです。


AddLog

サーバは、応答を生成しクライアントへ送信した後、AddLog 指令を実行してログファイルにエントリを追加します。

すべての AddLog 指令が実行されます。サーバは、エントリを複数のログファイルに追加できます。

どのログファイルを使うか、またログファイルがどの書式を使うかにより、magnus.conf の Init セクションにはログを初期化するための指令が必要になる場合があります。たとえば、AddLog 指令の 1 つが拡張ログ書式を使う flex-log を呼び出す場合は、フレキシブルなログシステムを初期化するために flex-init を呼び出す指令が Init セクションに必要になります。

ログの初期化については、第 7 章「magnus.conf の構文と使用法」の flex-init および init-clf の説明を参照してください。


Error

PathCheck または AuthTrans 指令が要求したリソースへのアクセスを拒否したり、要求したリソースが存在しない場合など、要求の処理プロセス中にエラーが発生する場合は、サーバはただちにすべてのその他の指令の実行を停止し、Error 指令の実行を開始します。



obj.conf の編集上の構文規則


obj.conf ファイルでは、いくつかの規則が重要になります。このファイルの編集は、慎重に行なってください。単純な誤りでも、サーバが起動に失敗したり正しく動作しなくなることがあります。


指令の順序

サーバは指令を obj.conf に記述されている順に実行するので、指令の順序は重要です。一部の指令の結果が、ほかの指令の実行に影響を及ぼします。

PathCheck 指令の場合、サーバがすべての PathCheck 指令を実行するので、PathCheck セクション内の順序はさほど重要ではありません。しかし、ObjectType セクションでは順序は非常に重要です。これは、1 つの ObjectType 指令が属性値を設定すると、その他の ObjectType 指令はその値を変更できないからです。たとえば、デフォルトの ObjectType 指令が次の順序 (これは誤った逆の順序である) の場合は、すべての要求の type の値は text/plain に設定され、サーバには要求されたリソースの拡張子に従って type を設定する機会が与えられません。

ObjectType fn="force-type" type="text/plain"
ObjectType fn="type-by-extension"

同様に、Service セクション内の指令の順序は、非常に重要です。サーバは、現在の要求に一致する最初の Service 指令を実行し、その他は実行しません。


パラメータ

パラメータの個数と名前は、関数によって異なります。行の中でのパラメータの順序は、重要ではありません。


大文字、小文字の区別

obj.conf ファイル内の関数名、パラメータ名、多くのパラメータ値、パス名などの項目では、大文字と小文字が区別されます。


区切り文字

C 言語では、関数名には文字、数字、および下線だけを含めることができます。C コードの関数名の下線 (_) の代わりに、構成ファイルではハイフン (-) 文字を使うことができます。これは、関数名にだけ当てはまります。


引用符

引用符 (") は、文字列に空白文字が含まれるときにだけ文字列値のまわりに必要になります。そうでない場合は、省略可能です。各開始引用符には、対応する終了引用符が必要です。


空白文字

空白文字は、前の行から続いているとき以外は行の先頭に置くことはできません。空白文字は、名前と値を区切る等号 (=) の前後には置くことはできません。空白文字は、行の終わりや空行には置くことはできません。


行の継続

次の行を空白文字またはタブで始めることにより、長い行を次の行に続けることができます。


パス名

Windows NT では、パス名にはバックスラッシュ (\) ではなく必ずスラッシュ (/) を使います。バックスラッシュは、次の文字をエスケープします。


コメント

コメントは、シャープ (#) 記号で始まります。コメントを手動で obj.conf に追加し、その後サーバマネージャインタフェースを使ってサーバの設定を変更した場合には、サーバマネージャは、obj.conf を更新するときにコメントを削除します。



obj.conf 指令の例について


obj.conf ファイル内の行はすべて、以下のキーワードのいずれかで始まります。

AuthTrans
NameTrans
PathCheck
ObjectType
Service
AddLog
Error
<Object
</Object>

このマニュアルの例に出てきた行が上記以外の語で始まっている場合は、折り返されているためそうなっているだけであり、実際のファイルではそうはなりません。マニュアルの PDF および HTML 形式の行の長さの制限によって、このようになることがあります。

たとえば、次の指令は、実際の obj.conf ファイルではすべて 1 行に収まっています。

NameTrans fn="pfx2dir" from="/cgi" dir="D:/netscape/server4/docs/mycgi" name="cgi"


前へ     目次     索引     DocHome     次へ     
Copyright © 2000 Sun Microsystems, Inc. Some preexisting portions Copyright © 2000 Netscape Communications Corp. All rights reserved.

Last Updated September 21, 2001