<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>
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>
# 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.