+ <h3><a name="proxy" id="proxy">force-proxy-request-1.0, proxy-nokeepalive, proxy-sendchunked, proxy-sendcl</a></h3>
+
+ <p>These directives alter the protocol behavior of
+ <code class="module"><a href="./mod/mod_proxy.html">mod_proxy</a></code>. See the <code class="module"><a href="./mod/mod_proxy.html">mod_proxy</a></code>
+ documentation for more details.</p>
+
+
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<div class="section">
<h2><a name="examples" id="examples">Examples</a></h2>
<h3><a name="misbehaving" id="misbehaving">Changing protocol behavior with misbehaving clients</a></h3>
- <p>We recommend that the following lines be included in
- httpd.conf to deal with known client problems.</p>
+ <p>Earlier versions recommended that the following lines be included in
+ httpd.conf to deal with known client problems. Since the affected clients
+ are no longer seen in the wild, this configuration is likely no-longer
+ necessary.</p>
<div class="example"><pre>
#
# The following directives modify normal HTTP response behavior.
<?xml version="1.0" encoding="iso-2022-jp" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.ja.xsl"?>
-<!-- English Revision: 170354:240426 (outdated) -->
+<!-- English Revision: 170354:326130 (outdated) -->
<!--
Copyright 2002-2005 The Apache Software Foundation or its licensors, as
<?xml version="1.0" encoding="EUC-KR" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
-<!-- English Revision: 105989:240426 (outdated) -->
+<!-- English Revision: 105989:326130 (outdated) -->
<!--
Copyright 2003-2005 The Apache Software Foundation or its licensors,
<li><img alt="" src="../images/down.gif" /> <a href="#forwardreverse">Forward and Reverse Proxies</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#examples">Basic Examples</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#access">Controlling access to your proxy</a></li>
-<li><img alt="" src="../images/down.gif" /> <a href="#ftp-proxy">FTP Proxy</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#startup">Slow Startup</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#intranet">Intranet Proxy</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#envsettings">Protocol Adjustments</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#request-bodies">Request Bodys</a></li>
</ul><h3>See also</h3>
<ul class="seealso">
<li><code class="module"><a href="../mod/mod_cache.html">mod_cache</a></code></li>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
-<h2><a name="ftp-proxy" id="ftp-proxy">FTP Proxy</a></h2>
-
-
- <h3><a name="mimetypes" id="mimetypes">Why doesn't file type <var>xxx</var>
- download via FTP?</a></h3>
- <p>You probably don't have that particular file type defined as
- <code>application/octet-stream</code> in your proxy's mime.types
- configuration file. A useful line can be</p>
-
- <div class="example"><pre>application/octet-stream bin dms lha lzh exe class tgz taz</pre></div>
- <p>Alternatively you may prefer to default everything to binary:</p>
- <div class="example"><pre>DefaultType application/octet-stream</pre></div>
-
-
- <h3><a name="type" id="type">How can I force an FTP ASCII download of
- File <var>xxx</var>?</a></h3>
- <p>In the rare situation where you must download a specific file using the
- FTP <code>ASCII</code> transfer method (while the default transfer is in
- <code>binary</code> mode), you can override <code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code>'s
- default by suffixing the request with <code>;type=a</code> to force an
- ASCII transfer. (FTP Directory listings are always executed in ASCII mode,
- however.)</p>
-
-
- <h3><a name="ftpnonget" id="ftpnonget">How can I do FTP upload?</a></h3>
- <p>Currently, only GET is supported for FTP in mod_proxy. You can
- of course use HTTP upload (POST or PUT) through an Apache proxy.</p>
-
-
- <h3><a name="percent2fhck" id="percent2fhck">How can I access FTP files outside
- of my home directory?</a></h3>
- <p>An FTP URI is interpreted relative to the home directory of the user
- who is logging in. Alas, to reach higher directory levels you cannot
- use /../, as the dots are interpreted by the browser and not actually
- sent to the FTP server. To address this problem, the so called <dfn>Squid
- %2f hack</dfn> was implemented in the Apache FTP proxy; it is a
- solution which is also used by other popular proxy servers like the <a href="http://www.squid-cache.org/">Squid Proxy Cache</a>. By
- prepending <code>/%2f</code> to the path of your request, you can make
- such a proxy change the FTP starting directory to <code>/</code> (instead
- of the home directory). For example, to retrieve the file
- <code>/etc/motd</code>, you would use the URL:</p>
-
- <div class="example"><p><code>
- ftp://<var>user</var>@<var>host</var>/%2f/etc/motd
- </code></p></div>
-
-
- <h3><a name="ftppass" id="ftppass">How can I hide the FTP cleartext password
- in my browser's URL line?</a></h3>
- <p>To log in to an FTP server by username and password, Apache uses
- different strategies. In absense of a user name and password in the URL
- altogether, Apache sends an anonymous login to the FTP server,
- <em>i.e.</em>,</p>
-
- <div class="example"><p><code>
- user: anonymous<br />
- password: apache_proxy@
- </code></p></div>
-
- <p>This works for all popular FTP servers which are configured for
- anonymous access.</p>
-
- <p>For a personal login with a specific username, you can embed the user
- name into the URL, like in:</p>
-
- <div class="example"><p><code>
- ftp://<var>username</var>@<var>host</var>/myfile
- </code></p></div>
-
- <p>If the FTP server asks for a password when given this username (which
- it should), then Apache will reply with a <code>401</code> (Authorization
- required) response, which causes the Browser to pop up the
- username/password dialog. Upon entering the password, the connection
- attempt is retried, and if successful, the requested resource is
- presented. The advantage of this procedure is that your browser does not
- display the password in cleartext (which it would if you had used</p>
-
- <div class="example"><p><code>
- ftp://<var>username</var>:<var>password</var>@<var>host</var>/myfile
- </code></p></div>
-
- <p>in the first place).</p>
-
- <div class="note"><h3>Note</h3>
- <p>The password which is transmitted in such a way is not encrypted on
- its way. It travels between your browser and the Apache proxy server in
- a base64-encoded cleartext string, and between the Apache proxy and the
- FTP server as plaintext. You should therefore think twice before
- accessing your FTP server via HTTP (or before accessing your personal
- files via FTP at all!) When using unsecure channels, an eavesdropper
- might intercept your password on its way.</p>
- </div>
-
- </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="section">
<h2><a name="startup" id="startup">Slow Startup</a></h2>
<p>If you're using the <code class="directive"><a href="#proxyblock">ProxyBlock</a></code> directive, hostnames' IP addresses are looked up
and cached during startup for later match test. This may take a few
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="envsettings" id="envsettings">Protocol Adjustments</a></h2>
- <p>For circumstances where you have a application server which doesn't
- implement keepalives or HTTP/1.1 properly, there are 2 environment
- variables which when set send a HTTP/1.0 with no keepalive. These are set
- via the <code class="directive"><a href="../mod/mod_env.html#setenv">SetEnv</a></code> directive.</p>
+ <p>For circumstances where <code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code> is sending
+ requests to an origin server that doesn't properly implement
+ keepalives or HTTP/1.1, there are two <a href="../env.html">environment variables</a> that can force the
+ request to use HTTP/1.0 with no keepalive. These are set via the
+ <code class="directive"><a href="../mod/mod_env.html#setenv">SetEnv</a></code> directive.</p>
<p>These are the <code>force-proxy-request-1.0</code> and
<code>proxy-nokeepalive</code> notes.</p>
</span>
</Location>
</code></p></div>
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="request-bodies" id="request-bodies">Request Bodys</a></h2>
+
+ <p>Some request methods such as POST include a request body.
+ The HTTP protocol requires that requests which include a body
+ either use chunked transfer encoding or send a
+ <code>Content-Length</code> request header. When passing these
+ requests on to the origin server, <code class="module"><a href="../mod/mod_proxy_http.html">mod_proxy_http</a></code>
+ will always attempt to send the <code>Content-Length</code>. But
+ if the body is large and the original request used chunked
+ encoding, then chunked encoding may also be used in the upstream
+ request. You can control this selection using <a href="../env.html">environment variables</a>. Setting
+ <code>proxy-sendcl</code> ensures maximum compatibility with
+ upstream servers by always sending the
+ <code>Content-Length</code>, while setting
+ <code>proxy-sendchunked</code> minimizes resource usage by using
+ chunked encoding.</p>
+
</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="AllowCONNECT" id="AllowCONNECT">AllowCONNECT</a> <a name="allowconnect" id="allowconnect">Directive</a></h2>
<?xml version="1.0" encoding="iso-2022-jp"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
-<!-- English Revision: 189754:290723 (outdated) -->
+<!-- English Revision: 189754:326130 (outdated) -->
<!--
Copyright 2005 The Apache Software Foundation or its licensors, as
<div id="quickview"><h3 class="directives">Directives</h3>
<p>This module provides no
directives.</p>
-<h3>See also</h3>
+<h3>Topics</h3>
+<ul id="topics">
+<li><img alt="" src="../images/down.gif" /> <a href="#mimetypes">Why doesn't file type <var>xxx</var>
+ download via FTP?</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#type">How can I force an FTP ASCII download of
+ File <var>xxx</var>?</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#ftpnonget">How can I do FTP upload?</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#percent2fhck">How can I access FTP files outside
+ of my home directory?</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#ftppass">How can I hide the FTP cleartext password
+ in my browser's URL line?</a></li>
+</ul><h3>See also</h3>
<ul class="seealso">
<li><code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code></li>
</ul></div>
+<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="mimetypes" id="mimetypes">Why doesn't file type <var>xxx</var>
+ download via FTP?</a></h2>
+ <p>You probably don't have that particular file type defined as
+ <code>application/octet-stream</code> in your proxy's mime.types
+ configuration file. A useful line can be</p>
+ <div class="example"><pre>application/octet-stream bin dms lha lzh exe class tgz taz</pre></div>
+ <p>Alternatively you may prefer to default everything to binary:</p>
+ <div class="example"><pre>DefaultType application/octet-stream</pre></div>
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="type" id="type">How can I force an FTP ASCII download of
+ File <var>xxx</var>?</a></h2>
+ <p>In the rare situation where you must download a specific file using the
+ FTP <code>ASCII</code> transfer method (while the default transfer is in
+ <code>binary</code> mode), you can override <code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code>'s
+ default by suffixing the request with <code>;type=a</code> to force an
+ ASCII transfer. (FTP Directory listings are always executed in ASCII mode,
+ however.)</p>
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="ftpnonget" id="ftpnonget">How can I do FTP upload?</a></h2>
+ <p>Currently, only GET is supported for FTP in mod_proxy. You can
+ of course use HTTP upload (POST or PUT) through an Apache proxy.</p>
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="percent2fhck" id="percent2fhck">How can I access FTP files outside
+ of my home directory?</a></h2>
+ <p>An FTP URI is interpreted relative to the home directory of the user
+ who is logging in. Alas, to reach higher directory levels you cannot
+ use /../, as the dots are interpreted by the browser and not actually
+ sent to the FTP server. To address this problem, the so called <dfn>Squid
+ %2f hack</dfn> was implemented in the Apache FTP proxy; it is a
+ solution which is also used by other popular proxy servers like the <a href="http://www.squid-cache.org/">Squid Proxy Cache</a>. By
+ prepending <code>/%2f</code> to the path of your request, you can make
+ such a proxy change the FTP starting directory to <code>/</code> (instead
+ of the home directory). For example, to retrieve the file
+ <code>/etc/motd</code>, you would use the URL:</p>
+
+ <div class="example"><p><code>
+ ftp://<var>user</var>@<var>host</var>/%2f/etc/motd
+ </code></p></div>
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="ftppass" id="ftppass">How can I hide the FTP cleartext password
+ in my browser's URL line?</a></h2>
+ <p>To log in to an FTP server by username and password, Apache uses
+ different strategies. In absense of a user name and password in the URL
+ altogether, Apache sends an anonymous login to the FTP server,
+ <em>i.e.</em>,</p>
+
+ <div class="example"><p><code>
+ user: anonymous<br />
+ password: apache_proxy@
+ </code></p></div>
+
+ <p>This works for all popular FTP servers which are configured for
+ anonymous access.</p>
+
+ <p>For a personal login with a specific username, you can embed the user
+ name into the URL, like in:</p>
+
+ <div class="example"><p><code>
+ ftp://<var>username</var>@<var>host</var>/myfile
+ </code></p></div>
+
+ <p>If the FTP server asks for a password when given this username (which
+ it should), then Apache will reply with a <code>401</code> (Authorization
+ required) response, which causes the Browser to pop up the
+ username/password dialog. Upon entering the password, the connection
+ attempt is retried, and if successful, the requested resource is
+ presented. The advantage of this procedure is that your browser does not
+ display the password in cleartext (which it would if you had used</p>
+
+ <div class="example"><p><code>
+ ftp://<var>username</var>:<var>password</var>@<var>host</var>/myfile
+ </code></p></div>
+
+ <p>in the first place).</p>
+
+ <div class="note"><h3>Note</h3>
+ <p>The password which is transmitted in such a way is not encrypted on
+ its way. It travels between your browser and the Apache proxy server in
+ a base64-encoded cleartext string, and between the Apache proxy and the
+ FTP server as plaintext. You should therefore think twice before
+ accessing your FTP server via HTTP (or before accessing your personal
+ files via FTP at all!) When using unsecure channels, an eavesdropper
+ might intercept your password on its way.</p>
+ </div>
+ </div>
</div>
<div class="bottomlang">
<p><span>Available Languages: </span><a href="../en/mod/mod_proxy_ftp.html" title="English"> en </a></p>
<tr><th><a href="module-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="module-dict.html#ModuleIdentifier">Module Identifier:</a></th><td>version_module</td></tr>
<tr><th><a href="module-dict.html#SourceFile">Source File:</a></th><td>mod_version.c</td></tr>
-<tr><th><a href="module-dict.html#Compatibility">Compatibility:</a></th><td>Available in version 2.1 and later</td></tr></table>
+<tr><th><a href="module-dict.html#Compatibility">Compatibility:</a></th><td>Available in version 2.0.56 and later</td></tr></table>
<h3>Summary</h3>
<p>This module is designed for the use in test suites and large
<?xml version="1.0" encoding="iso-2022-jp"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
-<!-- English Revision: 151408:290723 (outdated) -->
+<!-- English Revision: 151408:326136 (outdated) -->
<!--
Copyright 2004-2005 The Apache Software Foundation or its licensors,
<?xml version="1.0" encoding="EUC-KR" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
-<!-- English Revision: 105989:290723 (outdated) -->
+<!-- English Revision: 105989:326136 (outdated) -->
<!--
Copyright 2004-2005 The Apache Software Foundation or its licensors,
projects / apache / commitdiff