DOC: option logasap does not depend on mode

The documentation for option logasap misleads into thinking it is
only valid for mode http. It is actually valid for mode tcp too,
so this patch tries to disambiguate the current wording.

diff --git a/doc/configuration.txt b/doc/configuration.txt
index 2dbb893a2487cac04e1012273beec7e5cf640ba2..676d5a07559e455dcca12f481578cd64b62336bc 100644 (file)
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -7383,21 +7383,27 @@ no option log-separate-errors
 
 option logasap
 no option logasap
-  Enable or disable early logging of HTTP requests
+  Enable or disable early logging.
   May be used in sections :   defaults | frontend | listen | backend
                                  yes   |    yes   |   yes  |   no
   Arguments : none
 
-  By default, HTTP requests are logged upon termination so that the total
-  transfer time and the number of bytes appear in the logs. When large objects
-  are being transferred, it may take a while before the request appears in the
-  logs. Using "option logasap", the request gets logged as soon as the server
-  sends the complete headers. The only missing information in the logs will be
-  the total number of bytes which will indicate everything except the amount
-  of data transferred, and the total time which will not take the transfer
-  time into account. In such a situation, it's a good practice to capture the
-  "Content-Length" response header so that the logs at least indicate how many
-  bytes are expected to be transferred.
+  By default, logs are emitted when all the log format variables and sample
+  fetches used in the definition of the log-format string return a value, or
+  when the session is terminated. This allows the built in log-format strings
+  to account for the transfer time, or the number of bytes in log messages.
+
+  When handling long lived connections such as large file transfers or RDP,
+  it may take a while for the request or connection to appear in the logs.
+  Using "option logasap", the log message is created as soon as the server
+  connection is established in mode tcp, or as soon as the server sends the
+  complete headers in mode http. Missing information in the logs will be the
+  total number of bytes which will only indicate the amount of data transfered
+  before the message was created and the total time which will not take the
+  remainder of the connection life or transfer time into account. For the case
+  of HTTP, it is good practice to capture the Content-Length response header
+  so that the logs at least indicate how many bytes are expected to be
+  transfered.
 
   Examples :
       listen http_proxy 0.0.0.0:80