archive-de.com » DE » K » KW-BERLIN.DE

Total: 256

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • セクションの設定 - Apache HTTP サーバ
    Files セクションの 中にあるディレクティブはどのディレクトリにあるかに関わらず 指定された名前の すべてのファイルに適用されます ですから例えば以下の設定ディレクティブが 設定ファイルの主セクションに書かれたときには すべての場所の private html という名前のファイルへのアクセスを拒否します Files private html Order allow deny Deny from all Files ファイルシステムの特定の場所にあるファイルを指定するために Files セクションと Directory セクションを 組み合わせることができます 例えば 次の設定では var web dir1 private html var web dir1 subdir2 private html var web dir1 subdir3 private html など var web dir1 ディレクトリの下にあるすべての private html へのアクセスを拒否します Directory var web dir1 Files private html Order allow deny Deny from all Files Directory ウェブ空間コンテナ 一方 Location ディレクティブとその正規表現版はウェブ空間上の内容に対して設定を変更します たとえば 次の設定では private で始まる URL パスへのアクセスを制限します 具体的には http yoursite example com private http yoursite example com private123 http yoursite example com private dir file html へのリクエストや 他の同様に private 文字列で始まるリクエストに 適用されます Location private Order Allow Deny Deny from all Location Location ディレクティブはファイルシステムと関係ある必要が全くありません たとえば次の例では どのようにして特定の URL を mod status で提供されている Apache 内部ハンドラにマップするかを示しています ファイルシステムに server status というファイルが存在する必要はありません Location server status SetHandler server status Location ワイルドカードと正規表現 Directory Files Location ディレクティブでは C 標準ライブラリの fnmatch のように shell スタイルのワイルドカードキャラクタが使用できます 文字は任意の文字列にマッチし 文字は任意の 1 文字にマッチし seq は seq の任意の文字にマッチします 文字はどのワイルドカードでもマッチされません 明示的に指定する必要があります これより柔軟なマッチングが必要な場合は これらのコンテナに正規表現 regex 版である DirectoryMatch FilesMatch LocationMatch があり マッチを選択するのに perl 互換 正規表現 を使用できます しかし 次の設定のマージに目を通して regex セクションを使用することで ディレクティブの適用がどのように 変化するか把握しておいてください 全ユーザディレクトリの設定を変更する 非 regex ワイルドカードセクションは次のようになります Directory home public html Options Indexes Directory regex セクションを使用することで 画像ファイルの多くのタイプに対する アクセスを一度に拒否できます FilesMatch i gif jpe g png Order allow deny Deny from all FilesMatch いつ何を使うか ファイルシステムコンテナとウェブ空間コンテナを使い分けるのは 実際には非常に簡単です ファイルシステムに依存する オブジェクトにディレクティブを適応する場合は 必ず Directory か Files を使用します ファイルシステムに依存しないオブジェクト データベースから生成されるウェブページなど にディレクティブを適用する際には Location を使用します ファイルシステム上のオブジェクトへのアクセスを制限するために Location を決して使用ないようにしましょう 同一のファイルシステム位置にマップしている ウェブ空間位置 URL が多数あって 設定した制限を迂回されてしまうかもしれないからです 例えば次の設定を考えてみましょう Location dir Order allow deny Deny from all Location http yoursite example com dir へのリクエストでは上手く動作します しかし大文字小文字を区別しない ファイルシステムを使っていたらどうなるでしょう http yoursite example com DIR へのリクエストで簡単にアクセス制限を迂回されてしまいます これに対して Directory ディレクティブを使用すると どのように呼び出されたかに関わらず その場所から提供される内容に適用されます 例外はファイルシステムのリンクです シンボリックリンクを使って 同一のディレクトリを複数のファイルシステムに設置できます Directory ディレクティブはパス名をリセットすることなくシンボリックリンクを 辿ります ですから 高度なセキュリティが要求される場合は 適切に Options ディレクティブを使用してシンボリックリンクを無効にするべきです 大文字小文字を区別するファイルシステムを使用しているから上記のことは 無関係だと思われるかもしれませんが 同一のファイルシステム位置に複数のウェブ空間位置をマップする方法は 他にいくらでもあるということを覚えていてください ですからできる限りファイルシステムコンテナを使用してください しかしながら一つだけ例外があります Location セクションはどんな URL にも関わらず適用されるので 完全に安全です バーチャルホスト VirtualHost コンテナは特定のホストに適用するディレクティブを格納します 一台のマシンで複数のホストを異なる設定で提供したいときに有用です 詳細に関しては バーチャルホストドキュメント を ご覧下さい プロクシ Proxy と ProxyMatch コンテナは 特定の URL にマッチする mod proxy プロクシサーバを経由してアクセスしたサイトに対してのみ適用される 設定ディレクティブを格納します 例えば次の設定は cnn com ウェブサイトにアクセスするために用いられるプロクシサーバを

    Original URL path: http://xserve.kw-berlin.de/manual/ja/sections.html (2016-02-16)
    Open archived version from archive


  • コンテントネゴシエーション - Apache HTTP サーバ
    ドキュメントにあります Multiviews MultiViews はディレクトリ毎のオプションで httpd conf ファイルの Directory Location Files セクション中や AllowOverride が適切な値に 設定されていると htaccess ファイルで Options ディレクティブによって設定することができます Options All は MultiViews をセットしないことに注意してください 明示的に その名前を書く必要があります MultiViews の効果は以下のようになります サーバが some dir foo へのリクエストを受け取り some dir で MultiViews が有効であって some dir foo が存在 しない 場合 サーバはディレクトリを読んで foo にあてはまる全てのファイルを探し 事実上それらのファイルをマップするタイプマップを作ります そのとき メディアタイプとコンテントエンコーディングは そのファイル名を 直接指定したときと同じものが割り当てられます それからクライアントの要求に一番合うものを選びます サーバがディレクトリの索引を作ろうとしている場合 MultiViews は DirectoryIndex ディレクティブで指定されたファイルを探す過程にも 適用されます 設定ファイルに DirectoryIndex index が書かれていて index html と index html3 が 両方存在していると サーバはその中からどちらかを適当に選びます もしその両方が存在せずに index cgi が存在していると サーバはそれを実行します もしディレクトリを読んでいる際に 文字セット コンテントタイプ 言語 エンコーディングを 指定するための mod mime で認識できる拡張子を持たないファイルが見つかると 結果は MultiViewsMatch ディレクティブの設定に依存します このディレクティブは ハンドラ フィルタ 他のファイル拡張子タイプのどれが MultiViews ネゴシエーションで使用できるかを決定します ネゴシエーション方法 Apache はリソースの variant の一覧を タイプマップファイルか ディレクトリ内のファイル名からかで取得した後 最適な variant を決定するために二つの方法の どちらかを起動します Apache のコンテントネゴシエーションの機能を使うために どのようにしてこの調停が行われるか詳細を知る必要はありません しかしながら この文書の残りでは関心のある人のために 使用されている方法について説明しています ネゴシエーション方法は二つあります 通常は Apache のアルゴリズムを用いた Server driven negotiation が使用されます Apache のアルゴリズムは後に詳細に説明されています このアルゴリズムが使用された場合 Apache はより良い結果になるように 特定の次元において品質の値を 変える ことができます Apache が品質の値を変える方法は後で詳細に説明されています RFC 2295 で定義されている機構を用いてブラウザが特に指定した場合 transparent content negotiation が使用されます このネゴシエーション方法では 最適な variant の決定をブラウザが完全に制御することができます ですから 結果はブラウザが使用しているアルゴリズムに依存します Transparent negotiation の処理の過程で ブラウザは RFC 2296 で 定義されている remote variant selection algorithm を実行するように頼むことができます ネゴシエーションの次元 次元 説明 メディアタイプ ブラウザは Accept ヘッダフィールドで優先傾向を指定します アイテムそれぞれは 関連した品質数値を持つことができます variant の説明も品質数値を持つことができます qs パラメータをご覧下さい 言語 ブラウザは Accept Language ヘッダフィールドで優先傾向を指定します 要素それぞれに品質数値を持たせることができます variants は 0 か 1 つかそれ以上の言語と 関連づけることができます エンコーディング ブラウザは Accept Encoding ヘッダフィールドで優先傾向を指定します 要素それぞれに品質数値を持たせることができます 文字セット ブラウザは Accept Charset ヘッダフィールドで優先傾向を指定します 要素それぞれに品質数値を持たせることができます variant はメディアタイプのパラメータとして文字セットを 指定することもできます Apache ネゴシエーションアルゴリズム ブラウザに返す 最適な variant を もしあれば 選択するように Apache は次のアルゴリズムを使うことができます このアルゴリズムを設定により変更することはできません 次のように動作します まずはじめに ネゴシエーションの次元それぞれについて適切な Accept ヘッダフィールドを調べ variant それぞれに品質を割り当てます もしある次元の Accept ヘッダでその variant が許容できないことが示されていれば それを削除します variant が一つも残っていなければ ステップ 4 に行きます 消去法で 最適な variant を選びます 次のテストが順番に適用されます テストで選択されなかった variant は削除されていきます テスト後 variant が一つだけ残っていれば それを最適なものとして ステップ 3 に進みます 複数 variant が残っていれば 次のテストに進みます variant のメディアタイプの品質数値と Accept ヘッダの品質数値との積を計算して 最高値の variant を選びます 言語品質数値が最高の variant を選びます もしあれば Accept Language ヘッダの言語順か もしあれば LanguagePriority ディレクティブの言語順で最適な言語の variant を選びます 最高 レベル のメディアパラメータ text html メディアタイプのバージョンを与えるために使われます を持つ variant を選びます Accept Charset ヘッダ行で与えられている最高の文字セット メディアパラメータを持つ variant を選びます 明示的に除外されていない限り ISO 8859 1 が許容されるようになっています text メディアタイプであるけれども 特定の文字セットに明示的に関連づけられているわけではない variant は ISO 8859 1 であると仮定されます ISO 8859 1 ではない 文字セットメディアパラメータと 関連づけられている variant を選びます そのような variant がない場合は 代わりに全ての variant を選びます 最適なエンコーディングの variant を選びます もし user agent が許容するエンコーディングがあれば その variant のみを選びます そうではなく もしエンコードされたものとそうでない variant が混ざって存在していたらエンコードされていない variant のみを選びます variant が全部エンコードされているか variant が全部エンコードされていないという場合は 全ての variant を選びます 内容の最も短い variant を選びます 残っている variant の最初のものを選びます タイプマップファイルの最初にリストされているか variant がディレクトリから最初に読み込まれる時に ASCII順でソートしてファイル名が先頭になったか のどちらかです アルゴリズムを使って一つの 最適な variant を選びましたので それを応答として返します ネゴシエーションの次元を指定するために HTTP レスポンスヘッダ Vary が設定されます リソースのキャッシュをする時に ブラウザやキャッシュはこの情報を使うことができます 以上で終わり ここに来たということは variant が一つも選択されなかった ブラウザが許容するものがなかったため ということです 406 ステータス No Acceptable representation を意味する が 利用可能な variant のリストのついた HTML ドキュメントとともに返されます 相違の次元を示す HTTP Vary ヘッダも設定されます 品質の値を変える 上記の Apache ネゴシエーションアルゴリズムの厳格な解釈で 得られるであろう値から Apache は品質数値を時々変えます これは このアルゴリズムで完全ではない あるいは正確でない情報を送る ブラウザ向けによりよい結果を得るために行われます かなりポピュラーなブラウザで もしないと間違った variant を選択する結果になってしまうような Accept ヘッダ情報を送るものもあります ブラウザが完全で正しい情報を送っていれば この数値変化は適用されません メディアタイプとワイルドカード Accept リクエストヘッダはメディアタイプの優先傾向を指定します これはまた image や といった ワイルドカード メディアタイプを含むことができます ここで は任意の文字列にマッチします ですから 次の Accept image を含むリクエストは image ではじまるタイプ全てが許容できる そして他のどんなタイプも許容できる この場合はじめの image は冗長になります ことを示します 扱うことのできる明示的なタイプに加えて 機械的に ワイルドカードを送るブラウザもあります 例えば Accept text html text plain image gif image jpeg こうすることの狙いは 明示的にリストしているタイプが優先されるけれども 異なる表現が利用可能であればそれでも良い ということです しかしながら 上の基本的なアルゴリズムでは ワイルドカードは他の全てのタイプと全く同等なので優先されません ブラウザは にもっと低い品質 優先 値を付けてリクエストを送るべきなのです 例えば Accept text html text plain image gif image jpeg q 0 01 明示的なタイプには品質数値が付けられていませんので デフォルトの 1 0 最高値 の優先になります ワイルドカード は低い優先度 0 01 を与えられているので 明示的にリストされているタイプに合致する variant がない場合にのみ 他のタイプが返されます もし Accept ヘッダが q 値を全く含んで いなければ 望みの挙動をするために Apache は があれば 0 01 の q 値を設定します また type の形のワイルドカードには 0 02 の q 値を設定します ですからこれらは のマッチよりも優先されます もし Accept ヘッダ中のメディアタイプのどれかが q 値を含んでいれば これらの特殊な値は適応 されず 正しい情報を送るブラウザからのリクエストは期待通りに

    Original URL path: http://xserve.kw-berlin.de/manual/ja/content-negotiation.html (2016-02-16)
    Open archived version from archive

  • 動的共有オブジェクト (DSO) サポート - Apache HTTP サーバ
    shared make install サードパーティ Apache モジュール 仮に mod foo c として それを DSO mod foo so にビルド インストール configure add module module type path to 3rdparty mod foo c enable foo shared make install 共有モジュールの 後々のインストール のために Apache を設定 configure enable so make install サードパーティ Apache モジュール 仮に mod foo c として それを apxs を使って Apache ソースツリーの 外で DSO にビルド インストール cd path to 3rdparty apxs c mod foo c apxs i a n foo mod foo la どの場合においても 共有モジュールをコンパイルした後で httpd conf で LoadModule ディレクティブを使って Apache がモジュールを使用するように しなければなりません 背景 最近の Unix 系の OS には 動的共有オブジェクト DSO の動的リンク ロードという気のきいた機構が 存在します これは 実行時にプログラムのアドレス空間に ロードできるような特別な形式でプログラムをビルドすることを 可能にします このロードは二つの方法で行なうことができます 実行プログラムが 起動されたときに ld so というシステムプログラム により自動的に行なわれる方法と 実行プログラム中から システムコール dlopen dlsym による Unix ローダへの プログラムシステムのインタフェースを使って手動で行なう方法とが あります 最初の方法では DSO は普通は 共有ライブラリ や DSO ライブラリ と呼ばれていて DSO の名前は libfoo so や libfoo so 1 2 のようになっています これらはシステムディレクトリ 通常 usr lib に存在し 実行プログラムへのリンクはビルド時に lfoo をリンカに 指定することで確立されます これによりライブラリへの参照が実行プログラムの ファイルに書き込まれて 起動時に Unix のローダが usr lib や リンカの R のようなオプションによりハードコードされたパス 環境変数 LD LIBRARY PATH により設定されたパス の中から libfoo so の場所を見つけることができます それから 実行プログラム中の まだ未解決の シンボルを DSO にあるシンボルで 解決します 普通は実行プログラム中のシンボルは DSO からは参照されません DSO は一般的なコードによる再利用可能なライブラリですので ですから さらなるシンボルの解決は必要ありません シンボルは Unix ローダにより完全な解決が行なわれますので 実行ファイル自身は 何もする必要がありません 実際のところ 静的でない方法でリンクされている すべての実行プログラムに組み込まれている開始用のコードの一部に ld so を起動するコードが含まれています よく使われる ライブラリの動的ロードの利点は明らかです ライブラリのコードは システムライブラリに libc so のようにして一度保存するだけでよく プログラムのために必要なディスクの領域を節約することができます 二つめの方法では DSO は普通は 共有オブジェクト や DSO ファイル と呼ばれていて 任意の拡張子を付けることができます ただし 標準的な名前は foo so です これらのファイルは通常はプログラム専用のディレクトリに置かれ これらを使う実行プログラムへのリンクは自動的にはされません ですので 実行プログラムは dlopen を使って 実行時に手動で DSO をプログラムのアドレス空間にロードする必要があります この時点では実行プログラムに対して DSO のシンボルの解決は行なわれません しかし その代わりに Unix のローダが DSO の まだ未解決の シンボルを 実行プログラムによりエクスポートされたシンボルと既にロードされた DSO ライブラリによりエクスポートされたシンボル 特に どこにでもある libc so のすべてのシンボル で自動的に解決します こうすることで DSO は最初から静的にリンクされていたかのように 実行プログラムのシンボルを知ることができます 最後に DSO の API を利点を生かすために プログラムは 後でディスパッチテーブル など でシンボルを使うことができるように dlsym を使っていくつかのシンボルを解決します すなわち 実行プログラムは必要なすべてのシンボルを手動で解決しなければ なりません この機構の利点はプログラムのオプショナルな部分は 必要になるまでロードする必要がない だからメモリも消費しない ことです 必要ならば 基本プログラムの機能を拡張するために これらの部分を動的にロードすることができます この DSO 機構は簡単なように見えますが 少なくとも一つ難しい点が あります プログラムを拡張するために DSO を使っているときに DSO が実行プログラムからシンボルを解決する点です 二番目の方法 これはなぜでしょうか それは DSO のシンボルを実行プログラムの シンボルから 逆解決 するというのはライブラリの設計 ライブラリはそれを使用するプログラムのことは何も 知らない に反していて この機能はすべてのプラットフォームに あるわけではなく 標準化もされていないからです 実際には実行プログラムのグローバルなシンボルは再エクスポートされることは あまりなく DSO から使うことができません リンカにグローバルシンボルすべてを エクスポートするようにさせる方法を見つけることが 実行時にプログラムを 拡張するために DSO

    Original URL path: http://xserve.kw-berlin.de/manual/ja/dso.html (2016-02-16)
    Open archived version from archive

  • Apache の環境変数 - Apache HTTP サーバ
    SSI チュートリアル を参照してください アクセス制御 allow from env ディレクティブと deny from env ディレクティブを使用して サーバへのアクセスを環境変数の値で制御することができます SetEnvIf ディレクティブと組み合わせることで クライアントの特性に基づいて サーバへのアクセス制御を柔軟に行なうことができるようになります たとえば これらのディレクティブを使用して 特定のブラウザ User Agent からのアクセスを拒否することができます 条件付きログ記録 LogFormat ディレクティブのオプション e を使用することで 環境変数をアクセスログに記録することができます さらに CustomLog ディレクティブの条件分岐式を使用することで 環境変数の値によってリクエストをログに記録するかどうかを決めることができます SetEnvIf ディレクティブと組み合わせることで どのリクエストをログに記録するかを柔軟に制御することが可能になります たとえば gif で終わるファイル名へのリクエストはログに記録しない 違うサブネットのクライアントからのリクエストだけをログに記録する という選択が可能です 条件付き応答ヘッダ Header ディレクティブは環境変数の存在や不在によってクライアントへの応答に特定の HTTP ヘッダを付けるかどうかを決めることができます これにより たとえば クライアントからのリクエスト にあるヘッダがある場合にのみ特定の応答ヘッダを送る というようなことが できます 外部フィルタの適用 ExtFilterDefine ディレクティブを使用して mod ext filter で設定される外部フィルタは disableenv と enableenv オプションを使って 環境変数による条件付き適用ができます URL の書き換え RewriteCond ディレクティブで 評価文字列 として ENV 式を指定することで mod rewrite の書き換えエンジンが環境変数に基いて条件分岐を行なうことができます mod rewrite が使用可能な変数で ENV が前についていない変数は 実際は環境変数ではないということに注意してください それらは他のモジュールからは使用できない mod rewrite 用の特別な変数です 特別な目的の環境変数 互換性の問題を解決するために 特定のクライアントと通信しているときは Apache の動作を変更できる機構が導入されました できるだけ柔軟にするために これらの機構は環境変数を定義することで呼び出されます 普通は BrowserMatch ディレクティブを使いますが たとえば SetEnv ディレクティブや PassEnv ディレクティブも使用することができます downgrade 1 0 これを指定することで リクエストが HTTP 1 0 より新しいプロトコルの場合でも HTTP 1 0 として扱われます force gzip DEFLATE フィルタが使用するように設定されているときに この環境変数はブラウザの accept encoding の設定を無視して常に 圧縮された出力を送るようにします force no vary 応答ヘッダがクライアントに送られる前に Vary フィールドを取り除きます クライアントの中にはこのフィールドを正しく解釈しないものがあります この変数を設定することでその問題を回避することができます この変数を設定すると force response 1 0 が設定されたことになります force response 1 0 これが設定されていると HTTP 1 0 リクエストを発行するクライアントに対しては 常に HTTP 1 0 で応答するようになります この機能は 元々は AOL のプロキシの問題のために実装されました HTTP 1 0 クライアントの中には HTTP 1 1 の応答を返されると正しく動作しないものがあるかもしれません この機能を使用することで そのようなクライアントとの間の互換性問題を解決できます gzip only text html これが 1 に設定されると この変数は text html 以外のコンテントタイプに対する mod deflate 提供の DEFLATE 出力フィルタを無効にします また 静的に 既に圧縮されたファイルを使用したい場合 gzip だけでなく identity と異なる全てのエンコードに対して mod negotiation も変数を評価します no gzip セットされると mod deflate の DEFLATE フィルタがオフになります そして mod negotiation はエンコードされたリソースを送らないようにします nokeepalive これが設定されている場合は KeepAlive を使用しないようにします prefer language mod negotiation の挙動に影響を与えます en ja x klingon といった 言語タグが格納されていれば その言語の variant を送信しようとします そのような variant がない場合は 通常の ネゴシエーション 処理が 適用されます redirect carefully これはクライアントへのリダイレクトの送信をサーバがより注意深く 行なうようにします これは通常 リダイレクトに際してクライアントに 問題があることが分かっている場合に使われます この機能は元々は マイクロソフトのウェブフォルダのソフトが DAV メソッドによるディレクトリのリソースへのリダイレクトの扱いに 問題がり それを回避するために実装されました suppress error charset Apache 2 2 以降で利用可能 クライアントのリクエストに対する応答としてリダイレクトを送信する際 レスポンスにはリダイレクトが自動的に行なえない 行なわれない 場合に表示するテキストが含まれます 通常 このテキストに合致したキャラクタセット ISO 8859 1 でラベル付けをします しかし リダイレクト先が別の文字セットを使っている場合 ある問題のあるブラウザのバージョンでは リダイレクト先の実際の文字セットの代わりに リダイレクト元の文字セットを使ってしまうことがあります その結果 例えば変な描画が行なわれたりして 読めなくなったりします この環境変数を設定することで リダイレクションテキストに対する キャラクタセットの指定を除去しますので それら問題のあるブラウザでも リダイレクト先の文字セットを正しく使うようにできます force proxy request 1 0 proxy nokeepalive proxy sendchunked proxy sendcl これらの指示子は mod proxy の挙動を変更します 詳細は mod proxy のドキュメントをご参照ください 例 おかしな挙動をするクライアントに対してプロトコルの動作を変更する クライアントに関する既知の問題に対処するために 以下の行を httpd conf に入れることを推奨しています 古いバージョンの Apache では クライアントの問題に対応するために

    Original URL path: http://xserve.kw-berlin.de/manual/ja/env.html (2016-02-16)
    Open archived version from archive

  • ログファイル - Apache HTTP サーバ
    HTTP 1 0 200 2326 このログエントリのそれぞれの部分の意味は以下で説明します 127 0 0 1 h これはサーバへリクエストをしたクライアント リモートホスト の IP アドレスです HostnameLookups が On の場合は サーバはホスト名を調べて IP アドレスが書かれているところに記録します しかし この設定は サーバをかなり遅くするので あまりお勧めできません そうではなく logresolve の ようなログの後処理を行なうプログラムでホスト名を調べるのが良いでしょう ここに報告される IP アドレスは必ずしもユーザが使っているマシンの ものであるとは限りません ユーザとサーバの間にプロキシサーバが あれば このアドレスは元のマシンのものではなく プロキシの アドレスになります l 出力中の ハイフン は要求された情報が手に入らなかったということを 意味します この場合 取得できなかった情報はクライアントのマシンの identd により決まる RFC 1413 のクライアントの アイデンティティです この情報はあまり信用することができず しっかりと管理された内部ネットワークを除いては使うべきではありません Apache は IdentityCheck が On になっていない限り この情報を得ようとすらしません frank u これは HTTP 認証による ドキュメントをリクエストした人の ユーザ ID です CGI スクリプトには通常同じ値が REMOTE USER 環境変数として与えられます リクエストのステータスコード 以下を参照 が 401 であった場合は ユーザは認証に失敗しているので この値は信用できません ドキュメントがパスワードで保護されていない 場合は このエントリは前のものと同じように に なります 10 Oct 2000 13 55 36 0700 t サーバがリクエストを受け取った時刻です 書式は day month year hour minute second zone day 2 digit month 3 letter year 4 digit hour 2 digit minute 2 digit second 2 digit zone 4 digit ログのフォーマット文字列に format t を 指定することで 別の形式で時刻を表示させることもできます このとき format は C の標準ライブラリの strftime 3 の形式になります GET apache pb gif HTTP 1 0 r クライアントからのリクエストが二重引用符の中に示されています リクエストには多くの有用な情報があります まず この場合クライアントが 使ったメソッドは GET です 次に クライアントは リソース apache pb gif を要求しました そして クライアントはプロトコル HTTP 1 0 を使用しました リクエストの各部分を独立にログ収集することもできます 例えば フォーマット文字列 m U q H は メソッド パス クエリ文字列 プロトコルをログ収集し 結局 r とまったく同じ出力になります 200 s サーバがクライアントに送り返すステータスコードです この情報は リクエストが成功応答 2 で始まるコード であったか リダイレクション 3 で始まるコード であったか クライアントによる エラー 4 で始まるコード であったか サーバのエラー 5 で始まるコード であったか を表すので 非常に大切です ステータスコードの 完全なリストは HTTP 規格 RFC2616 第 10 節 にあります 2326 b この最後のエントリはクライアントに送信されたオブジェクトの 応答ヘッダを除いたサイズを表します コンテントがクライアントに送られなかった 場合は この値は になります コンテントが無い場合に 0 をログ収集するには b ではなく B を使ってください Combined Log Format もう一つのよく使われる書式は Combined Log Format と呼ばれています 以下のようにして使うことができます LogFormat h l u t r s b Referer i User agent i combined CustomLog log access log combined この書式の最初の方は Common Log Format とまったく同じで 最後に 二つ追加のエントリがあります 追加のエントリはパーセントディレクティブ header i を使っています ここで header は HTTP のリクエストヘッダのどれかです この書式による アクセスログは以下のような感じになります 127 0 0 1 frank 10 Oct 2000 13 55 36 0700 GET apache pb gif HTTP 1 0 200 2326 http www example com start html Mozilla 4 08 en Win98 I Nav 追加のエントリは http www example com start html Referer i Referer 意図的な綴り間違い HTTP リクエストヘッダです これはクライアントが報告してくる参照元のサイトを表します この場合は apache pb gif にリンクしているか それを含んでいるページです Mozilla 4 08 en Win98 I Nav User agent i User Agent HTTP リクエストヘッダです これはクライアントのブラウザが 自分自身のことを報告してくる情報です 複数のアクセスログ 複数のアクセスログは単に設定ファイルに複数の CustomLog ディレクティブを書くことで作成されます 例えば 以下のディレクティブは 三つのアクセスログを作ります 最初のものは基本的な CLF の情報で 二つ目と三つ目は referer とブラウザの情報です 最後二つの CustomLog は ReferLog ディレクティブと AgentLog ディレクティブの効果をまねる方法を示しています LogFormat h l u t r s b common CustomLog logs access log common CustomLog logs referer log Referer i U CustomLog logs agent log User agent i この例は LogFormat で ニックネームを定義する必要がない ということも示しています ニックネームの代わりに CustomLog ディレクティブに 直接ログの書式を指定することができます 条件付きログ クライアントのリクエストの特徴に基づいてアクセスログにエントリの 一部をロギングしない方が便利なことがあります これは 環境変数 の補助により簡単に実現できます まず リクエストが何らかの条件に合うということを表すために環境変数が 設定される必要があります これは通常は SetEnvIf により 行なわれます そして CustomLog ディレクティブの env 節を使って環境変数が設定されているリクエストを 含めたり排除したりすることができます いくつか例を挙げます Mark requests from the loop back interface SetEnvIf Remote Addr 127 0 0 1 dontlog Mark requests for the robots txt file SetEnvIf Request URI robots txt dontlog Log what remains CustomLog logs access log common env dontlog 他の例として 英語を話す人からのリクエストとそれ以外の人からのリクエストを 分けたい という場合を考えてみてください SetEnvIf Accept Language en english CustomLog logs english log common env english CustomLog logs non english log common env english ここまででは条件付きロギングが非常に強力で柔軟であることを示してきましたが それがログの内容を制御する唯一の方法というわけではありません ログファイルは サーバの活動の完全な記録である方がより役に立ちます 単純にログファイルを 後処理して 考慮したくないログを削除する方が簡単であることがよくあります ログの交替 普通の負荷のサーバでさえ ログファイルに保存される情報の量は 膨大になります アクセスログのファイルは普通 10 000 リクエスト毎に

    Original URL path: http://xserve.kw-berlin.de/manual/ja/logs.html (2016-02-16)
    Open archived version from archive

  • URL からファイルシステム上の位置へのマップ - Apache HTTP サーバ
    ディレクティブや ScriptAliasMatch ディレクティブ を使って強力な 正規表現 に基づいたマッチと 置換を行なうことができます たとえば ScriptAliasMatch a zA Z0 9 cgi bin home 1 cgi bin 2 は http example com user cgi bin script cgi への リクエストを home user cgi bin script cgi というパスへ マップし このマップの結果としてのファイルを CGI スクリプトとして 扱います ユーザディレクトリ 伝統的に Unix システムではユーザ user のホームディレクトリを user として参照できます mod userdir モジュールはこの概念をウェブに拡張して それぞれのユーザのホームディレクトリのファイルを 以下のような URL を使ってアクセスできるようにします http www example com user file html セキュリティの観点から ウェブからユーザのホームディレクトリへ 直接アクセスできるようにすることは適切ではありません ですから UserDir ディレクティブには ユーザのホームディレクトリの下の ウェブファイルの 置かれているディレクトリを指定します デフォルトの設定の Userdir public html を使うと 上の URL は home user public html file html というようなファイルに マップされます ここで home user は etc passwd で指定されているユーザのホームディレクトリです Userdir には etc passwd にホームディレクトリの位置が書かれていない システムでも使うことのできる他の形式もあります 中にはシンボル 7e のように符号化されることが多い を格好が悪いと思って ユーザのディレクトリを表すために別の文字列の 使用を好む人がいます mod userdir はこの機能をサポートしていません しかし ユーザのホームディレクトリが規則的な構成のときは AliasMatch を使って望みの 効果を達成することができます たとえば http www example com upages user file html が home user public html file html にマップされるようにするには 以下のように AliasMatch ディレクティブを使います AliasMatch upages a zA Z0 9 home 1 public html 2 URL リダイレクション 上の節で説明した設定用のディレクティブは Apache に ファイルシステムの特定の場所からコンテンツを取ってきて クライアントに送り返すようにします ときには その代わりに クライアントにリクエストされたコンテンツは別の URL にあることを 知らせて クライアントが新しい URL へ新しいリクエストを行なうように する方が望ましいことがあります これは リダイレクション と 呼ばれていて Redirect ディレクティブにより実装されています たとえば DocumentRoot の下のディレクトリ foo が新しいディレクトリ bar に移動したときは 以下のようにしてクライアントが新しい場所のコンテンツをリクエストするように 指示することができます Redirect permanent foo http www example com bar これは foo で始まるすべての URL Path を www example com サーバの bar が foo に置換されたものにリダイレクトします サーバは自分自身のサーバだけでなく どのサーバにでもクライアントを リダイレクトすることができます Apache はより複雑な書き換えの問題のために RedirectMatch ディレクティブを 提供しています たとえば サイトのホームページを違うサイトにリダイレクト するけれど 他のリクエストはそのまま扱う というときは以下の設定を 使います RedirectMatch permanent http www example com startpage html あるいは 一時的にサイトのすべてのページを他のサイトの特定の ページへリダイレクトするときは 以下を使います RedirectMatch temp http othersite example com startpage html リバースプロキシ Apache は遠隔地にあるドキュメントをローカルのサーバの URL 空間に 持ってくることもできます この手法は リバースプロキシ と呼ばれています ウェブサーバが遠隔地のドキュメントを取得してクライアントに送り返すのが プロキシサーバの動作のように見えるからです クライアントにはドキュメントが リバースプロキシサーバから送られてきているように見える点が通常の プロキシとは異なります 次の例では クライアントが foo ディレクトリの下にある ドキュメントをリクエストすると サーバが internal example com の bar ディレクトリから取得して さもローカルサーバからの ドキュメントのようにしてクライアントに返します ProxyPass foo http internal example com bar ProxyPassReverse foo http internal example com bar ProxyPassReverseCookieDomain internal example com public example com ProxyPassReverseCookiePath foo bar ProxyPass ディレクティブは サーバが適切なドキュメントを取得するように設定し ProxyPassReverse ディレクティブは internal example com からのリダイレクトがローカルサーバの 適切なディレクトリを指すように書き換えます 同様に ProxyPassReverseCookieDomain

    Original URL path: http://xserve.kw-berlin.de/manual/ja/urlmapping.html (2016-02-16)
    Open archived version from archive

  • サーバ全体の設定 - Apache HTTP サーバ
    UseCanonicalName UseCanonicalPhysicalPort ServerAdmin ServerTokens UseCanonicalPhysicalPort ディレクティブは エラーメッセージなどのサーバが作るドキュメントに どのようなサーバの情報を表示するかを制御します ServerTokens ディレクティブは Server HTTP レスポンスヘッダフィールドの値を設定します ServerName ディレクティブと UseCanonicalName ディレクティブは サーバが自分自身を参照する URL を作るときに使われます たとえば クライアントがディレクトリを要求して そのディレクトリ名の最後にスラッシュが付いていないような場合には ドキュメントの相対的な参照を正しく解決できるようにするために Apache は最後のスラッシュを含んだ完全なパスにクライアントを リダイレクトさせる必要があります ファイルの位置 関連モジュール 関連ディレクティブ CoreDumpDirectory DocumentRoot ErrorLog LockFile PidFile ScoreBoardFile ServerRoot これらのディレクティブは Apache が適切な動作をするために必要な各種ファイルの位置を制御します パスがスラッシュ で始まっていないときは ファイルは ServerRoot からの相対パスとして 探されます root 以外のユーザが書き込み可能なパスにファイルを置く場合は注意が必要です 詳細は セキュリティ情報 を参照してください リソースの制限 関連モジュール 関連ディレクティブ LimitRequestBody LimitRequestFields LimitRequestFieldsize LimitRequestLine RLimitCPU RLimitMEM RLimitNPROC ThreadStackSize LimitRequest ディレクティブは Apache がクライアントからのリクエスト読み込みで使う リソースを制限するために使われます これらの値を制限することで いくつかのサービス拒否攻撃は影響を和らげることができます RLimit

    Original URL path: http://xserve.kw-berlin.de/manual/ja/server-wide.html (2016-02-16)
    Open archived version from archive

  • Apache の SSL/TLS 暗号化 - Apache HTTP サーバ
    tr Apache HTTP サーバモジュール mod ssl が OpenSSL ライブラリへのインターフェースを提供していますが これは Secure Sockts Layer と Transport Layer Security プロトコルを用いた強力な暗号化を提供します このモジュールやこの文書は Ralf S Engelschall の mod ssl プロジェクトに基づいています Documentation mod ssl Documentation はじめに 互換性 How To よくある質問 用語 mod ssl このモジュールで提供されるディレクティブや環境変数に関する 詳しい文書は

    Original URL path: http://xserve.kw-berlin.de/manual/ja/ssl/ (2016-02-16)
    Open archived version from archive



  •