<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
-<!-- English Revision: 189754:664013 (outdated) -->
+<!-- English Revision: 344971:664013 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
</section> <!-- /access -->
- <section id="ftp-proxy"><title>FTP プロキシ</title>
-
-
- <section id="mimetypes"><title>どうしてファイルタイプが <var>xxx</var>
- のファイルを FTP でダウンロードできないの?</title>
- <p>おそらく、プロキシの mime.types 設定ファイルでそのファイルタイプが
- <code>application/octet-stream</code> であると定義されていないのでしょう。
- 以下のようなものが役に立つかもしれません:</p>
-
- <example>
-<pre>application/octet-stream bin dms lha lzh exe class tgz taz</pre>
- </example>
- <p>別の方法として、すべてのデフォルトをバイナリにすることもできます:</p>
- <example>
-<pre>DefaultType application/octet-stream</pre>
- </example>
- </section> <!-- /mimetypes -->
-
- <section id="type"><title>ファイル <var>xxx</var> を FTP の ASCII ダウンロード
- にさせるのはどうすればよいの?</title>
- <p>まれに、(デフォルトの転送は <code>binary</code> モードで) 特定の
- ファイルのみ FTP の <code>ASCII</code> 転送方法を使わなければならない
- 場合には、リクエストの最後に <code>;type=a</code> を付けることで
- <module>mod_proxy</module> に ASCII 転送をさせることができます。
- (ただし、FTP のディレクトリ一覧は常に ASCII モードで行なわれます。)</p>
- </section> <!-- /type -->
-
- <section id="ftpnonget"><title>FTP のアップロードはどうすればよいの?</title>
- <p>現時点では、mod_proxy の FTP サポートは GET のみです。もちろん
- Apache の プロキシを使って HTTP のアップロード (POST や PUT) を
- することはできます。</p>
- </section>
-
- <section id="percent2fhck"><title>ホームディレクトリの外の FTP ファイルに
- アクセスするにはどうすればよいの?</title>
- <p>FTP URI はログインしているユーザのホームディレクトリからの
- 相対パスとして扱われます。残念なことに、/../ はブラウザにより解釈され、
- 実際に FTP サーバには送られないため、/../ を使って上位のディレクトリに
- 到達することはできません。この問題を解決するために、いわゆる
- <dfn>Squid %2f ハック</dfn> を Apache の FTP プロキシは実装しています。
- これは <a
- href="http://www.squid-cache.org/">Squid Proxy キャッシュ</a> のような
- 他のよく使われているプロキシサーバでも取られている方法です。
- リクエストのパスの先頭に <code>/%2f</code> を付けることで、プロキシに
- FTP の開始ディレクトリを (ホームディレクトリの代わりに) <code>/</code>
- に変えることができます。例えば、<code>/etc/motd</code> を取得するためには
- 次の URL を使います:</p>
-
- <example>
- ftp://<var>user</var>@<var>host</var>/%2f/etc/motd
- </example>
- </section> <!-- /percent2fhck -->
-
- <section id="ftppass"><title>ブラウザの URL 表示で FTP の平文パスワードを
- 隠すにはどうすればよいの?</title>
- <p>FTP サーバにユーザ名とパスワードを使ってログインするために、
- Apache は異なる方法を使います。URL にユーザ名とパスワードがまったく
- ない場合は、Apache は FTP サーバに anonymous ログインを送ります。
- <em>つまり</em>、</p>
-
- <example>
- user: anonymous<br />
- password: apache_proxy@
- </example>
-
- <p>これは anonymous アクセスが設定された
- すべての FTP サーバに対して動作します。</p>
-
- <p>ユーザ名を使った個人別のログインには、URL にユーザ名を入れることが
- できます:</p>
-
- <example>
- ftp://<var>username</var>@<var>host</var>/myfile
- </example>
-
- <p>このユーザ名が与えられたときに、FTP サーバがパスワードを要求すれば
- (もちろんそうすべきなのですが)、Apache は <code>401</code>
- (Authorization required) を返します。これにより、ブラウザはユーザ名
- パスワードの入力ダイアログを表示します。パスワードが入力された後、
- 再び接続を試み、成功すればリクエストしたリソースが表示されます。
- この方法の利点はブラウザがパスワードを平文で表示しないことです。
- (もし最初から</p>
-
- <example>
- ftp://<var>username</var>:<var>password</var>@<var>host</var>/myfile
- </example>
-
- <p>と入力した場合には表示されてしまいます。)</p>
-
- <note><title>注</title>
- <p>送信されるパスワードは、暗号化されて送られるわけではありません。
- ブラウザと Apache プロキシサーバは base64 で符号化された
- 文字列として、Apache プロキシと FTP サーバの間は平文として送られます。
- ですから、HTTP を使って HTTP をアクセスする前 (もしくは、そもそも
- 個人的なファイルを FTP でアクセスする前) によく考える必要があります。
- 安全でない通信路を使った場合は、盗聴者に途中でパスワードを盗まれる
- 可能性があります。</p>
- </note>
- </section> <!-- /ftppass -->
- </section> <!-- /ftpproxy -->
<section id="startup"><title>遅い起動</title>
<p><directive module="mod_proxy"
>ProxyBlock</directive> ディレクティブを使っている場合、
</section> <!-- /intranet -->
<section id="envsettings"><title>プロトコルの調整</title>
- <p>Keepalive や HTTP/1.1 を適切に実装していないアプリケーションサーバが
- ある状況で、HTTP/1.0 で keepalive を無しにしてリクエストを送るための
+ <p>Keepalive や HTTP/1.1 を適切に実装していないアプリケーションサーバに対して
+ <module>mod_proxy</module> がリクエストを送信する場合、
+ HTTP/1.0 を使って keepalive を無しにしてリクエストを送るようにする
環境変数が二つあります。これらは <directive module="mod_env"
>SetEnv</directive> ディレクティブで設定します。</p>
</indent>
</Location>
</example>
+
</section> <!-- /envsettings -->
+ <section id="request-bodies"><title>リクエストボディ</title>
+
+ <p>POST メソッドなどのリクエストには、リクエストボディがあります。
+ HTTP プロトコル仕様によると、ボディのあるリクエストは chunked
+ 転送を使うか、<code>Content-Length</code>
+ ヘッダを送信しなければなりません。
+ このようなリクエストをオリジンサーバに送信する場合、
+ <module>mod_proxy_http</module> は常に <code>Content-Length</code>
+ を送ろうと試みます。しかし。ボディが大きく、オリジナルのリクエストで
+ chunked 転送が使われている場合、上流へのリクエストに
+ chunked 転送も使われます。
+ この挙動は <a href="../env.html">環境変数</a>で制御できます。
+ <code>proxy-sendcl</code> を設定すると、可能な限り常に
+ <code>Content-Length</code> を付与して、
+ 上流サーバに送信するようになります。
+ 逆に <code>proxy-sendchunked</code> を設定すると、リソース消費を抑え、
+ chnked エンコードを使って送信するようになります。</p>
+
+ </section> <!-- /request-bodies -->
+
<directivesynopsis type="section">
<name>Proxy</name>
<description>プロキシされるリソースに適用されるコンテナ</description>
<usage>
<p><directive type="section">ProxyMatch</directive> は URL のマッチに
- 正規表現を用いることを除いて <directive type="section"
- >Proxy</directive> ディレクティブと同じです。</p>
+ <glossary ref="regex">正規表現</glossary> を用いることを除いて
+ <directive type="section">Proxy</directive> ディレクティブと同じです。</p>
</usage>
</directivesynopsis>
<usage>
<p><directive>ProxyRemoteMatch</directive> は最初の引数がリクエストされた
- URL にマッチする正規表現であることを除けば <directive
+ URL にマッチする<glossary ref="regex">正規表現</glossary>であることを除けば <directive
module="mod_proxy">ProxyRemote</directive> ディレクティブと同じです。</p>
</usage>
</directivesynopsis>
除外ディレクティブを置く必要があります。</p>
</note>
- <p>2.1 ã\81®æ\96°æ©\9fè\83½ã\81§ã\80\81ã\83\90ã\83\83ã\82¯ã\82¨ã\83³ã\83\89ã\82µã\83¼ã\83\90ã\81¨ã\81®æ\8e¥ç¶\9aã\81«ã\83\97ã\83¼ã\83«ã\81\95ã\82\8cã\81\9fã\82³ã\83\8dã\82¯ã\82·ã\83§ã\83³ã\82\92
+ <p>2.1 の機能で、バックエンドサーバとの接続にプールされたコネクションを
使えるようになりました。<code>key=value</code> 形式のパラメータで
このコネクションプーリングの調整ができます。<code>Hard Maximum</code>
のデフォルト値は、有効になっている MPM でのプロセス当たりのスレッド数と