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