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.
This commit is contained in:
Jerome Magnin 2020-04-23 19:01:17 +02:00 committed by Willy Tarreau
parent 62ba9ba6ca
commit 95fb57b923

View File

@ -7383,21 +7383,27 @@ no option log-separate-errors
option logasap option logasap
no 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 May be used in sections : defaults | frontend | listen | backend
yes | yes | yes | no yes | yes | yes | no
Arguments : none Arguments : none
By default, HTTP requests are logged upon termination so that the total By default, logs are emitted when all the log format variables and sample
transfer time and the number of bytes appear in the logs. When large objects fetches used in the definition of the log-format string return a value, or
are being transferred, it may take a while before the request appears in the when the session is terminated. This allows the built in log-format strings
logs. Using "option logasap", the request gets logged as soon as the server to account for the transfer time, or the number of bytes in log messages.
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 When handling long lived connections such as large file transfers or RDP,
of data transferred, and the total time which will not take the transfer it may take a while for the request or connection to appear in the logs.
time into account. In such a situation, it's a good practice to capture the Using "option logasap", the log message is created as soon as the server
"Content-Length" response header so that the logs at least indicate how many connection is established in mode tcp, or as soon as the server sends the
bytes are expected to be transferred. 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 : Examples :
listen http_proxy 0.0.0.0:80 listen http_proxy 0.0.0.0:80