| <?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.</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 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.</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 <code>%r</code>, | 
 |       <code>%i</code> and <code>%o</code> 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> | 
 |  | 
 |       <p>Since httpd 2.0, unlike 1.3, 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> |