| <?xml version="1.0"?> | |
| <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd"> | |
| <?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?> | |
| <!-- $LastChangedRevision$ --> | |
| <!-- | |
| Licensed to the Apache Software Foundation (ASF) under one or more | |
| contributor license agreements. See the NOTICE file distributed with | |
| this work for additional information regarding copyright ownership. | |
| The ASF licenses this file to You under the Apache License, Version 2.0 | |
| (the "License"); you may not use this file except in compliance with | |
| the License. You may obtain a copy of the License at | |
| http://www.apache.org/licenses/LICENSE-2.0 | |
| Unless required by applicable law or agreed to in writing, software | |
| distributed under the License is distributed on an "AS IS" BASIS, | |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | |
| See the License for the specific language governing permissions and | |
| limitations under the License. | |
| --> | |
| <modulesynopsis metafile="mod_log_config.xml.meta"> | |
| <name>mod_log_config</name> | |
| <description>Logging of the requests made to the server</description> | |
| <status>Base</status> | |
| <sourcefile>mod_log_config.c</sourcefile> | |
| <identifier>log_config_module</identifier> | |
| <summary> | |
| <p>This module provides for flexible logging of client | |
| requests. Logs are written in a customizable format, and may be | |
| written directly to a file, or to an external program. | |
| Conditional logging is provided so that individual requests may | |
| be included or excluded from the logs based on characteristics | |
| of the request.</p> | |
| <p>Three directives are provided by this module: | |
| <directive module="mod_log_config">TransferLog</directive> to create | |
| a log file, <directive module="mod_log_config">LogFormat</directive> | |
| to set a custom format, and <directive module="mod_log_config" | |
| >CustomLog</directive> to define a log file and format in one | |
| step. The <directive>TransferLog</directive> and <directive | |
| >CustomLog</directive> directives can be used multiple times in each | |
| server to cause each request to be logged to multiple files.</p> | |
| </summary> | |
| <seealso><a href="../logs.html">Apache Log Files</a></seealso> | |
| <section id="formats"><title>Custom Log Formats</title> | |
| <p>The format argument to the <directive module="mod_log_config" | |
| >LogFormat</directive> and <directive module="mod_log_config" | |
| >CustomLog</directive> directives is a string. This string is | |
| used to log each request to the log file. It can contain literal | |
| characters copied into the log files and the C-style control | |
| characters "\n" and "\t" to represent new-lines and tabs. | |
| Literal quotes and backslashes should be escaped with | |
| backslashes.</p> | |
| <p>The characteristics of the request itself are logged by | |
| placing "<code>%</code>" directives in the format string, which are | |
| replaced in the log file by the values as follows:</p> | |
| <table border="1" style="zebra"> | |
| <columnspec><column width=".2"/><column width=".8"/></columnspec> | |
| <tr><th>Format String</th> | |
| <th>Description</th></tr> | |
| <tr><td><code>%%</code></td> | |
| <td>The percent sign.</td></tr> | |
| <tr><td><code>%a</code></td> | |
| <td>Client IP address of the request (see the | |
| <module>mod_remoteip</module> module).</td></tr> | |
| <tr><td><code>%{c}a</code></td> | |
| <td>Underlying peer IP address of the connection (see the | |
| <module>mod_remoteip</module> module).</td></tr> | |
| <tr><td><code>%A</code></td> | |
| <td>Local IP-address.</td></tr> | |
| <tr><td><code>%B</code></td> | |
| <td>Size of response in bytes, excluding HTTP headers.</td></tr> | |
| <tr><td><code>%b</code></td> | |
| <td>Size of response in bytes, excluding HTTP headers. In CLF format, <em>i.e.</em> | |
| a '<code>-</code>' rather than a 0 when no bytes are sent.</td></tr> | |
| <tr><td><code>%{<var>VARNAME</var>}C</code></td> | |
| <td>The contents of cookie <var>VARNAME</var> in the request sent | |
| to the server. Only version 0 cookies are fully supported.</td></tr> | |
| <tr><td><code>%D</code></td> | |
| <td>The time taken to serve the request, in microseconds. See %T for details.</td></tr> | |
| <tr><td><code>%{<var>VARNAME</var>}e</code></td> | |
| <td>The contents of the environment variable | |
| <var>VARNAME</var>.</td></tr> | |
| <tr><td><code>%f</code></td> | |
| <td>Filename.</td></tr> | |
| <tr><td><code>%h</code></td> | |
| <td>Remote hostname. Will log the IP address if <directive | |
| module="core">HostnameLookups</directive> is set to | |
| <code>Off</code>, which is the default. If it logs the hostname | |
| for only a few hosts, you probably have access control | |
| directives mentioning them by name. See <a | |
| href="mod_authz_host.html#reqhost">the Require host | |
| documentation</a>. This format is affected by modifications to the | |
| remote hostname by modules like <module>mod_remoteip</module>.</td></tr> | |
| <tr><td><code>%{c}h</code></td> | |
| <td>Like <code>%h</code>, but always reports on the hostname of the | |
| underlying TCP connection and not any modifications to the | |
| remote hostname by modules like <module>mod_remoteip</module>.</td></tr> | |
| <tr><td><code>%H</code></td> | |
| <td>The request protocol.</td></tr> | |
| <tr><td><code>%{<var>VARNAME</var>}i</code></td> | |
| <td>The contents of <code><var>VARNAME</var>:</code> header line(s) | |
| in the request sent to the server. Changes made by other | |
| modules (e.g. <module>mod_headers</module>) affect this. If you're | |
| interested in what the request header was prior to when most | |
| modules would have modified it, use <module>mod_setenvif</module> | |
| to copy the header into an internal environment variable and log | |
| that value with the <code>%{<var>VARNAME</var>}e</code> described | |
| above. | |
| </td></tr> | |
| <tr><td><code>%k</code></td> | |
| <td>Number of keepalive requests handled on this connection. Interesting if | |
| <directive module="core">KeepAlive</directive> is being used, so that, | |
| for example, a '1' means the first keepalive request after the initial | |
| one, '2' the second, etc...; | |
| otherwise this is always 0 (indicating the initial request).</td></tr> | |
| <tr><td><code>%l</code></td> | |
| <td>Remote logname (from identd, if supplied). This will return a | |
| dash unless <module>mod_ident</module> is present and <directive | |
| module="mod_ident">IdentityCheck</directive> is set | |
| <code>On</code>.</td></tr> | |
| <tr><td><code>%L</code></td> | |
| <td>The request log ID from the error log (or '-' if nothing has been | |
| logged to the error log for this request). Look for the | |
| matching error log line to see what request caused what error.</td></tr> | |
| <tr><td><code>%{c}L</code></td> | |
| <td>The connection log ID from the error log (or '-' if nothing has been | |
| logged to the error log for this request). Look for the | |
| matching error log line to see what request caused what error.</td></tr> | |
| <tr><td><code>%m</code></td> | |
| <td>The request method.</td></tr> | |
| <tr><td><code>%{<var>VARNAME</var>}n</code></td> | |
| <td>The contents of note <var>VARNAME</var> from another | |
| module.</td></tr> | |
| <tr><td><code>%{<var>VARNAME</var>}o</code></td> | |
| <td>The contents of <code><var>VARNAME</var>:</code> header line(s) | |
| in the reply.</td></tr> | |
| <tr><td><code>%p</code></td> | |
| <td>The canonical port of the server serving the request.</td></tr> | |
| <tr><td><code>%{<var>format</var>}p</code></td> | |
| <td>The canonical port of the server serving the request, or the | |
| server's actual port, or the client's actual port. Valid formats | |
| are <code>canonical</code>, <code>local</code>, or <code>remote</code>. | |
| </td></tr> | |
| <tr><td><code>%P</code></td> | |
| <td>The process ID of the child that serviced the request.</td></tr> | |
| <tr><td><code>%{<var>format</var>}P</code></td> | |
| <td>The process ID or thread ID of the child that serviced the | |
| request. Valid formats are <code>pid</code>, <code>tid</code>, | |
| and <code>hextid</code>. | |
| </td></tr> | |
| <tr><td><code>%q</code></td> | |
| <td>The query string (prepended with a <code>?</code> if a query | |
| string exists, otherwise an empty string).</td></tr> | |
| <tr><td><code>%r</code></td> | |
| <td>First line of request. Does not adhere to | |
| <directive module="core">MergeSlashes</directive>. (i.e. no merging | |
| even if ON)</td></tr> | |
| <tr><td><code>%R</code></td> | |
| <td>The handler generating the response (if any).</td></tr> | |
| <tr><td><code>%s</code></td> | |
| <td>Status. For requests that have been internally redirected, this is | |
| the status of the <em>original</em> request. Use <code>%>s</code> | |
| for the final status.</td></tr> | |
| <tr><td><code>%t</code></td> | |
| <td>Time the request was received, in the format <code>[18/Sep/2011:19:18:28 -0400]</code>. | |
| The last number indicates the timezone offset from GMT</td></tr> | |
| <tr><td><code>%{<var>format</var>}t</code></td> | |
| <td>The time, in the form given by format, which should be in | |
| an extended <code>strftime(3)</code> format (potentially localized). | |
| If the format starts with <code>begin:</code> (default) the time is taken | |
| at the beginning of the request processing. If it starts with | |
| <code>end:</code> it is the time when the log entry gets written, | |
| close to the end of the request processing. In addition to the formats | |
| supported by <code>strftime(3)</code>, the following format tokens are | |
| supported: | |
| <table> | |
| <tr><td><code>sec</code></td><td>number of seconds since the Epoch</td></tr> | |
| <tr><td><code>msec</code></td><td>number of milliseconds since the Epoch</td></tr> | |
| <tr><td><code>usec</code></td><td>number of microseconds since the Epoch</td></tr> | |
| <tr><td><code>msec_frac</code></td><td>millisecond fraction</td></tr> | |
| <tr><td><code>usec_frac</code></td><td>microsecond fraction</td></tr> | |
| </table> | |
| These tokens can not be combined with each other or <code>strftime(3)</code> | |
| formatting in the same format string. You can use multiple | |
| <code>%{<var>format</var>}t</code> tokens instead. | |
| </td></tr> | |
| <tr><td><code>%T</code></td> | |
| <td><p>The time taken to serve the request, in seconds. The time measured | |
| begins when the first line of the HTTP request is read from the host | |
| operating system by the HTTP server and ends when the last byte of | |
| the response is written by the HTTP server to the host operating system.</p> | |
| <p>The time measured does <em>not</em> include any of the following:</p> | |
| <ul> | |
| <li> Time spent in TCP or TLS handshakes.</li> | |
| <li> The time before a webserver thread is able to read the first | |
| line of the request.</li> | |
| <li> Delays in the operating system putting the response data out | |
| onto the network.</li> | |
| <li> Time taken for the response to arrive at the client host.</li> | |
| <li> Time taken for the useragent to read and process the | |
| response.</li> | |
| </ul> | |
| </td></tr> | |
| <tr><td><code>%{<var>UNIT</var>}T</code></td> | |
| <td>The time taken to serve the request, in a time unit given by | |
| <code>UNIT</code>. Valid units are <code>ms</code> for milliseconds, | |
| <code>us</code> for microseconds, and <code>s</code> for seconds. | |
| Using <code>s</code> gives the same result as <code>%T</code> | |
| without any format; using <code>us</code> gives the same result | |
| as <code>%D</code>. Combining <code>%T</code> with a unit is | |
| available in 2.4.13 and later.</td></tr> | |
| <tr><td><code>%u</code></td> | |
| <td>Remote user if the request was authenticated. May be bogus if return status | |
| (<code>%s</code>) is 401 (unauthorized).</td></tr> | |
| <tr><td><code>%U</code></td> | |
| <td>The URL path requested, not including any query string. | |
| Adheres to <directive module="core">MergeSlashes</directive>. | |
| (i.e. slashes are merged if <code>ON</code>)</td></tr> | |
| <tr><td><code>%v</code></td> | |
| <td>The canonical <directive module="core">ServerName</directive> | |
| of the server serving the request.</td></tr> | |
| <tr><td><code>%V</code></td> | |
| <td>The server name according to the <directive module="core" | |
| >UseCanonicalName</directive> setting.</td></tr> | |
| <tr><td><code>%X</code></td> | |
| <td>Connection status when response is completed: | |
| <table> | |
| <columnspec><column width=".2"/><column width=".6"/></columnspec> | |
| <tr><td><code>X</code> =</td> | |
| <td>Connection aborted before the response completed.</td></tr> | |
| <tr><td><code>+</code> =</td> | |
| <td>Connection may be kept alive after the response is | |
| sent.</td></tr> | |
| <tr><td><code>-</code> = </td> | |
| <td>Connection will be closed after the response is | |
| sent.</td></tr> | |
| </table> | |
| </td></tr> | |
| <tr><td><code>%I</code></td> | |
| <td>Bytes received, including request and headers. Cannot be zero. | |
| You need to enable <module>mod_logio</module> to use this.</td></tr> | |
| <tr><td><code>%O</code></td> | |
| <td>Bytes sent, including headers. May be zero in rare cases | |
| such as when a request is aborted before a response is sent. | |
| You need to enable <module>mod_logio</module> to use this.</td></tr> | |
| <tr><td><code>%S</code></td> | |
| <td>Bytes transferred (received and sent), including request and headers, | |
| cannot be zero. This is the combination of %I and %O. You need to | |
| enable <module>mod_logio</module> to use this.</td></tr> | |
| <tr><td><code>%{<var>VARNAME</var>}^ti</code></td> | |
| <td>The contents of <code><var>VARNAME</var>:</code> trailer line(s) | |
| in the request sent to the server. </td></tr> | |
| <tr><td><code>%{<var>VARNAME</var>}^to</code></td> | |
| <td>The contents of <code><var>VARNAME</var>:</code> trailer line(s) | |
| in the response sent from the server. </td></tr> | |
| </table> | |
| <section id="modifiers"><title>Modifiers</title> | |
| <p>Particular items can be restricted to print only for | |
| responses with specific HTTP status codes by placing a | |
| comma-separated list of status codes immediately following the | |
| "%". The status code list may be preceded by a "<code>!</code>" to | |
| indicate negation.</p> | |
| <table border="1" style="zebra"> | |
| <columnspec><column width=".2"/><column width=".8"/></columnspec> | |
| <tr><th>Format String</th> | |
| <th>Meaning</th></tr> | |
| <tr> | |
| <td><code>%400,501{User-agent}i</code></td> | |
| <td>Logs <code>User-agent</code> on 400 errors and 501 errors only. For | |
| other status codes, the literal string <code>"-"</code> will be | |
| logged.</td></tr> | |
| <tr><td><code>%!200,304,302{Referer}i</code></td> | |
| <td>Logs <code>Referer</code> on all requests that do | |
| <em>not</em> return one of the three specified codes, | |
| "<code>-</code>" otherwise. | |
| </td></tr> | |
| </table> | |
| <p>The modifiers "<" and ">" can be used for requests that | |
| have been internally redirected to choose whether the original | |
| or final (respectively) request should be consulted. By | |
| default, the <code>%</code> directives <code>%s, %U, %T, | |
| %D,</code> and <code>%r</code> look at the original request | |
| while all others look at the final request. So for example, | |
| <code>%>s</code> can be used to record the final status of | |
| the request and <code>%<u</code> can be used to record the | |
| original authenticated user on a request that is internally | |
| redirected to an unauthenticated resource.</p> | |
| </section> | |
| <section id="format-notes"><title>Format Notes</title> | |
| <p>For security reasons, starting with version 2.0.46, | |
| non-printable and other special characters in format strings | |
| that may contain arbitrary string data are escaped using | |
| <code>\x<var>hh</var></code> sequences, where <var>hh</var> | |
| stands for the hexadecimal representation of the raw | |
| byte. Exceptions from this rule are <code>"</code> and | |
| <code>\</code>, which are escaped by prepending a backslash, and | |
| all whitespace characters, which are written in their C-style | |
| notation (<code>\n</code>, <code>\t</code>, etc). In versions | |
| prior to 2.0.46, no escaping was performed on these strings so | |
| you had to be quite careful when dealing with raw log files.</p> | |
| <table> | |
| <columnspec><column width=".1"/><column width=".45"/><column width=".45"/></columnspec> | |
| <tr><th>Format</th><th>Description</th><th>Escaped</th></tr> | |
| <tr><td><code>%c</code></td><td>SSL variable (shortcut)</td><td>Yes</td></tr> | |
| <tr><td><code>%C</code></td><td>Cookie value</td><td>Yes</td></tr> | |
| <tr><td><code>%e</code></td><td>Environment variable</td><td>Yes</td></tr> | |
| <tr><td><code>%f</code></td><td>Request filename</td><td>Yes</td></tr> | |
| <tr><td><code>%h</code></td><td>Remote hostname</td><td>Yes</td></tr> | |
| <tr><td><code>%H</code></td><td>Request protocol</td><td>Yes</td></tr> | |
| <tr><td><code>%i</code></td><td>Request header</td><td>Yes</td></tr> | |
| <tr><td><code>%l</code></td><td>Remote logname</td><td>Yes</td></tr> | |
| <tr><td><code>%m</code></td><td>Request method</td><td>Yes</td></tr> | |
| <tr><td><code>%n</code></td><td>Note</td><td>Yes</td></tr> | |
| <tr><td><code>%o</code></td><td>Response header</td><td>Yes</td></tr> | |
| <tr><td><code>%q</code></td><td>Query string</td><td>Yes</td></tr> | |
| <tr><td><code>%r</code></td><td>Request line</td><td>Yes</td></tr> | |
| <tr><td><code>%R</code></td><td>Handler</td><td>Yes</td></tr> | |
| <tr><td><code>%u</code></td><td>Remote user</td><td>Yes</td></tr> | |
| <tr><td><code>%U</code></td><td>Request URI</td><td>Yes</td></tr> | |
| <tr><td><code>%v</code></td><td>Server hostname</td><td>Yes</td></tr> | |
| <tr><td><code>%V</code></td><td>Canonical server name</td><td>Yes</td></tr> | |
| <tr><td><code>%x</code></td><td>SSL variable</td><td>Yes</td></tr> | |
| <tr><td><code>%^ti</code></td><td>Request trailer</td><td>Yes</td></tr> | |
| <tr><td><code>%^to</code></td><td>Response trailer</td><td>Yes</td></tr> | |
| <tr><td><code>%a</code></td><td>Remote IP address</td><td>No (IP address)</td></tr> | |
| <tr><td><code>%A</code></td><td>Local IP address</td><td>No (IP address)</td></tr> | |
| <tr><td><code>%b</code>, <code>%B</code></td><td>Bytes sent</td><td>No (numeric)</td></tr> | |
| <tr><td><code>%D</code></td><td>Request duration (microseconds)</td><td>No (numeric)</td></tr> | |
| <tr><td><code>%F</code></td><td>Request flushed</td><td>No (single character)</td></tr> | |
| <tr><td><code>%k</code></td><td>Requests on connection</td><td>No (numeric)</td></tr> | |
| <tr><td><code>%L</code></td><td>Log ID</td><td>No (internally generated)</td></tr> | |
| <tr><td><code>%p</code></td><td>Server port</td><td>No (numeric)</td></tr> | |
| <tr><td><code>%P</code></td><td>PID/TID</td><td>No (numeric)</td></tr> | |
| <tr><td><code>%s</code></td><td>Status code</td><td>No (numeric)</td></tr> | |
| <tr><td><code>%t</code></td><td>Request time</td><td>No (formatted time)</td></tr> | |
| <tr><td><code>%T</code></td><td>Request duration (seconds)</td><td>No (numeric)</td></tr> | |
| <tr><td><code>%X</code></td><td>Connection status</td><td>No (single character)</td></tr> | |
| </table> | |
| <p>The <code>%b</code> and | |
| <code>%B</code> format strings do not represent the number of | |
| bytes sent to the client, but simply the size in bytes of the | |
| HTTP response (which will differ, for instance, if the | |
| connection is aborted, or if SSL is used). The <code>%O</code> | |
| format provided by <module>mod_logio</module> will log the | |
| actual number of bytes sent over the network.</p> | |
| <note> | |
| <p>Note: <module>mod_cache</module> is implemented as a | |
| quick-handler and not as a standard handler. Therefore, the | |
| <code>%R</code> format string will not return any handler | |
| information when content caching is involved.</p> | |
| </note> | |
| <note> | |
| <p>Note: The '^' character at the start of three-character formats | |
| has no significance, but it must be the first character of any newly | |
| added three-character format to avoid potential conflicts with log | |
| formats that use literals adjacent to a format specifier, such as | |
| "%Dus".</p> | |
| </note> | |
| </section> | |
| <section id="examples"><title>Examples</title> | |
| <p>Some commonly used log format strings are:</p> | |
| <dl> | |
| <dt>Common Log Format (CLF)</dt> | |
| <dd><code>"%h %l %u %t \"%r\" %>s %b"</code></dd> | |
| <dt>Common Log Format with Virtual Host</dt> | |
| <dd><code>"%v %h %l %u %t \"%r\" %>s %b"</code></dd> | |
| <dt>NCSA extended/combined log format</dt> | |
| <dd><code>"%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" | |
| \"%{User-agent}i\""</code></dd> | |
| <dt>Referer log format</dt> | |
| <dd><code>"%{Referer}i -> %U"</code></dd> | |
| <dt>Agent (Browser) log format</dt> | |
| <dd><code>"%{User-agent}i"</code></dd> | |
| </dl> | |
| <p>You can use the <code>%{format}t</code> directive multiple | |
| times to build up a time format using the extended format tokens | |
| like <code>msec_frac</code>:</p> | |
| <dl> | |
| <dt>Timestamp including milliseconds</dt> | |
| <dd><code>"%{%d/%b/%Y %T}t.%{msec_frac}t %{%z}t"</code></dd> | |
| </dl> | |
| </section> | |
| </section> | |
| <section id="security"><title>Security Considerations</title> | |
| <p>See the <a | |
| href="../misc/security_tips.html#serverroot">security tips</a> | |
| document for details on why your security could be compromised | |
| if the directory where logfiles are stored is writable by | |
| anyone other than the user that starts the server.</p> | |
| </section> | |
| <directivesynopsis> | |
| <name>BufferedLogs</name> | |
| <description>Buffer log entries in memory before writing to disk</description> | |
| <syntax>BufferedLogs On|Off</syntax> | |
| <default>BufferedLogs Off</default> | |
| <contextlist><context>server config</context></contextlist> | |
| <usage> | |
| <p>The <directive>BufferedLogs</directive> directive causes | |
| <module>mod_log_config</module> to store several log entries in | |
| memory and write them together to disk, rather than writing them | |
| after each request. On some systems, this may result in more | |
| efficient disk access and hence higher performance. It may be | |
| set only once for the entire server; it cannot be configured | |
| per virtual-host.</p> | |
| <note>This directive should be used with caution as a crash might | |
| cause loss of logging data.</note> | |
| </usage> | |
| </directivesynopsis> | |
| <directivesynopsis> | |
| <name>CustomLog</name> | |
| <description>Sets filename and format of log file</description> | |
| <syntax>CustomLog <var>file</var>|<var>pipe</var>|<var>provider</var> | |
| <var>format</var>|<var>nickname</var> | |
| [env=[!]<var>environment-variable</var>| | |
| expr=<var>expression</var>]</syntax> | |
| <contextlist><context>server config</context><context>virtual host</context> | |
| </contextlist> | |
| <usage> | |
| <p>The <directive>CustomLog</directive> directive is used to | |
| log requests to the server. A log format is specified, and the | |
| logging can optionally be made conditional on request | |
| characteristics using environment variables.</p> | |
| <p>The first argument, which specifies the location to which | |
| the logs will be written, can take one of the following two | |
| types of values:</p> | |
| <dl> | |
| <dt><var>file</var></dt> | |
| <dd>A filename, relative to the <directive module="core" | |
| >ServerRoot</directive>.</dd> | |
| <dt><var>pipe</var></dt> | |
| <dd>The pipe character "<code>|</code>", followed by the path | |
| to a program to receive the log information on its standard | |
| input. See the notes on <a href="../logs.html#piped">piped logs</a> | |
| for more information. | |
| <note type="warning"><title>Security:</title> | |
| <p>If a program is used, then it will be run as the user who | |
| started <program>httpd</program>. This will be root if the server was | |
| started by root; be sure that the program is secure.</p> | |
| </note> | |
| <note type="warning"><title>Note</title> | |
| <p>When entering a file path on non-Unix platforms, care should be taken | |
| to make sure that only forward slashed are used even though the platform | |
| may allow the use of back slashes. In general it is a good idea to always | |
| use forward slashes throughout the configuration files.</p> | |
| </note></dd> | |
| <dt><var>provider</var></dt> | |
| <dd>Modules implementing ErrorLog providers can also be used as a target | |
| for CustomLog messages. To use ErrorLog provider as a target, | |
| "provider:argument" syntax must be used. You can for example use | |
| <module>mod_journald</module> or <module>mod_syslog</module> | |
| as a provider: | |
| <highlight language="config"> | |
| # CustomLog logging to journald | |
| CustomLog "journald" "%h %l %u %t \"%r\" %>s %b" | |
| # CustomLog logging to syslog with "user" facility | |
| CustomLog "syslog:user" "%h %l %u %t \"%r\" %>s %b" | |
| </highlight> | |
| </dd> | |
| </dl> | |
| <p>The second argument specifies what will be written to the | |
| log file. It can specify either a <var>nickname</var> defined by | |
| a previous <directive module="mod_log_config">LogFormat</directive> | |
| directive, or it can be an explicit <var>format</var> string as | |
| described in the <a href="#formats">log formats</a> section.</p> | |
| <p>For example, the following two sets of directives have | |
| exactly the same effect:</p> | |
| <highlight language="config"> | |
| # CustomLog with format nickname | |
| LogFormat "%h %l %u %t \"%r\" %>s %b" common | |
| CustomLog "logs/access_log" common | |
| # CustomLog with explicit format string | |
| CustomLog "logs/access_log" "%h %l %u %t \"%r\" %>s %b" | |
| </highlight> | |
| <p>The third argument is optional and controls whether or | |
| not to log a particular request. The condition can be the | |
| presence or absence (in the case of a '<code>env=!<var>name</var></code>' | |
| clause) of a particular variable in the server | |
| <a href="../env.html">environment</a>. Alternatively, the condition | |
| can be expressed as arbitrary boolean <a href="../expr.html" | |
| >expression</a>. If the condition is not satisfied, the request | |
| will not be logged. References to HTTP headers in the expression | |
| will not cause the header names to be added to the Vary header.</p> | |
| <p>Environment variables can be set on a per-request | |
| basis using the <module>mod_setenvif</module> | |
| and/or <module>mod_rewrite</module> modules. For | |
| example, if you want to record requests for all GIF | |
| images on your server in a separate logfile but not in your main | |
| log, you can use:</p> | |
| <highlight language="config"> | |
| SetEnvIf Request_URI \.gif$ gif-image | |
| CustomLog "gif-requests.log" common env=gif-image | |
| CustomLog "nongif-requests.log" common env=!gif-image | |
| </highlight> | |
| <p>Or, to reproduce the behavior of the old RefererIgnore | |
| directive, you might use the following:</p> | |
| <highlight language="config"> | |
| SetEnvIf Referer example\.com localreferer | |
| CustomLog "referer.log" referer env=!localreferer | |
| </highlight> | |
| </usage> | |
| </directivesynopsis> | |
| <directivesynopsis> | |
| <name>LogFormat</name> | |
| <description>Describes a format for use in a log file</description> | |
| <syntax>LogFormat <var>format</var>|<var>nickname</var> | |
| [<var>nickname</var>]</syntax> | |
| <default>LogFormat "%h %l %u %t \"%r\" %>s %b"</default> | |
| <contextlist><context>server config</context><context>virtual host</context> | |
| </contextlist> | |
| <usage> | |
| <p>This directive specifies the format of the access log | |
| file.</p> | |
| <p>The <directive>LogFormat</directive> directive can take one of two | |
| forms. In the first form, where only one argument is specified, | |
| this directive sets the log format which will be used by logs | |
| specified in subsequent <directive>TransferLog</directive> | |
| directives. The single argument can specify an explicit | |
| <var>format</var> as discussed in the <a href="#formats">custom log | |
| formats</a> section above. Alternatively, it can use a | |
| <var>nickname</var> to refer to a log format defined in a | |
| previous <directive>LogFormat</directive> directive as described | |
| below.</p> | |
| <p>The second form of the <directive>LogFormat</directive> | |
| directive associates an explicit <var>format</var> with a | |
| <var>nickname</var>. This <var>nickname</var> can then be used in | |
| subsequent <directive>LogFormat</directive> or | |
| <directive module="mod_log_config">CustomLog</directive> directives | |
| rather than repeating the entire format string. A | |
| <directive>LogFormat</directive> directive that defines a nickname | |
| <strong>does nothing else</strong> -- that is, it <em>only</em> | |
| defines the nickname, it doesn't actually apply the format and make | |
| it the default. Therefore, it will not affect subsequent | |
| <directive module="mod_log_config">TransferLog</directive> directives. | |
| In addition, <directive>LogFormat</directive> cannot use one nickname | |
| to define another nickname. Note that the nickname should not contain | |
| percent signs (<code>%</code>).</p> | |
| <example><title>Example</title> | |
| <highlight language="config"> | |
| LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common | |
| </highlight> | |
| </example> | |
| </usage> | |
| </directivesynopsis> | |
| <directivesynopsis> | |
| <name>TransferLog</name> | |
| <description>Specify location of a log file</description> | |
| <syntax>TransferLog <var>file</var>|<var>pipe</var></syntax> | |
| <contextlist><context>server config</context><context>virtual host</context> | |
| </contextlist> | |
| <usage> | |
| <p>This directive has exactly the same arguments and effect as | |
| the <directive module="mod_log_config">CustomLog</directive> | |
| directive, with the exception that it does not allow the log format | |
| to be specified explicitly or for conditional logging of requests. | |
| Instead, the log format is determined by the most recently specified | |
| <directive module="mod_log_config">LogFormat</directive> directive | |
| which does not define a nickname. Common Log Format is used if no | |
| other format has been specified.</p> | |
| <example><title>Example</title> | |
| <highlight language="config"> | |
| LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" | |
| TransferLog "logs/access_log" | |
| </highlight> | |
| </example> | |
| </usage> | |
| </directivesynopsis> | |
| <directivesynopsis> | |
| <name>GlobalLog</name> | |
| <description>Sets filename and format of log file</description> | |
| <syntax>GlobalLog <var>file</var>|<var>pipe</var>|<var>provider</var> | |
| <var>format</var>|<var>nickname</var> | |
| [env=[!]<var>environment-variable</var>| | |
| expr=<var>expression</var>]</syntax> | |
| <contextlist><context>server config</context> | |
| </contextlist> | |
| <compatibility>Available in Apache HTTP Server 2.4.19 and later</compatibility> | |
| <usage> | |
| <p>The <directive>GlobalLog</directive> directive defines a log shared | |
| by the main server configuration and all defined virtual hosts.</p> | |
| <p>The <directive>GlobalLog</directive> directive is identical to | |
| the <directive>CustomLog</directive> directive, apart from the following | |
| differences:</p> | |
| <ul> | |
| <li><directive>GlobalLog</directive> is not valid in virtual host | |
| context.</li> | |
| <li><directive>GlobalLog</directive> is used by virtual hosts that | |
| define their own <directive>CustomLog</directive>, unlike a | |
| globally specified <directive>CustomLog</directive>.</li> | |
| </ul> | |
| </usage> | |
| </directivesynopsis> | |
| </modulesynopsis> |