httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sl...@apache.org
Subject svn commit: r326130 - in /httpd/httpd/trunk/docs/manual: env.xml mod/mod_proxy.xml mod/mod_proxy_ftp.xml
Date Tue, 18 Oct 2005 15:54:57 GMT
Author: slive
Date: Tue Oct 18 08:54:54 2005
New Revision: 326130

URL: http://svn.apache.org/viewcvs?rev=326130&view=rev
Log:
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/trunk/docs/manual/env.xml
    httpd/httpd/trunk/docs/manual/mod/mod_proxy.xml
    httpd/httpd/trunk/docs/manual/mod/mod_proxy_ftp.xml

Modified: httpd/httpd/trunk/docs/manual/env.xml
URL: http://svn.apache.org/viewcvs/httpd/httpd/trunk/docs/manual/env.xml?rev=326130&r1=326129&r2=326130&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/env.xml (original)
+++ httpd/httpd/trunk/docs/manual/env.xml Tue Oct 18 08:54:54 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/trunk/docs/manual/mod/mod_proxy.xml
URL: http://svn.apache.org/viewcvs/httpd/httpd/trunk/docs/manual/mod/mod_proxy.xml?rev=326130&r1=326129&r2=326130&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_proxy.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_proxy.xml Tue Oct 18 08:54:54 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>
         &lt;/Location&gt;
       </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/trunk/docs/manual/mod/mod_proxy_ftp.xml
URL: http://svn.apache.org/viewcvs/httpd/httpd/trunk/docs/manual/mod/mod_proxy_ftp.xml?rev=326130&r1=326129&r2=326130&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_proxy_ftp.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_proxy_ftp.xml Tue Oct 18 08:54:54 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>



Mime
View raw message