]> git.ipfire.org Git - thirdparty/apache/httpd.git/commitdiff
Update transformations
authorVincent Bray <noodl@apache.org>
Wed, 20 Aug 2008 22:55:37 +0000 (22:55 +0000)
committerVincent Bray <noodl@apache.org>
Wed, 20 Aug 2008 22:55:37 +0000 (22:55 +0000)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@687496 13f79535-47bb-0310-9956-ffa450edef68

docs/manual/mod/mod_proxy_http.html.en
docs/manual/mod/mod_ssl.html.en
docs/manual/rewrite/rewrite_guide.html.en

index 396ba6106ae0c688c8cf2d9785b2ca7e9cb74539..6fdc34486a039612ac4afc88bfa6d50e35bbe258 100644 (file)
         <dt>proxy-nokeepalive</dt>
         <dd>Forces the proxy to close the backend connection after
         each request.</dd>
-        <dt>Proxy-Chain-Auth</dt>
+        <dt>proxy-chain-auth</dt>
         <dd>If the proxy requires authentication, it will read and
         consume the proxy authentication credentials sent by the client.
-        With <var>Proxy-Chain-Auth</var> it will <em>also</em> forward
+        With <var>proxy-chain-auth</var> it will <em>also</em> forward
         the credentials to the next proxy in the chain.  This may
         be necessary if you have a chain of proxies that share
         authentication information.  <strong>Security Warning:</strong>
         <code>proxy-interim-response RFC</code> to be fully protocol
         compliant, or <code>proxy-interim-response Suppress</code>
         to suppress interim responses.</dd>
+        <dt>proxy-initial-not-pooled</dt>
+        <dd>If this variable is set no pooled connection will be reused
+        if the client connection is an initial connection. This avoids
+        the "proxy: error reading status line from remote server" error message
+        caused by the race condition that the backend server closed the
+        pooled connection after the connection check by the proxy and
+        before data send by the proxy reached the backend. It has to be
+        kept in mind that setting this variable downgrades performance,
+        especially with HTTP/1.0 clients.
+        </dd>
     </dl>
 </div>
 </div>
index a16230f796acc796029c936cdb0d9510eebe1b74..b6919b864700ffb0c11c1db2e02e7586e66f0df8 100644 (file)
@@ -361,10 +361,10 @@ authentication. Because although placing a CA certificate of the
 server certificate chain into <code class="directive"><a href="#sslcacertificatepath">SSLCACertificatePath</a></code> has the same effect
 for the certificate chain construction, it has the side-effect that
 client certificates issued by this same CA certificate are also
-accepted on client authentication. That's usually not one expect.</p>
+accepted on client authentication.</p>
 <p>
 But be careful: Providing the certificate chain works only if you are using a
-<em>single</em> (either RSA <em>or</em> DSA) based server certificate. If you are
+<em>single</em> RSA <em>or</em> DSA based server certificate. If you are
 using a coupled RSA+DSA certificate pair, this will work only if actually both
 certificates use the <em>same</em> certificate chain. Else the browsers will be
 confused in this situation.</p>
index ba7a703b44d2173a18aaed2530da7a8069f8ca38..9c29c21997ffc45eea3bedafdd5fec83664e17fc 100644 (file)
@@ -306,13 +306,13 @@ RewriteEngine on
 
 #   first try to find it in dir1/...
 #   ...and if found stop and be happy:
-RewriteCond         /your/docroot/<strong>dir1</strong>/%{REQUEST_FILENAME}  -f
-RewriteRule  ^(.+)  /your/docroot/<strong>dir1</strong>/$1  [L]
+RewriteCond         %{DOCUMENT_ROOT}/<strong>dir1</strong>/%{REQUEST_FILENAME}  -f
+RewriteRule  ^(.+)  %{DOCUMENT_ROOT}/<strong>dir1</strong>/$1  [L]
 
 #   second try to find it in dir2/...
 #   ...and if found stop and be happy:
-RewriteCond         /your/docroot/<strong>dir2</strong>/%{REQUEST_FILENAME}  -f
-RewriteRule  ^(.+)  /your/docroot/<strong>dir2</strong>/$1  [L]
+RewriteCond         %{DOCUMENT_ROOT}/<strong>dir2</strong>/%{REQUEST_FILENAME}  -f
+RewriteRule  ^(.+)  %{DOCUMENT_ROOT}/<strong>dir2</strong>/$1  [L]
 
 #   else go on for other Alias or ScriptAlias directives,
 #   etc.