You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by sl...@apache.org on 2005/10/18 17:59:03 UTC
svn commit: r326131 - in /httpd/httpd/branches/2.2.x/docs/manual: env.xml
mod/mod_proxy.xml mod/mod_proxy_ftp.xml
Author: slive
Date: Tue Oct 18 08:59:01 2005
New Revision: 326131
URL: http://svn.apache.org/viewcvs?rev=326131&view=rev
Log:
Merge r326130 from trunk:
Proxy docs changes:
- Move ftp-related questions to mod_proxy_ftp.
- Document the proxy-sendcl and proxy-sendchunked env variables.
- Improve the docs on the other proxy env variables.
Modified:
httpd/httpd/branches/2.2.x/docs/manual/env.xml
httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy.xml
httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy_ftp.xml
Modified: httpd/httpd/branches/2.2.x/docs/manual/env.xml
URL: http://svn.apache.org/viewcvs/httpd/httpd/branches/2.2.x/docs/manual/env.xml?rev=326131&r1=326130&r2=326131&view=diff
==============================================================================
--- httpd/httpd/branches/2.2.x/docs/manual/env.xml (original)
+++ httpd/httpd/branches/2.2.x/docs/manual/env.xml Tue Oct 18 08:59:01 2005
@@ -366,6 +366,13 @@
</section>
+ <section id="proxy"><title>force-proxy-request-1.0, proxy-nokeepalive, proxy-sendchunked, proxy-sendcl</title>
+
+ <p>These directives alter the protocol behavior of
+ <module>mod_proxy</module>. See the <module>mod_proxy</module>
+ documentation for more details.</p>
+ </section>
+
</section>
<section id="examples">
@@ -374,8 +381,10 @@
<section id="misbehaving">
<title>Changing protocol behavior with misbehaving clients</title>
- <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>
<example><pre>
#
# The following directives modify normal HTTP response behavior.
Modified: httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy.xml
URL: http://svn.apache.org/viewcvs/httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy.xml?rev=326131&r1=326130&r2=326131&view=diff
==============================================================================
--- httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy.xml (original)
+++ httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy.xml Tue Oct 18 08:59:01 2005
@@ -188,105 +188,6 @@
</section> <!-- /access -->
- <section id="ftp-proxy"><title>FTP Proxy</title>
-
-
- <section id="mimetypes"><title>Why doesn't file type <var>xxx</var>
- download via FTP?</title>
- <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>
-
- <example>
-<pre>application/octet-stream bin dms lha lzh exe class tgz taz</pre>
- </example>
- <p>Alternatively you may prefer to default everything to binary:</p>
- <example>
-<pre>DefaultType application/octet-stream</pre>
- </example>
- </section> <!-- /mimetypes -->
-
- <section id="type"><title>How can I force an FTP ASCII download of
- File <var>xxx</var>?</title>
- <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 <module>mod_proxy</module>'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>
- </section> <!-- /type -->
-
- <section id="ftpnonget"><title>How can I do FTP upload?</title>
- <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>
- </section>
-
- <section id="percent2fhck"><title>How can I access FTP files outside
- of my home directory?</title>
- <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>
-
- <example>
- ftp://<var>user</var>@<var>host</var>/%2f/etc/motd
- </example>
- </section> <!-- /percent2fhck -->
-
- <section id="ftppass"><title>How can I hide the FTP cleartext password
- in my browser's URL line?</title>
- <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>
-
- <example>
- user: anonymous<br />
- password: apache_proxy@
- </example>
-
- <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>
-
- <example>
- ftp://<var>username</var>@<var>host</var>/myfile
- </example>
-
- <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>
-
- <example>
- ftp://<var>username</var>:<var>password</var>@<var>host</var>/myfile
- </example>
-
- <p>in the first place).</p>
-
- <note><title>Note</title>
- <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>
- </note>
- </section> <!-- /ftppass -->
- </section> <!-- /ftpproxy -->
<section id="startup"><title>Slow Startup</title>
<p>If you're using the <directive module="mod_proxy"
>ProxyBlock</directive> directive, hostnames' IP addresses are looked up
@@ -319,10 +220,12 @@
</section> <!-- /intranet -->
<section id="envsettings"><title>Protocol Adjustments</title>
- <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 <directive module="mod_env">SetEnv</directive> directive.</p>
+ <p>For circumstances where <module>mod_proxy</module> 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
+ <directive module="mod_env">SetEnv</directive> directive.</p>
<p>These are the <code>force-proxy-request-1.0</code> and
<code>proxy-nokeepalive</code> notes.</p>
@@ -336,7 +239,28 @@
</indent>
</Location>
</example>
+
</section> <!-- /envsettings -->
+
+ <section id="request-bodies"><title>Request Bodys</title>
+
+ <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, <module>mod_proxy_http</module>
+ 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>
+
+ </section> <!-- /request-bodies -->
<directivesynopsis type="section">
<name>Proxy</name>
Modified: httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy_ftp.xml
URL: http://svn.apache.org/viewcvs/httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy_ftp.xml?rev=326131&r1=326130&r2=326131&view=diff
==============================================================================
--- httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy_ftp.xml (original)
+++ httpd/httpd/branches/2.2.x/docs/manual/mod/mod_proxy_ftp.xml Tue Oct 18 08:59:01 2005
@@ -48,4 +48,101 @@
</summary>
<seealso><module>mod_proxy</module></seealso>
+ <section id="mimetypes"><title>Why doesn't file type <var>xxx</var>
+ download via FTP?</title>
+ <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>
+
+ <example>
+<pre>application/octet-stream bin dms lha lzh exe class tgz taz</pre>
+ </example>
+ <p>Alternatively you may prefer to default everything to binary:</p>
+ <example>
+<pre>DefaultType application/octet-stream</pre>
+ </example>
+ </section> <!-- /mimetypes -->
+
+ <section id="type"><title>How can I force an FTP ASCII download of
+ File <var>xxx</var>?</title>
+ <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 <module>mod_proxy</module>'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>
+ </section> <!-- /type -->
+
+ <section id="ftpnonget"><title>How can I do FTP upload?</title>
+ <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>
+ </section>
+
+ <section id="percent2fhck"><title>How can I access FTP files outside
+ of my home directory?</title>
+ <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>
+
+ <example>
+ ftp://<var>user</var>@<var>host</var>/%2f/etc/motd
+ </example>
+ </section> <!-- /percent2fhck -->
+
+ <section id="ftppass"><title>How can I hide the FTP cleartext password
+ in my browser's URL line?</title>
+ <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>
+
+ <example>
+ user: anonymous<br />
+ password: apache_proxy@
+ </example>
+
+ <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>
+
+ <example>
+ ftp://<var>username</var>@<var>host</var>/myfile
+ </example>
+
+ <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>
+
+ <example>
+ ftp://<var>username</var>:<var>password</var>@<var>host</var>/myfile
+ </example>
+
+ <p>in the first place).</p>
+
+ <note><title>Note</title>
+ <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>
+ </note>
+ </section> <!-- /ftppass -->
+
+
</modulesynopsis>