Note that CRL-querying browsers can have problems with low header timeouts.

Add another expamle config.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1032695 13f79535-47bb-0310-9956-ffa450edef68

diff --git a/docs/manual/mod/mod_reqtimeout.xml b/docs/manual/mod/mod_reqtimeout.xml
index ca71cc1547f8470d7fea63624d439f58590b1ec0..52567df8ee56e469781645f0560e0ff3115b06b7 100644 (file)
--- a/docs/manual/mod/mod_reqtimeout.xml
+++ b/docs/manual/mod/mod_reqtimeout.xml
@@ -65,6 +65,16 @@
         </example>
       </li>
 
+      <li>
+        Usually, a server should have both header and body timeouts configured.
+        If a common configuration is used for http and https virtual hosts, the
+        timeouts should not be set too low:
+
+        <example>
+          RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500
+        </example>
+      </li>
+
     </ol>
 </section>
 
@@ -87,8 +97,13 @@
     is sent.</p>
 
     <p>For SSL virtual hosts, the header timeout values include the time needed
-    to do the initial SSL handshake. The body timeout values include the time
-    needed for SSL renegotiation (if necessary).</p>
+    to do the initial SSL handshake.  If the user's browser is configured to
+    query certificate revocation lists and the CRL server is not reachable, the
+    initial SSL handshake may take a significant time until the browser gives up
+    waiting for the CRL.  Therefore the header timeout values should not be set
+    to very low values for SSL virtual hosts.
+    The body timeout values include the time needed for SSL renegotiation
+    (if necessary).</p>
 
     <p>When an <directive module="core">AcceptFilter</directive> is in use
     (usually the case on Linux and FreeBSD), the socket is not sent to the