[an error occurred while processing this directive]
[APACHE DOCUMENTATION]

Apache HTTP Server Version 1.3

Apache Server Frequently Asked Questions

$Revision: 1.94 $ ($Date: 1997/11/11 23:47:15 $)

この FAQ の最新版はメインの Apache サイトである <http://www.apache.org/docs/misc/FAQ> から入手できます。

この FAQ のテキスト版を読んでいるのなら、同封されたものの数に気付くかもしれません("[12]" のように)。これらはドキュメントの終わりにある URL 参照のリストに関するものです。これらの参照は、ハイパーテキスト版については現れていませんし、必要とされていません。

The Questions


The Answers

Background

  1. Apacheとはなんですか?

    Apacheはもともと人気の高いHTTPサーバのNCSA httpd 1.3 (1995初旬)のコードとアイデアに基づいていました。それ以来機能性、効率とスピードに関して他のいかなるUNIXベースのHTTPサーバに匹敵(そして恐らく凌ぐ)する良いシステムに発展しました。

    それを始めて以来、コードは完全に書き直され、また多くの新しい機能を組み込みました。Apacheは Netcraft調査によれば、インターネット上で1997年1月現在、最も人気が高いWWW サーバーです。


  2. なぜApacheを作ったのですか?

    wwwプロバイダーのグループとパートタイムのhttpdプログラマのaddress concerns に、その httpdは期待通りに動いてくれませんでした。 完全にApacheは商業ではなく、そのメンバーによって資金を供給される完全にボランティアの努力によるものです。


  3. Apacheグループは他のNCSA'sのようなサーバの尽力とどう関係してるのですか?

    我々はもちろん、Apacheが開発のベースにしたことに関して、NCSAとそのプログラマーに多大な借りがあります。しかしながら、我々のサーバを持っています。そして我々のプロジェクトはたいてい我々自身によるものです。Apacheプロジェクトは完全に他に依存しないベンチャーです。


  4. なぜ名前が"Apache"なのですか?

    ぴったりのキュートな名前です。 Apahceは "A PAtCHy (つぎはぎの/寄せ集めの) サーバ"です。それは若干の既存のコードと一連の「パッチファイル」に基づいていました。


  5. OK,それでApacheは他のどのサーバに匹敵しますか?

    他に依存しない評価のためにhttp://webcompare.iworld.com/compare/chart.html を見てください。

    Apacheは他の多くのフリーサーバより速いことが十分に証明されました。ある特定の製品サーバがApacheの速さ(これらのベンチマークのいずれもWWWサーバの性能を測定する良い方法であるとは証明されなかった)を凌ぐと主張したけど、我々は「ほとんど」高速のフリーサーバを持つことは、何千ドルもの費用がかかる「極めて」高速のサーバより良いと感じています。Apacheは1日に何百万ヒットするサイトでも走らせられ、そして運用の困難も感じられません。


  6. Apacheはどれぐらい完全にテストされましたか?

    Apacheは1997年7月現在500,000以上、インターネットのサーバで運用されています。それは完全にデベロッパーとユーザー両方によってテストされました。Apacheグループは新しいバージョンをリリースする前の厳密なテスト標準を維持しています。そして、我々のサーバーはすべての WWW サーバーの3分の1の上に上に支障無く実行できます。バグが発生した時、使えるようになったらすぐに、パッチや新しいバージョンをリリースします。

    Apache プロジェクトのウェブサイトはsites running Apacheの部分的なリストを持っています。


  7. Apacheの将来の予定は?


  8. サポートのために誰とコンタクトを取れますか?

    Apacheの正式なサポートはありません。 開発者のだれも、他でも解決できる些細な質問の洪水に巻き込まれることを望み ません。 バグレポートと提案は バグレポート・ページ から送ってください。 他の質問は、comp.infosystems.www.servers.unix宛てにするべきです。 そこにはApacheチームが潜んでいます。 httpdの指導者たちの仲間が助けてくれるでしょう。

    しかし、いくつかのサードパーティから有償サポートが受けられます。


  9. さらに多くのApacheの情報はありますか?

    あります。メインの Apache web siteを見てください。Apache Weekと呼ばれる、役に立つ定期的な電子出版もあります。Apache Weekの記事に関連したリンクがその場所にあります。Apache-specific booksにもいくつかあります。


  10. どこからApacheを手に入れられますか?

    Apacheのソースはmain web page で見つけられます。


Technical Questions

  1. "なぜできないのか?なぜ動かないのか?" 問題となる場合の対処方

    Apache サーバソフトウェアについてトラブルがあるときは、以下の手順を踏むべきです:

    1. エラーログの確認!

      Apache は問題に遭遇すると、助けになろうとします。多くの場合、詳細か、サーバエラーログに対するメッセージを与えます。時々、これは問題の対処方を診断するのに十分です(ファイルの許可やそのようなもの)。エラーログのデフォルトロケーションは/usr/local/apache/logs/error_logですが、サーバのロケーションのためのコンフィグファイルにあるErrorLog命令も見てください。

    2. FAQを確認!

      Apache で頻繁に質問されることについてのリストの最新版は、常にメインの Apache ウェブサイトで見ることができます。

    3. Apache バグデータベースの確認

      Apache グループで報告されている問題のほとんどは、bug databaseに記録されています。追加する前に、開いているのか、閉じられているのかの、報告の存在を確認してください。問題がすでに報告されていたら、報告を追加しないでください。もしオリジナルの報告がまだ閉じられていなかったら、定期的に確認することを勧めます。オリジナルの報告者にコンタクトを取ってもよいでしょう。なぜなら、データベースに記録されていない問題については email が変わっているかもしれないからです。

    4. comp.infosystems.www.servers.unixUSENET newsgroupでの質問

      多くの一般的な問題はcomp.infosystems.www.servers.unixニュースグループでの大きなトラフィックがあるので、データベースに首尾よく到達することはありません。多くの Apache ユーザと数人の開発者が、そのバーチャルホールを歩き回っているのが見られますので、そこで知識を得ることをお勧めします。たとえ、既に投稿されたあなたの質問を見なくても、バグデータベースからよりもずっと早く答えを得る機会があります。

    5. 全てが他に失敗していれば、バグデータベースの問題に登録してください。

      適切な上記の手順で問題が解決しなかった場合には、logging a bug reportによる問題について Apache グループに知らせてください。

      もし問題がサーバのクラッシュを巻き込み、コアダンプを生じたら、バックトレースを含んでください(もし可能なら)。例としては、

      # cd ServerRoot
      # dbx httpd core
      (dbx) where

      (ServerRoothttpdcoreファイルの適当なロケーションを代用してください。dbx の代わりに gdb を使ってもいいです。)


  2. 存在する NCSA 1.3 セットアップと Apache はどのくらい互換性がありますか?

    Apache は全ての特徴と NCSA httpd 1.4 と NCSA httpd 1.5 にある多くの追加の特徴のように NCSA httpd 1.3 のコンフィギュレーションのオプションを提供しようとします。

    NCSA httpd は今は要求されない実験的な特徴を追加するようにします。実験的な物のいくつかは、他の物が必然的に落とされていく一方で、継承していくでしょう。Apache の哲学は、必要とされているときに、必要とされているものを追加していくことです。

    Apache と NCSA 開発者の友好関係は、基本的な特徴の発展が、近い将来に二つのサーバで矛盾しなくなることを保証します。


  3. ScriptAlias とは異なるディレクトリで CGI の実行を可能にするにはどうしたら良いでしょうか?

    Apache は通常のドキュメントとして処理するよりもむしろ、実行の資格があるScriptAlias として名付けられたディレクトリにある全てのファイルを認識しています。これはファイル名とは無関係に適用するので、ScriptAlias のディレクトリにあるスクリプトは "*.cgi" とか "*.pl" というふうに名付ける必要がありません。言い換えると、ScriptAliasディレクトリにある全てのファイルは、Apache に関する限りはスクリプトです。

    通常のドキュメントも残っているかもしれないディレクトリにあるように、他のロケーションで Apache がスクリプトを実行することを確信するには、それらをどのように認識して、それを実行できるのかどうかも見分けなければなりません。このためには、AddHandler 命令のような、なにかを使うことが必要です。

    1. サーバコンフィギュレーションファイルの適当なセクションには、以下ような行を追加します。

      AddHandler cgi-script .cgi

      サーバはそれから、ロケーションにある、拡張子が ".cgi" である全てのファイルがスクリプトファイルであって、ドキュメントではないことを認識します。

    2. ディレクトリのロケーションが ExecCGI オプションを含んでいるOptions通知によってカバーされていることを確認してください。

    ある場合には、実行可能にされた "*.cgi" と名付けられた全てのファイルを実際に許可するローカルな手段に従わないようにできます。おそらく、実行できる通常のディレクトリにある特別なファイルを可能にしたいのでしょうから、これは代わりに mod_rewrite と以下の手順によって成し遂げられます:

    1. この一つに類似するルールセットを、該当する .htaccess ファイルにローカルに追加してください:

      RewriteEngine on
      RewriteBase /~foo/bar/
      RewriteRule ^quux\.cgi$ - [T=application/x-httpd-cgi]

    2. ExecCGIFollowSymLinks オプションを含んでいる Options 通知によってディレクトリロケーションがカバーされていることを確認してください。


  4. "早すぎるスクリプトヘッダのエンド" で CGI が失敗することは、何を意味していますか?"?

    それは、サーバは HTTP ヘッダ(空行に続く一つかそれ以上)のセットの完了を待っていて、そうならなかった、ということを意味します。

    この問題の最も一般的な原因は、サーバに対してヘッダの完全なセットか、出来る限りの全てを送信する前に、スクリプトが死んでしまうことです。このような場合には、サーバでのスクリプトとしてよりもむしろ、双方向のセッションからスクリプトを単独で走らせようとします。エラーメッセージが出たら、ほとんどが "スクリプトヘッダの早すぎるエンド" のメッセージです。

    次によくある原因は(要求されたヘッダの出力を全くしない人は別にして)、Perl の出力バファーとの相互作用によるものです。それぞれの出力ステートメントの後、Perl にそのバファーをフラッシュさせるためには、HTTP ヘッダを送信する printwrite ステートメントのまわりに、以下のステートメントを挿入してください:

    {
     local ($oldbar) = $|;
     $cfh = select (STDOUT);
     $| = 1;
     #
     # print your HTTP headers here
     #
     $| = $oldbar;
     select ($cfh);
    }

    これは、stdoutに対して出力を送信するスクリプトから外部プログラムを呼ぶときか、あるいは、もしヘッダが送られて、実際にコンテンツがエミットされ始めた時間の間に大きな遅れがあれば、大体必然的なものです。パフォーマンスを最大にするには、上に示したように、ヘッダを送信するステートメントの後に、buffer-flushing を off に戻す($| = 0 か、それと等しいもので)べきです。

    もしスクリプトが Perl で書かれていなかったら、使用している言語が何であれ(例えば、C だったらヘッダを書いた後に fflush() を呼びます)、同等のものにしてください。


  5. どうしたら SSI (parsed HTML)が可能になりますか?

    SSI(Server-Side Include) 命令は、static HTML を許可します(例えば、Apacheによってクライアントに配送されたとき)。SSI 命令のフォーマットは、Apache が SSI だけでなく、xSSI(eXtended SSI) 命令もサポートするのに十分である mod_include manual でカバーされます。

    ランタイム時のドキュメントの処理は、parsing と呼ばれます。それゆえに、"parsed HTML" という単語は、SSI 説明書を含んでいるドキュメントについて時々使っていました。parsing は極端なリソース消費になる傾向があり、デフォルトでは不可能です。さらにサーバに負担をかけるようなドキュメントの貯蔵を妨害できます(この詳細についれは、next questionを見てください)。

    SSI 処理を可能にするには

    追加情報については、Using Server Side Includes にある Apache Week 記事を参照してください。


  6. なぜ解析されたファイルがキャッシュされないのですか?

    サーバはクライアントに送られたコンテンツを変更するかもしれない SSI 命令をランタイム処理するので、結果として最終的なサイズはどうなったか、解析された結果は同じなのかどうか、ということは解析し始める時にはわかりません。これは、Content-LengthLast-Modified ヘッダを生成できないことを意味します。キャッシュは一般に、サーバによって運ばれてキャッシュにある Last-Modified を比較することによって作動します。 ドキュメントが変わったかどうかを言わないキャッシュがどうであれ、サーバは解析されたドキュメントについてヘッダを送信しないので、安全なところで再び取ってくることになります。

    Expires ヘッダを生じさせることによって、これを予備手段にします(詳細についてはmod_expiresドキュメントを見てください)。もう一つの可能性としては、 解析されたファイルの最新の修正時間を基にした Last-Modified ヘッダを送信すること(XBitHack 命令の記述にある、詳述された確かな環境下で)を Apache に教える、XBitHack Fullメカニズムを使うことです。 もし解析されたファイルが変わらないで、挿入された SSI のコンテンツが変わったら これは実際にはクライアントに働いているのかもしれません; もし含まれているコンテンツが時々変わったら、これはキャッシュされた古いコピーになることができます。


  7. どうすれば解析されたスクリプトの出力を得ることができますか?

    CGI スクリプトから出力に SSI 命令を含ませたいが、どうしたらいいのかわからない。短的に言えば、答えは"できない"です。これは潜在的にセキュリティの障害であり、さらに重要なことに、現在のサーバ API では、あまりうまく実行されません。次善策としては、SSI が行っていることをスクリプト自身に代わって行うことです。結局、それはコンテンツの残りを生じます。

    これは、Apache グループが 1.3 以降の主要なリリースで追加したい特徴です。


  8. Apache はプロキシーサーバとして動きますか?

    Apache version 1.1 とそれ以上では、proxy moduleで行っています。もしコンパイルされれば、これはキャッシュするプロキシーサーバとしてApache をメイクするでしょう。


  9. "multiviews"とは何ですか?

    "Multiviews" とは、リクエストに対するレスポンスに言語を特定化するドキュメント変数を与える Apache サーバの機能に付けられた一般名です。これは content negotiation の説明のページに全て書かれています。そのほかにも、Apache Week は "Content Negotiation Explained" にある記事で行っています。


  10. なぜ <n> 以上のバーチャルホストを走らせることができないのですか?

    おそらく、OS のリソース制限の中で走らせています。最も一般的な制限は、バーチャルホストを追加しているときに見られる問題の原因である、file descriptors でのプロセス毎の制限です。Apache がしばしば直感的なエラーメッセージを与えないのは、通常、ファイル記述を必要とし、それを得られなかったときでもはっきりとは不満を言わない(gethostbyname() のような)いくつかのライブラリルーチンのせいです。

    それぞれのログファイルは、もしそれぞれのバーチャルホストの分離したアクセスとエラーログを使えば、それぞれのバーチャルホストは2つのファイル記述を必要とすることを意味するファイル記述を要求します。それぞれの Listen 命令もまたファイル記述を必要とします。

    <n> についての典型的な値は 128 か 250 付近です。サーバがファイル記述制限にぶつかると、SIGSEGV のコアを破棄して、hang するか、あるいはエラーログの(たぶん意味のある)エラーに沿って limp するかもしれません。ファイル記述制限下で走っているときに起こる一つの一般的な問題は、適切に実行された CGI スクリプトの停止です。

    これについてできることは:

    1. Listen 命令の数を減らしてください。同じポート上のマシンで走っているサーバがなければ、普通は Listen 命令は全く必要ありません。デフォルトでは、Apache は port 80 で全てのアドレスに聞きます。
    2. ログファイルの数を減らしてください。 ログファイルにあるバーチャルホスト名を含んでいる間、単一のログファイルに対する全てのリクエストをログするために、mod_log_config を使うことができます。もし必要であれば、ログファイルを分かれたファイルに分割するスクリプトを書くことができます。
    3. サーバに対してファイル記述の有効な数を増やしてください(limitulimit コマンドでのシステムのドキュメントを見てください)。いくつかのシステムについては、これをどのように行うかについての情報が performance hints ページで入手できます。FreeBSD のための特別な注意が以下にあります。
    4. "これはやめてください" - 少ないバーチャルホストで走らせようとすること
    5. 複数のサーバ処理を横断する操作か(例えば Listen を使うが、最初の点を見る)、ポートを延展することを行ってください。

    これは OS の制限ですので、解決方法が他にあまりありません。

    1.2.1 のように、たくさんの記述で走ることに関する様々な制限の次善策を試みようとしています。詳しくはここです。


  11. FreeBSD で FD_SETSIZE を増やすことはできますか?

    3.0 以前の FreeBSD のバージョンでは、FD_SETSIZE はデフォルトを 256 に定義しています。これは Apache で 256 以上のファイル記述を使うとトラブルになることを意味しています。これは増やすことはできても、扱いにくいものです。もし 2.2 以前のバージョンを使っていれば、より大きな FD_SETSIZE でカーネルを再コンパイルする必要があります。これは以下のような行を追加することによって行われます:

    options FD_SETSIZE nnn

    カーネルコンフィグファイルに対して、バージョン 2.2 で始めると、これは最早必要ありません。

    もし使っているバージョンが 1997/03/10 以降の 2.1 か、あるいは 1997/06/28 以前の 2.2 か 3.0 なら、 libc がコンパイルされるときに FD_SETSIZE がセットされるより、多くのファイル記述からそれを避ける解決のためのライブラリに制限があります。これを増やすためには、高い FD_SETSIZE で libc を再コンパイルしなければなりません。

    FreeBSD 3.0 では、デフォルトの FD_SETSIZE は 1024 に増やされており、解決のためのライブラリにある上記に制限は外されています。

    上記の適切な変化を扱った後、コンフィギュレーションファイルで "-DFD_SETSIZE=nnn" を EXTRA_CFLAGS に追加することによって、Apache のコンパイル時に FD_SETSIZE の設定を増やすことができます。


  12. なぜフォーム POST リクエストで "access denied" になってしまうのでしょうか?

    この原因として多いのは、GET メソッドを指名するだけの <Limit> セクションです。以下と共通点があって、POST-handling スクリプトがあるロケーションに影響するものについてはコンフィギュレーションファイルを見てください:

    <Limit GET>
        :

    <Limit GET POST> に変えると、おそらく問題はなくなるでしょう。


  13. ウェブページ認証のために /etc/passwd ファイルを使うことはできますか?

    はい、できます。しかし、それは良くないです。ここに、いくつか理由があります:

    もし上記の不利益を考慮してもまだ、これを行いたければ、メソッドはリーダーのための動作試験として残されます。Apache の保証を排出すると、にもかかわらず、積み重ねられた UNIX の guru ポイントを失うことになるでしょう。


  14. なぜ ErrorDocument 401 が働かないのですか?

    フォームの "/foo/bar" の URL でそれを使う必要があり、"http://host/foo/bar" のようなメソッドとホスト名では必要ありません。詳細については ErrorDocument のドキュメントを見てください。これは過去に不正確に記述されていました。


  15. なぜスタートアップで"setgid: Invalid argument" を得るのですか?

    Group 命令は(おそらく conf/httpd.conf で)、/etc/groupファイル(か、またはシステムと同等の)に実際に存在するグループの名前をつける必要があります。


  16. なぜ Apache はあらゆるレスポンスにクッキーを送るのですか?

    Apache は mod_cookies モジュールで再コンパイルしない限り、全てのレスポンスに自動的にクッキーを送信したりはしません。このモジュールは 1.2 より前の Apache で配布されています。このモジュールはトラックユーザを助け、このためにクッキーを使うかもしれません。もし mod_cookies によって生じたデータを使わなければ、Apache にはそれをコンパイルしないでください。1.2 でこのモジュールは、より正確な名前である mod_usertrack に名前が変えられ、クッキーは CookieTracking 命令で特別に可能にされています。


  17. mod_cookies にコンパイルして、なぜクッキーは動かないのですか?

    最初に、正しくスクリプトが働くために mod_cookies にコンパイルする必要はありません(mod_cookies について詳しくは previous question を見てください)。もしクッキーが働かなければ、スクリプトが適切に働いていないか、ブラウザがクッキーを使っていない、もしくはそれを受け入れるセットアップではないのでしょう。


  18. Apache サーバから URL をリクエストすると、なぜ Java app[let]s はプレインテキストを与えるのですか?

    バージョン 1.2 では、Apache は HTTP/1.1 (HyperText Transfer Protocol version 1.1) サーバです。この事実は、リクエストを処理しているときにクライアントに送信される、レスポンスのヘッダに含まれるプロトコルのバージョンに反映されています。不幸にも、Java Development Kit (JDK) バージョン 1.0.2 に含まれている低レベルのウェブアクセスクラスは、バージョンストリングの "HTTP/1.0" を見ることを要求しており、Apache が送信している "HTTP/1.1" の値を正確には解釈しません(レスポンスのこの部分はレスポンスの dialect の通知というよりもむしろ、サーバができることの通知です)。その結果、JDK メソッドは正確にはヘッダを解析しないで、誤ってドキュメンツのコンテンツでそれを含むことになります。

    これは、Sun からの JDK 1.0.2 ファンデーションクラスでの決定的なバグで、バージョン 1.1 では修正されています。しかし、質問にあるクラスはバーチャルマシン環境の部分で、それはクライアントシステム上のウェブブラウザ(もし Java が可能なら)か、Java 環境の部分であることを意味しています。それでもし、最近の JDK でクラスを発展させるとしても、結局ユーザは問題にぶつかるのかもしれません。関係するクラスは、ベンダーが Java のバーチャルマシン環境を実施することによって入れ替えが可能で、1.0.2 を基にしたものでさえ、この問題を持っていないかもしれません。

    一方、次善策は JDK メソッドから来るリクエストに HTTP/1.0 レスポンスを "fake" することを Apache に言うことです; これは、サーバのコンフィギュレーションファイルに以下のような行を含むことによって行われます;

    BrowserMatch Java1.0 force-response-1.0
    BrowserMatch JDK/1.0 force-response-1.0

    この問題については、Apache ウェエブサイトの Java and HTTP/1.1で見ることができます。


  19. なぜ Netscape Gold と他のプログラムで PUT を使っていることを Apache サーバに発行できないのですか?

    なぜなら、アップロードされたファイルをハンドルするには、インストールしてスクリプトをコンフィギュアする必要があるからです。このスクリプトは、しばしば "PUT" ハンドラーと呼ばれます。役に立つものがいくつかありますが、セキュリティ問題を持っているかもしれません。少なくとも今では、FTP アップロードを使うとより簡単で安全かもしれません。詳しくは、Apache Week にある Publishing Pages with PUT の記事を見てください。


  20. もはや Apache では FastCGI は含まれないのですか?

    簡単に言うと、FastCGI web site でのマスターコピーと同調した Apache で含まれていたバージョンを維持するのが難しくなったからです。Apache の新しいリリースが行われたとき、含まれていた FastCGI のバージョンは、すぐに時代遅れになりました。

    まだ、マスターの FastCGI ウェブサイトから Apache の FastCGI モジュールを入手することができます。


  21. なぜエラーログで "httpd: could not set socket option TCP_NODELAY" が出てしまうのでしょうか?

    このメッセージはほとんどいつも、Apache が接続の setsockopt() を呼ぶポイントに届く前に、クライアントが接続を切断したことを示します。サーバがハンドルしているリクエストの 1% 以上で起こるべきではなく、ともかく報告だけです。


  22. なぜエラーログで "connection reset by peer" が出てしまうのでしょうか?

    これは通常のメッセージであり、警告されるようなことはなにもありません。単に、完全にセットアップされる前にクライアントが接続をキャンセルした、エンドユーザが "Stop" ボタンを押したようなことを意味します。レスポンスの時間や遅いネットワークリンクのサイトでは、大きな容量を持つものや、ネットワークに太いパイプがあるものよりも、これをよく経験するかもしれません。


  23. Apache がバッファすることなしにスクリプトの出力を得るには、どうすればいいでしょうか?なぜサーバプッシュは働かないのですか?

    ネットワークのパフォーマンスを改善するために、Apache は比較的大きな塊のスクリプト出力をバッファします。バーストに情報を送信するスクリプトを持っていれば(例えば、マルチコミットなデータベーストランザクションや、なんらかのサーバプッシュタイプにある部分的なメッセージ)、クライアントはスクリプトがそれを生じるような出力を必ずしも得ません。

    これを避けるために、Apache は non-parsed-header スクリプトとして "nph-" で名前が始まるスクリプトを認識します。これは、Apache がその出力をバッファしないで、ソケットがクライアントに戻るように直接接続します。

    これはおそらく、やりたいことができる一方、いくつか不便なところがあります:

    前者をどのようにハンドルするかというと( Perl スクリプト):

    if ($0 =~ m:^(.*/)*nph-[^/]*$:) {
         $HTTP_headers =  "HTTP/1.1 200 OK\015\012";
         $HTTP_headers .=  "Connection: close\015\012";
         print $HTTP_headers;
    }

    それから通常の non-nph ヘッダに続きます

    バージョン 1.3 で全ての CGI スクリプトは、そのような、送信されたフルの HTTP ヘッダを nph スクリプトが要求する nph スクリプトと通常のスクリプトとの違いだけをバファーしないことに注意してください。


  24. なぜ Linux でコンパイルすると "struct iovec" の再定義について問題が出るのですか?

    これは、C ライブラリが含んでいるものと、カーネルが含んでいるものとの間の矛盾です。両方のバージョンが適切に一致していることを確認してください。二つの次善策があって、どちらか一方が問題を解決するでしょう:


  25. エラーログは、Apache がコアを dump されたと言っていますが、dump ファイルはどこですか?

    Apache 1.2 では、コアを dump されたことについてのエラーログメッセージが dump ファイルが置かれるべきディレクトリを含んでいます。しかしながら、多くの Unix はセキュリティの理由から、コアを dump するために setuid() を呼ぶ処理を許可しません; 典型的な Apache のセットアップは、サーバリクエストで非特権ユーザに対して UIDs を変更した後、port 80 にバインドするルートとしてサーバを起動させます。

    これに関する扱いは極端に OS 特有のもので、システムカーネルの再構築を要求するかもしれません。システムがこれを行うかどうか、それをどのようにバイパスするかについては、OS のドキュメントか、ベンダーに助言を求めてください。もしそれをバイパスする明示された方法があれば、可能ならば httpd サーバ処理についてのみそれをバイパスすることをお勧めします。

    Apache コア dump ファイルの正統な場所は、ServerRoot ディレクトリです。Apache 1.3 では、ロケーションが、異なったディレクトリに対して CoreDumpDirectory 命令によって設定されます。このディレクトリがサーバが走っている(ユーザに向かうサーバのように)ユーザによって書き込み可能であることを確認してください。


  26. なぜホストやドメイン名が正しく働くことで、アクセスは制限しないのですか?

    この主な原因は2つです:

    1. DNS 登録のエラーや、矛盾、予想外のマッピング
      これは頻繁に起こります: コンフィギュレーションは Host.FooBar.Com へのアクセスを制限しますが、ホストからでは違います。この一般的な理由は、Host.FooBar.Com が実際は、他の名前のアライアスであることで、Apache が address-to-name のルックアップを行う時、それは Host.FooBar.Com ではない 本当の名前になります。自身で逆ルックアップをチェックすることにより、これを証明することができます。次善策として最も簡単な方法は、コンフィギュレーションで正確なホスト名を指定することです。
    2. Apache での不適当なチェックと、コンフィギュレーションでの証明
      もしアクセスチェックと、クライアントのホストやドメイン名を基にした制限をしようとすれば、実際に、与えられたオリジナルの情報を二重チェックするために Apache をコンフィギュアする必要があります。Configuration ファイルの EXTRA_CFLAGS 定義に -DMAXIMUM_DNS を追加することによりこれを行います。例えば:

      EXTRA_CFLAGS=-DMAXIMUM_DNS

      これは、特定のホストアドレスが、要求している名前に本当に割り当てられていることの確認について、Apache を非常に偏執的にさせるでしょう。ネームサーバに送信される全ての名前変更リクエストのせいで、重大なパフォーマンスペナルティを招くかもしれないことに注意してください。


  27. なぜ Apache は SSL を含まないのですか?

    SSL (Secure Socket Layer) データ転送は encryption をリクエストし、多くの政府機関はインポート、エクスポート、encryption の技術の使用に制限を持っています。もし Apache が基となるパッケージに SSL を含んでいれば、その配布は法的な全ての分類とお役所的な問題を巻き込み、もはやフリーで入手するものになってしまいます。また、SSL を使っている現在のクライアントにトークするために要求された技術のいくつかは、ライセンスなしでの使用を制限する RSA Data Security によって特許が取られています。

    Apache のいくつかの SSL の実行はできますが、メインの Apache ウェブサイトの "related projects" ページを見てください。

    Apache and Secure Transactions についての Apache Week 記事にある、このトピックについての詳細がわかります。


  28. なぜ HP's ANSI C コンパイラを使った HPUX でコアの dump が起きてしまうのですか?

    HP's ANSI C コンパイラが最適化してコンパイルされると、Apache がコアを dump するたくさんのレポートが出ます。コンパイラの最適化を不能にすると、これらの問題は修正されます。


  29. どうしたらブラウザが演奏できるように、Apache に MIDI ファイルを 送信させますか?

    MIDI ファイルで登録された MIME タイプでさえも、audio/midi であり、いくつかのブラウザは、それをそのように認識するセットアップではありません; 代わりに、audio/x-midi を捜します。これに対する処置は二つあります:

    1. 正確に audio/midi タイプのドキュメントを扱うために、ブラウザをコンフィギュアしてください。これは、デフォルトで Apache が送信するタイプです。変更のためにクライアントのインストールが多かったり、クライアントが制御下になかったりすると、動かないかもしれません。
    2. サーバのコンフィギュレーションファイルに以下の行を追加することにより、これらのファイルに対する異なった Content-type の送信を Apache に指示してください:

      AddType audio/x-midi .mid .midi .kar

      もし audio/x-midi を同じ方法で準備する用意ができているのでなければ、audio/midi MIME タイプを認識するブラウザを壊すかもしれないことに注意してください。


  30. なぜ Apache はシステムの cc でコンパイルしないのですか?

    もしサーバがシステムをコンパイルしないなら、おそらく原因は以下のうちの一つです:

    Apache グループは、多くの異なったプラットフォームでサーバを構築する能力をテストしています。不幸にも、存在する OS のプラットフォームの全てをテストすることはできていません。もし上記の結果が、あなたの問題のせいでないことを証明できて、それが以前に報告されていないのなら、problem report に報告してください。コンパイラや& OS バージョン、正確なエラーメッセージといった詳細を完全にふくんでいることを確認してください。


  31. ログにブラウザとリファーラを追加するにはどうしたらいいでしょうか?

    Apache にはこれを行うための異なった方法が二つあります。推奨されるメソッドはコンフィギュレーションに mod_log_config モジュールをコンパイルして、CustomLog 命令を使うことです。

    通常の転送ログとは異なるファイルにある追加情報をログするか、既に書かれた記録にそれを追加することができます。例えば:

    CustomLog logs/access_log "%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-Agent}i\""

    これは、アクセスログにあるそれぞれの行の終わりに対して、それぞれにクライアントとリファリングページを指し示す User-agent:Referer: ヘッダの値を追加します。

    タイトルを付けられた Apache Week の記事を調べるのもよいでしょう:"Gathering Visitor Information: Customising Your Logfiles"


  32. なぜ "__inet_ntoa" や他の __inet_* シンボルへの未定義リファレンスに関するエラーが出てしまうのですか?

    もし BIND-8 をインストールしていれば、普通は include ファイルとライブラリとの矛盾のせいです。BIND-8 はその include ファイルとライブラリファイル、/usr/local/include//usr/local/lib/ をインストールします。その一方、システムと一緒になるリソルバーが /usr/include//usr/lib/ にインストールされます。もしシステムが /usr/include/ にあるものより前に、/usr/local/include/ にあるヘッダファイルを使っていて、新しいリソルバーライブラリを使っていなければ、二つのバージョンは矛盾するでしょう。

    これを解決するためには、システムになっている include ファイルとライブラリを使っていることを確認するか、新しい include ファイルとライブラリを使っていることを確認するかのどちらかです。Configuration ファイルの EXTRA_LDFLAGS 行に -lbind を追加して、Configure を再び走らせ、問題を解決すべきでしょう(Apache バージョン 1.2.* と初期の EXTRA_LFLAGS 代用の使用)。

    Note:BIND 8.1.1 では、バインドライブラリとファイルは、デフォルトで /usr/local/bind 下にインストールされ、この問題にぶつかるべきではありません。それぞれの行に以下を追加するバインドリソルバーを使うべきでしょう:

    EXTRA_CFLAGS=-I/usr/local/bind/include
    EXTRA_LDFLAGS=-L/usr/local/bind/lib
    EXTRA_LIBS=-lbind


  33. なぜ"/"のトレイリングを含んでいるときに、アクセスディレクトリだけが働いて、(http://foo.domain.com/~user/)、それを省略したときには働かない(http://foo.domain.com/~user)のですか?

    "/"のトレイリングをしないでディレクトリにアクセスすると、Apache はトレイリングスラッシュを追加することを言うために、クライアントにリダイレクトを呼ばれることを送信する必要があります。もしそうならなければ、相対的な URL は適切には動きません。リダイレクトを送信すると、リダイレクトに含むことができるように、サーバの名前を知る必要があります。Apache でこれを発見する方法は二つあります; 推測するか、教えるかのどちらかです。もし DNS が正しくコンフィギュアされていれば、なんの問題もなしに普通に推測することができます。もしそうでないなら、その時は、教える必要があります。

    サーバのドメイン名が何であるかを教えるためにコンフィグファイルに ServerName 命令を追加してください。


  34. 確実にドキュメントにアクセスするためには、ユーザ名とパスワードを要求する Apache をどのようにセットアップすればいいでしょうか?

    これを行うためには、いくつかの方法があります; 一般的なものとしては、mod_authmod_auth_dbmod_auth_dbm といったモジュールを使うことです。

    これらの制限をどのように実行するかの説明については、Apache WeekUsing User AuthenticationDBM User Authentication の記事を見てください。


  35. なぜ環境変数 REMOTE_USER が設定されていないのですか?

    この変数が SSI や CGI スクリプトで設定、利用されていて、かつ、その時に限り、要求されたドキュメントはアクセス認証によって保護されます。これらの制限をどのように実行するかの説明は、Apache Week にある Using User AuthenticationDBM User Authentication の記事を見てください。

    ヒント: HTML FORM のデータを受け取るために CGI スクリプトを使うとき、FORM を含むドキュメントの保護は、CGI スクリプトに REMOTE_USER を与えるには不十分です。CGI スクリプトも保護しなければなりません。あるいは代わりになるのは CGI スクリプトだけです(それから、認証はフォームを満たした後にだけ起こります)。


  36. もしサイトがローカルサイトであったり、ユーザがパスワードとユーザ名を与えていれば、特定のドキュメントにだけアクセスを許可する Apache をどのようにセットアップしますか?

    唯一のアクセス制限を満たすことを要求するために、特定の Satisfy Any 命令で Satisfy 命令を使ってください。例えば、.htaccess かサーバコンフィギュレーションファイルに対して以下のコンフィギュレーションを追加することは、domain.com でホストからサイトにアクセスするか、正当なユーザ名とパスワードを満たせる人に対して、アクセスを制限します:

    deny from all
    allow from .domain.com
    AuthType Basic
    AuthUserFile /usr/local/apache/conf/htpasswd.users
    AuthName special directory
    require valid-user
    satisfy any

    上記の命令がどのように働くかについての詳細は、user authentication の質問と mod_access モジュールを見てください。


  37. なぜ mod_info はなんの命令もリストしないのですか?

    mod_info モジュールはサーバがどのようにコンフィギュアされているのかを見るために、ウェブブラウザを使うことを許可します。表示している情報に混じってリストモジュールとコンフィギュレーション命令があります。命令の "current" 値は、サーバを走らせるのに必ずしも必要ではありません; それらはリクエストのときにコンフィギュレーションファイルから引き出されます。もしサーバが最後にリロードされてからファイルが変更されると、表示は使われている値とは一致しません。もしサーバが走っていながら、ファイルと、ファイルへのパスがユーザによって読めなければ (User 命令を見てください)、mod_info はその値をリストするために、読むことができません。しかしながら、エントリーはこれでエラーログに作られるでしょう。


  38. Linux で走っているときに、"shmget: function not found"が出たら、どうすべきですか?

    カーネルは SysV IPC サポートなしで作られます。サポートができるカーネルを再構築すべきでしょう("General Setup" サブメニューで)。カーネル構築のためのドキュメントは、この FAQ の外にあります; Kernel HOWTO か配布で与えられたドキュメント、Linux newsgroup/mailing list で助言を求めるべきでしょう。最後の手段としての策として、src/conf.hLINUX セクションにある #define HAVE_SHMGET 定義とサーバの再構築があります。これは遅くて、信頼性のあまりないサーバを作ることになるでしょう。


  39. なぜ認証はサーバエラーを与えるのですか?

    通常の環境で Apache のアクセスコントロールモジュールは、次のアクセスのコントロールモジュールを制御して、認識されていないユーザ ID をパスするでしょう。もしユーザ ID が認識されて、パスワードが有効にされる(あるいは、されない)だけなら、普通にうまくいくか、"authentication failed" のメッセージが出ます。

    しかし、'declines' 行にある最後のアクセスモジュールのの有効化がリクエストすると(なぜならユーザID を聞かないか、コンフィギュアされないからです)、http_request ハンドラーは、以下のように混乱した一つのエラーを出します;

    これはいくつかの雑誌が示しているように、'AuthUserFile /dev/null' 行を追加しなければならないということではありません!

    解決法は、少なくとも最後のモジュールに認証があって、CONFIGURED であることを確実にします。もし適当な AuthUserFile でコンフィギュアされるだけなら、デフォルトでは、mod_auth は認証があって、OK/Denied を与えます。正当なグループが要求される場合も同様です(モジュールは、コンパイル時の Configuration ファイルに現われるものの順序とは逆に処理されることを忘れないでください)。

    このエラーの典型的な状況というのは、モジュール自身で mod_auth_dbmmod_auth_msqlmod_auth_mysqlmod_auth_anonmod_auth_cookie モジュールを使っているときです。これらはデフォルトでは、認証がありません。そして、ユーザ ID がそれぞれのデータベースにないとき、次の(存在しない)認証モジュールに責任転嫁します。ただ、コンフィギュレーションに適切な 'XXXAuthoritative yes' 行を追加してください。

    一般的には、最後の手段としてファイルデータベースに mod_auth を持つのはよい手です(あまり効果的ではありませんが)。たとえデータベースがダウンしたり、壊れたりしても、これは2、3の特別なパスワードでウェブサーバにアクセスすることを許可します。保護されたエリアで、それぞれのリクエストのためにファイルの open/seek/close はコストがかかります。


  40. 同じマシンで (mSQL) 認証情報を維持すべきでしょうか?

    ウェブサーバとは違うマシンで認証情報を維持することについては、いくつかの団体は非常に強く確信しています。(R)DBMses に対する mod_auth_msqlmod_auth_mysql、他の SQL モジュールの接続で、これは完全に可能です。ただコンタクトするための明白なホストをコンフィギュアするだけです。

    mSQL と Oracle に気を付けてください。これらのデータベースの接続を開いたり、閉じたりするのは、とても高価で、時間を消費します。もし RDBMS のライセンスがそれを許可するなら、auth_* モジュールにあるコードを見て、これをいくらか軽減するためにコンパイル時間のフラッグをいじりたくなるかもしれません。


  41. なぜ mSQL 認証は非常に遅いのですか?

    おそらく FQHN を特定化することによってホストをコンフィギュアしていて、速い内部デバイスよりもむしろ、このような libmsql はデータベースと話すため、完全に打撃を受けた tcp/ip ソケットを使うでしょう。libmsql と mSQL FAQ、mod_auth_msql ドキュメントは、これについて警告します。もし異なったホストを使わなければならないなら、適しているか、あるいは適していないコンパイル時のフラッグのために、mod_auth_msql を調べてください。


  42. 特定の URL に関した問題を既に解決している mod_rewrite ルールセットをどこで捜せますか?

    現在知られている mod_rewrite の典型的な解法の全てを捜すことができるのは Practical Solutions for URL-Manipulation です。もし、このドキュメントで現在カバーされていない特定の問題を解決する、より興味深いルールセットを持っているなら、まとめて Ralf S. Engelschall に送ってください。他のウェブマスター達は方向転換の再考を避けることを感謝するでしょう。


  43. URL 操作と mod_rewrite についての情報はどこで見つかりますか?

    "iX Multiuser Multitasking Magazin" issue #12/96 に、mod_rewrite を基にした URL 操作についての Ralf S. Engelschall の記事があります。ドイツ語版(オリジナル)は http://www.heise.de/ix/artikel/9612149/ で読むことができ、英語版(翻訳)は http://www.heise.de/ix/artikel/E/9612149/ にあります。


  44. なぜ mod_rewrite は学ぶのが難しくて、複雑に見えるのでしょうか?

    理由はたくさんあります。まず、mod_rewrite 自身が URL を書き換える本当に全ての局面で助けになる、強いモジュールなので、定義ごとのつまらないモジュールではないのです。それを成し遂げるためには、ソフトウェアの leverage を使い、Apache 1.2 から必須の部分である Henry Spencer による強力な regular expression ライブラリを利用します。そして regular expression 自体は newbies になるのは難しい一方、新たなハッカーに対しては最も柔軟な力を発揮します。

    一方、mod_rewrite は Apache API 環境内部で働かなければならず、そこで適合するためには、多少の技術が必要となります。例えば、1.x の Apache API は .htaccess の段階の処理では、URL の書き換えについてはデザインされませんでした。あるいは、連続して多発する rewrite の問題で、API ごとのデザインによってはハンドルされません。mod_rewrite にこの特徴を提供することは、Apache カーネル内部での処理を難しくするような、いくつかの特別な(API 対応!)ハンドリングをしなければなりません。ユーザは普通この処理をなにも見ませんが、RewriteRules のいくつかが働いているように見えないとき、問題を発見するのは難しくなります。


  45. RewriteRules が期待したように働かないとき、どうすればいいですか?

    "RewriteLog somefile" と "RewriteLogLevel 9" を使って、rewrite エンジンの動きの段階を正確に見てください。これは、rewriting のコンフィギュレーションをデバッグする唯一最良の方法です。


  46. mod_rewrite を使うと、なぜ URL のいくつかが DocumentRoot で先頭に来ないのですか?

    ファイルシステムに /somedir が本当に存在しないことを /somedir/... が確認して rule がスタートするか、このディレクトリに一致する URL を導きたくないなら、すなわち、ファイルシステム上に somedir という名のルートディレクトリは、ないに違いありません。なぜなら、もしそのようなディレクトリがあれば、URL はドキュメントルートで先頭に来ないからです。この動作は不快ですが、いくつかの他の URL rewrite にとって本当に重要なことです。


  47. どのようにすれば mod_rewrite で全ての URLs case-insensitive を作ることができますか?

    それはできません。第一の理由としては、任意の長さの URL の case translation が regex パターンと、一致する置換を経ては行われません。sed/Perl tr|..|..| の特徴のような文字ごとのパターンが必要になります。二番目に、ちょうど作っている URL がいつも upper か lower な場合に case-INSENSITIVE URL の問題を完全には解決しないのは、実際の URL が、後で Apache がファイルにアクセスするのを必要とする処理のせいで、ファイルシステムにある正確な case-variant を書き換えなければならなかったからです。 そして Unix のファイルシステムは、いつも case-SENSITIVE です。

    しかし、ネット上のそこで mod_speling.c(このように名付けられます) と名付けられたモジュールがあります。試してください。


  48. なぜバーチャルホスト部分にある RewriteRule は無視されるのですか?

    セキュリティに関係しているせいで、あらゆるバーチャルホストのためのエンジンをはっきりと可能にしなければならないからです。ただ、バーチャルホストのコンフィギュレーション部分に "RewriteEngine on" を追加するだけです。


  49. どのようにして RewriteRule の ENV フラッグで空行のストリングを使いますか?

    唯一の不快な方法しかありません: 引用符 ("[E=...]") で完全にフラッグの項を囲まなければなりません。注: ここで引用する項は E-flag に対する項ではなくて、Apache コンフィグファイルパーサーの項、すなわちここでは、RewriteRule の三番目の項です。それで、"[E=any text with whitespaces]" を書かなければなりません。


  50. どこで "CGI specification" を見つけることができますか?

    Common Gateway Interface (CGI) の使用は、現在少なくとも二つのバージョンで生きています:

    1. オリジナル NCSA サイト <http://hoohoo.ncsa.uiuc.edu/cgi/interface.html>で。このバージョンは 1995 年から更新されておらず、更新して置き換える努力をしています。
    2. Internet RFC にするために努力している目下のバージョンは、<http://www.ast.cam.ac.uk/~drtr/cgi-spec.html>で見られます。


  51. Apache は 2000年対応ですか?

    はい、Apache は2000年対応です。

    Apache は内部的に二つの数字で年数をストアすることはありません。HTTP プロトコルのレベルで RFC1123-style のアドレスは、HTTP/1.1 対応サーバが生じるべきフォーマットで作られます。古いアプリケーションとの互換性を持つために、Apache は ANSI C's asctime() と RFC850-/RFC1036-style date のフォーマットも認識しています。asctime() フォーマットは四つの数字の年数を使いますが、RFC850 と RFC1036 date のフォーマットは二つの数字の年数だけを定義しています。もし Apache が70よりも少ない値として date を見ると、世紀は19よりもむしろ20であると仮定します。

    いくつかのApache の出力では、オプションが可能になった FancyIndexingmod_autoindex によるディレクトリコンテンツの自動リストのように、二つの数字の年を使うかもしれませんが、そのような特定のシンタックスに依存するのは不都合です。問題は開発者によって手段が講じられます; 将来の Apache は好きな表示フォーマットを許可するでしょう。

    Apache は2000年対応ですが、もし基礎となっている OS が2000年から後に問題を持っていると、やっかいになるかもしれません(例えば、OS は受け入れたり返したりする年の数字を呼びます)。ほとんどの(UNIX)システムは、内部的に1970年1月1日からの秒数を含んでいる、サインされた32ビットの integer として日付をストアするので、心配するようなマジックの境界は2038年であって、2000年ではありません。しかし、最近の OS はトラブルを起こすことは全くありません。


  52. Apache 1.3 にアップグレードしたら、バーチャルホストが全く動かない!

    1.3b2 より前の Apache のバージョンでは、アドレスを基にしたバーチャルホストと名前を基にしたバーチャルホスト(HTTP/1.1)とで、非常に混乱がありました。サーバが <VirtualHost> 定義をどのように処理したかに関する rule はとても複雑で、あまりよく記述されていません。

    Apache 1.3b2 は rule をかなり単純化する新しい命令である NameVirtualHost を導入しています。しかしながら、このような rule の変更は、存在する名前を基にした <VirtualHost> は、以下のアップグレードで直ちに正確に動かなくなることを意味します。

    この問題を訂正するため、なんらかのバーチャルホストを定義する前に、サーバのコンフィギュレーションファイルの始めに以下の行を追加してください:

    NameVirtualHost n.n.n.n

    名前を基にしたバーチャルホストの名前に対する IPアドレスで "n.n.n.n"を置き換えてください; もし複数のアドレスに複数の名前を基にしたホストを持っているなら、それぞれのアドレスに命令を繰り返してください。

    名前を基にした <VirtualHost> ブロックは ServerName と、可能な限り ServerAlias 命令を含み、Apache が正確に区別していることを確認してください。

    コンフィギュレーションについての更なる詳細は Apache Virtual Host documentation を見てください。


  53. I'm using RedHat Linux and I have problems with httpd dying randomly or not restarting properly

    RedHat Linux versions 4.x (and possibly earlier) RPMs contain various nasty scripts which do not stop or restart Apache properly. These can affect you even if you're not running the RedHat supplied RPMs.

    If you're using the default install then you're probably running Apache 1.1.3, which is outdated. From RedHat's ftp site you can pick up a more recent RPM for Apache 1.2.x. This will solve one of the problems.

    If you're using a custom built Apache rather than the RedHat RPMs then you should rpm -e apache. In particular you want the mildly broken /etc/logrotate.d/apache script to be removed, and you want the broken /etc/rc.d/init.d/httpd (or httpd.init) script to be removed. The latter is actually fixed by the apache-1.2.5 RPMs but if you're building your own Apache then you probably don't want the RedHat files.

    We can't stress enough how important it is for folks, especially vendors to follow the stopping Apache directions given in our documentation. In RedHat's defense, the broken scripts were necessary with Apache 1.1.x because the Linux support in 1.1.x was very poor, and there were various race conditions on all platforms. None of this should be necessary with Apache 1.2 and later.


  54. I upgraded from an Apache version earlier than 1.2.0 and suddenly I have problems with Apache dying randomly or not restarting properly

    You should read the previous note about problems with RedHat installations. It is entirely likely that your installation has start/stop/restart scripts which were built for an earlier version of Apache. Versions earlier than 1.2.0 had various race conditions that made it necessary to use kill -9 at times to take out all the httpd servers. But that should not be necessary any longer. You should follow the directions on how to stop and restart Apache.

    As of Apache 1.3 there is a script src/support/apachectl which, after a bit of customization, is suitable for starting, stopping, and restarting your server.


  55. I'm using RedHat Linux and my .htm files are showing up as HTML source rather than being formatted!

    RedHat messed up and forgot to put a content type for .htm files into /etc/mime.types. Edit /etc/mime.types, find the line containing html and add htm to it. Then restart your httpd server:

    kill -HUP `cat /var/run/httpd.pid`

    Then clear your browsers' caches. (Many browsers won't re-examine the content type after they've reloaded a page.)


  56. I'm using RedHat Linux 5.0, or some other glibc-based Linux system, and I get errors with the crypt function when I attempt to build Apache 1.2.

    glibc puts the crypt function into a separate library. Edit your src/Configuration file and set this:

    EXTRA_LIBS=-lcrypt

    Then re-run src/Configure and re-execute the make.


  57. Server hangs, or fails to start, and/or error log fills with "fcntl: F_SETLKW: No record locks available" or similar messages

    These are symptoms of a fine locking problem, which usually means that the server is trying to use a synchronization file on an NFS filesystem.

    Because of its parallel-operation model, the Apache Web server needs to provide some form of synchronization when accessing certain resources. One of these synchronization methods involves taking out locks on a file, which means that the filesystem whereon the lockfile resides must support locking. In many cases this means it can't be kept on an NFS-mounted filesystem.

    To cause the Web server to work around the NFS locking limitations, include a line such as the following in your server configuration files:

    LockFile /var/run/apache-lock

    The directory should not be generally writable (e.g., don't use /var/tmp). See the LockFile documentation for more information.


  58. What's the best hardware/operating system/... How do I get the most out of my Apache Web server?

    Check out Dean Gaudet's performance tuning page.


  59. What are "regular expressions"?

    Regular expressions are a way of describing a pattern - for example, "all the words that begin with the letter A" or "every 10-digit phone number" or even "Every sentence with two commas in it, and no capital letter Q". Regular expressions (aka "regexp"s) are useful in Apache because they let you apply certain attributes against collections of files or resources in very flexible ways - for example, all .gif and .jpg files under any "images" directory could be written as /.*\/images\/.*[jpg|gif]/.

    The best overview around is probably the one which comes with Perl. We implement a simple subset of Perl's regexp support, but it's still a good way to learn what they mean. You can start by going to the CPAN page on regular expressions, and branching out from there.


  60. I'm using gcc and I get some compilation errors, what is wrong?

    GCC parses your system header files and produces a modified subset which it uses for compiling. This behaviour ties GCC tightly to the version of your operating system. So, for example, if you were running IRIX 5.3 when you built GCC and then upgrade to IRIX 6.2 later, you will have to rebuild GCC. Similarly for Solaris 2.4, 2.5, or 2.5.1 when you upgrade to 2.6. Sometimes you can type "gcc -v" and it will tell you the version of the operating system it was built against.

    If you fail to do this, then it is very likely that Apache will fail to build. One of the most common errors is with readv, writev, or uio.h. This is not a bug with Apache. You will need to re-install GCC.


  61. My .htaccess files are being ignored.

    This is almost always due to your AllowOverride directive being set incorrectly for the directory in question. If it is set to None then .htaccess files will not even be looked for. If you do have one that is set, then be certain it covers the directory you are trying to use the .htaccess file in. This is normally accomplished by ensuring it is inside the proper Directory container.


  62. How do I submit a patch to the Apache Group?

    The Apache Group encourages patches from outside developers. There are 2 main "types" of patches: small bugfixes and general improvements. Bugfixes should be sent to the Apache bug report page. Improvements, modifications and additions should follow these instructions.

    In general, the first course of action is to be a member of the new-httpd@apache.org mailing list. This indicates to the Group that you are closely following the latest Apache developments. Your patch file should be generated using either 'diff -c' or 'diff -u' against the latest CVS tree. To submit your patch, send Email to new-httpd@apache.org with a Subject: line that starts with [PATCH] and includes a general description of the patch. In the body of the message, the patch should be clearly described and then included at the end of the message. If the patch-file is long, you can note a URL to the file instead of the file itself. Use of MIME enclosures/attachments should be avoided.

    Be prepared to respond to any questions about your patches and possibly defend your code. If your patch results in a lot of discussion, you may be asked to submit an updated patch that incorporate all changes and suggestions.


Apache HTTP Server Version 1.3

検索文字
Index Home The English original manual is here.
このページの情報に関わる、ご質問、お問い合わせは、 japache@infoscience.co.jpまで。

JAPACHE ホームページ