| <?xml version='1.0' encoding='UTF-8' ?> |
| <!DOCTYPE manualpage SYSTEM "../style/manualpage.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. |
| --> |
| |
| <manualpage metafile="new_api_2_4.xml.meta"> |
| |
| <title>API Changes in Apache HTTP Server 2.4 since 2.2</title> |
| |
| <summary> |
| <p>This document describes changes to the Apache HTTPD API from |
| version 2.2 to 2.4, that may be of interest to module/application |
| developers and core hacks. As of the first GA release of the |
| 2.4 branch API compatibility is preserved for the life of the |
| 2.4 branch. (The |
| <a href="http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/VERSIONING">VERSIONING</a> |
| description for the 2.4 release provides more information about API |
| compatibility.)</p> |
| |
| <p>API changes fall into two categories: APIs that are altogether new, |
| and existing APIs that are expanded or changed. The latter are |
| further divided into those where all changes are backwards-compatible |
| (so existing modules can ignore them), and those that might |
| require attention by maintainers. As with the transition from |
| HTTPD 2.0 to 2.2, existing modules and applications will require |
| recompiling and may call for some attention, but most should not |
| require any substantial updating (although some may be able to |
| take advantage of API changes to offer significant improvements).</p> |
| <p>For the purpose of this document, the API is split according |
| to the public header files. These headers are themselves the |
| reference documentation, and can be used to generate a browsable |
| HTML reference with <code>make docs</code>.</p> |
| </summary> |
| |
| <section id="api_changes"> |
| <title>Changed APIs</title> |
| |
| <section id="ap_expr"> |
| <title>ap_expr (NEW!)</title> |
| <p>Introduces a new API to parse and evaluate boolean and algebraic |
| expressions, including provision for a standard syntax and |
| customised variants.</p> |
| </section> |
| |
| <section id="ap_listen"> |
| <title>ap_listen (changed; backwards-compatible)</title> |
| <p>Introduces a new API to enable httpd child processes to serve |
| different purposes.</p> |
| </section> |
| |
| <section id="ap_mpm"> |
| <title>ap_mpm (changed)</title> |
| <p><code>ap_mpm_run</code> is replaced by a new <code>mpm</code> hook. |
| Also <code>ap_graceful_stop_signalled</code> is lost, and |
| <code>ap_mpm_register_timed_callback</code> is new.</p> |
| </section> |
| |
| <section id="ap_regex"> |
| <title>ap_regex (changed)</title> |
| <p>In addition to the existing regexp wrapper, a new higher-level API |
| <code>ap_rxplus</code> is now provided. This provides the capability to |
| compile Perl-style expressions like <code>s/regexp/replacement/flags</code> |
| and to execute them against arbitrary strings. Support for regexp |
| backreferences is also added.</p> |
| </section> |
| |
| <section id="ap_slotmem"> |
| <title>ap_slotmem (NEW!)</title> |
| <p>Introduces an API for modules to allocate and manage memory slots, |
| most commonly for shared memory.</p> |
| </section> |
| |
| <section id="ap_socache"> |
| <title>ap_socache (NEW!)</title> |
| <p>API to manage a shared object cache.</p> |
| </section> |
| |
| <section id="heartbeat"> |
| <title>heartbeat (NEW!)</title> |
| <p>common structures for heartbeat modules</p> |
| </section> |
| |
| <section id="ap_parse_htaccess"> |
| <title>ap_parse_htaccess (changed)</title> |
| <p>The function signature for <code>ap_parse_htaccess</code> has been |
| changed. A <code>apr_table_t</code> of individual directives allowed |
| for override must now be passed (override remains).</p> |
| </section> |
| |
| <section id="http_config"> |
| <title>http_config (changed)</title> |
| <ul> |
| <li>Introduces per-module, per-directory loglevels, including macro wrappers.</li> |
| <li>New <code>AP_DECLARE_MODULE</code> macro to declare all modules.</li> |
| <li>New <code>APLOG_USE_MODULE</code> macro necessary for per-module loglevels in |
| multi-file modules.</li> |
| <li>New API to retain data across module unload/load</li> |
| <li>New <code>check_config</code> hook</li> |
| <li>New <code>ap_process_fnmatch_configs()</code> function to process wildcards</li> |
| <li>Change <code>ap_configfile_t</code>, <code>ap_cfg_getline()</code>, |
| <code>ap_cfg_getc()</code> to return error codes, and add |
| <code>ap_pcfg_strerror()</code> for retrieving an error description.</li> |
| <li>Any config directive permitted in ACCESS_CONF context must now |
| correctly handle being called from an .htaccess file via the new |
| <directive module="core">AllowOverrideList</directive> directive. |
| ap_check_cmd_context() accepts a new flag NOT_IN_HTACCESS to detect |
| this case.</li> |
| </ul> |
| </section> |
| |
| <section id="http_core"> |
| <title>http_core (changed)</title> |
| <ul> |
| <li>REMOVED <code>ap_default_type</code>, <code>ap_requires</code>, all |
| 2.2 authnz API</li> |
| <li>Introduces Optional Functions for logio and authnz</li> |
| <li>New function <code>ap_get_server_name_for_url</code> to support IPv6 |
| literals.</li> |
| <li>New function <code>ap_register_errorlog_handler</code> to register error log |
| format string handlers.</li> |
| <li>Arguments of <code>error_log</code> hook have changed. Declaration has moved to |
| <code>http_core.h</code>.</li> |
| <li>New function <code>ap_state_query</code> to determine if the server is in the |
| initial configuration preflight phase or not. This is both easier to |
| use and more correct than the old method of creating a pool userdata |
| entry in the process pool.</li> |
| <li>New function <code>ap_get_conn_socket</code> to get the socket descriptor for a |
| connection. This should be used instead of accessing the core |
| connection config directly.</li> |
| </ul> |
| </section> |
| |
| <section id="httpd"> |
| <title>httpd (changed)</title> |
| <ul> |
| <li>Introduce per-directory, per-module loglevel</li> |
| <li>New loglevels <code>APLOG_TRACEn</code></li> |
| <li>Introduce errorlog ids for requests and connections</li> |
| <li>Support for mod_request kept_body</li> |
| <li>Support buffering filter data for async requests</li> |
| <li>New <code>CONN_STATE</code> values</li> |
| <li>Function changes: <code>ap_escape_html</code> updated; |
| <code>ap_unescape_all</code>, <code>ap_escape_path_segment_buffer</code></li> |
| <li>Modules that load other modules later than the <code>EXEC_ON_READ</code> config |
| reading stage need to call <code>ap_reserve_module_slots()</code> or |
| <code>ap_reserve_module_slots_directive()</code> in their |
| <code>pre_config hook</code>.</li> |
| <li>The useragent IP address per request can now be tracked |
| independently of the client IP address of the connection, for |
| support of deployments with load balancers.</li> |
| </ul> |
| </section> |
| |
| <section id="http_log"> |
| <title>http_log (changed)</title> |
| <ul> |
| <li>Introduce per-directory, per-module loglevel</li> |
| <li>New loglevels <code>APLOG_TRACEn</code></li> |
| <li><code>ap_log_*error</code> become macro wrappers (backwards-compatible if |
| <code>APLOG_MARK</code> macro is used, except that is no longer possible to |
| use <code>#ifdef</code> inside the argument list)</li> |
| <li>piped logging revamped</li> |
| <li><code>module_index</code> added to error_log hook</li> |
| <li>new function: <code>ap_log_command_line</code></li> |
| </ul> |
| </section> |
| |
| <section id="http_request"> |
| <title>http_request (changed)</title> |
| <ul> |
| <li>New auth_internal API and auth_provider API</li> |
| <li>New <code>EOR</code> bucket type</li> |
| <li>New function <code>ap_process_async_request</code></li> |
| <li>New flags <code>AP_AUTH_INTERNAL_PER_CONF</code> and |
| <code>AP_AUTH_INTERNAL_PER_URI</code></li> |
| <li>New <code>access_checker_ex</code> hook to apply additional access control |
| and/or bypass authentication.</li> |
| <li>New functions <code>ap_hook_check_access_ex</code>, |
| <code>ap_hook_check_access</code>, <code>ap_hook_check_authn</code>, |
| <code>ap_hook_check_authz</code> which accept |
| <code>AP_AUTH_INTERNAL_PER_*</code> flags</li> |
| <li>DEPRECATED direct use of <code>ap_hook_access_checker</code>, |
| <code>access_checker_ex</code>, <code>ap_hook_check_user_id</code>, |
| <code>ap_hook_auth_checker</code></li> |
| </ul> |
| <p>When possible, registering all access control hooks (including |
| authentication and authorization hooks) using <code>AP_AUTH_INTERNAL_PER_CONF</code> |
| is recommended. If all modules' access control hooks are registered |
| with this flag, then whenever the server handles an internal |
| sub-request that matches the same set of access control configuration |
| directives as the initial request (which is the common case), it can |
| avoid invoking the access control hooks another time.</p> |
| <p>If your module requires the old behavior and must perform access |
| control checks on every sub-request with a different URI from the |
| initial request, even if that URI matches the same set of access |
| control configuration directives, then use |
| <code>AP_AUTH_INTERNAL_PER_URI</code>.</p> |
| </section> |
| |
| <section id="mod_auth"> |
| <title>mod_auth (NEW!)</title> |
| <p>Introduces the new provider framework for authn and authz</p> |
| </section> |
| |
| <section id="mod_cache"> |
| <title>mod_cache (changed)</title> |
| <p>Introduces a <code>commit_entity()</code> function to the cache provider |
| interface, allowing atomic writes to cache. Add a <code>cache_status()</code> |
| hook to report the cache decision. All private structures and functions were |
| removed.</p> |
| </section> |
| |
| <section id="mod_core"> |
| <title>mod_core (NEW!)</title> |
| <p>This introduces low-level APIs to send arbitrary headers, |
| and exposes functions to handle HTTP OPTIONS and TRACE.</p> |
| </section> |
| |
| <section id="mod_cache_disk"> |
| <title>mod_cache_disk (changed)</title> |
| <p>Changes the disk format of the disk cache to support atomic cache |
| updates without locking. The device/inode pair of the body file is |
| embedded in the header file, allowing confirmation that the header |
| and body belong to one another.</p> |
| </section> |
| |
| <section id="mod_disk_cache"> |
| <title>mod_disk_cache (renamed)</title> |
| <p>The mod_disk_cache module has been renamed to mod_cache_disk in |
| order to be consistent with the naming of other modules within the |
| server.</p> |
| </section> |
| |
| <section id="mod_request"> |
| <title>mod_request (NEW!)</title> |
| <p>The API for <module>mod_request</module>, to make input data |
| available to multiple application/handler modules where required, |
| and to parse HTML form data.</p> |
| </section> |
| |
| <section id="mpm_common"> |
| <title>mpm_common (changed)</title> |
| <ul> |
| <li>REMOVES: <code>accept</code>, <code>lockfile</code>, <code>lock_mech</code>, |
| <code>set_scoreboard</code> (locking uses the new ap_mutex API)</li> |
| <li>NEW API to drop privileges (delegates this platform-dependent |
| function to modules)</li> |
| <li>NEW Hooks: <code>mpm_query</code>, <code>timed_callback</code>, and |
| <code>get_name</code></li> |
| <li>CHANGED interfaces: <code>monitor</code> hook, |
| <code>ap_reclaim_child_processes</code>, |
| <code>ap_relieve_child_processes</code></li> |
| </ul> |
| </section> |
| |
| <section id="scoreboard"> |
| <title>scoreboard (changed)</title> |
| <p><code>ap_get_scoreboard_worker</code> is made non-backwards-compatible |
| as an alternative version is introduced. Additional proxy_balancer |
| support. Child status stuff revamped.</p> |
| </section> |
| |
| <section id="util_cookies"> |
| <title>util_cookies (NEW!)</title> |
| <p>Introduces a new API for managing HTTP Cookies.</p> |
| </section> |
| |
| <section id="util_ldap"> |
| <title>util_ldap (changed)</title> |
| <p><em>no description available</em></p> |
| </section> |
| |
| <section id="util_mutex"> |
| <title>util_mutex (NEW!)</title> |
| <p>A wrapper for APR proc and global mutexes in httpd, providing |
| common configuration for the underlying mechanism and location |
| of lock files.</p> |
| </section> |
| |
| <section id="util_script"> |
| <title>util_script (changed)</title> |
| <p>NEW: <code>ap_args_to_table</code></p> |
| </section> |
| |
| <section id="util_time"> |
| <title>util_time (changed)</title> |
| <p>NEW: <code>ap_recent_ctime_ex</code></p> |
| </section> |
| |
| </section> |
| |
| <section id="upgrading"> |
| <title>Specific information on upgrading modules from 2.2</title> |
| |
| <section id="upgrading_logging"> |
| <title>Logging</title> |
| <p>In order to take advantage of per-module loglevel configuration, any |
| source file that calls the <code>ap_log_*</code> functions should declare |
| which module it belongs to. If the module's module_struct is called |
| <code>foo_module</code>, the following code can be used to remain |
| backward compatible with HTTPD 2.0 and 2.2:</p> |
| <example> |
| #include <http_log.h><br/> |
| <br/> |
| #ifdef APLOG_USE_MODULE<br/> |
| APLOG_USE_MODULE(foo);<br/> |
| #endif |
| </example> |
| <p>Note: This is absolutely required for C++-language modules. It |
| can be skipped for C-language modules, though that breaks |
| module-specific log level support for files without it.</p> |
| <p>The number of parameters of the <code>ap_log_*</code> functions and the |
| definition of <code>APLOG_MARK</code> has changed. Normally, the change |
| is completely transparent. However, changes are required if a |
| module uses <code>APLOG_MARK</code> as a parameter to its own functions |
| or if a module calls <code>ap_log_*</code> without passing |
| <code>APLOG_MARK</code>. A module which uses wrappers |
| around <code>ap_log_*</code> typically uses both of these constructs.</p> |
| |
| <p>The easiest way to change code which passes <code>APLOG_MARK</code> to |
| its own functions is to define and use a different macro that expands to |
| the parameters required by those functions, as <code>APLOG_MARK</code> |
| should only be used when calling <code>ap_log_*</code> |
| directly. In this way, the code will remain compatible with HTTPD 2.0 |
| and 2.2.</p> |
| |
| <p>Code which calls <code>ap_log_*</code> without passing |
| <code>APLOG_MARK</code> will necessarily differ between 2.4 and earlier |
| releases, as 2.4 requires a new third argument, |
| <code>APLOG_MODULE_INDEX</code>.</p> |
| |
| <example> |
| /* code for httpd 2.0/2.2 */<br /> |
| ap_log_perror(file, line, APLOG_ERR, 0, p, "Failed to allocate dynamic lock structure");<br /> |
| <br /> |
| /* code for httpd 2.4 */<br /> |
| ap_log_perror(file, line, APLOG_MODULE_INDEX, APLOG_ERR, 0, p, "Failed to allocate dynamic lock structure");<br /> |
| <br /> |
| </example> |
| |
| <p><code>ap_log_*error</code> are now implemented as macros. This means |
| that it is no longer possible to use <code>#ifdef</code> inside the |
| argument list of <code>ap_log_*error</code>, as this would cause |
| undefined behavor according to C99.</p> |
| |
| <p>A <code>server_rec</code> pointer must be passed to |
| <code>ap_log_error()</code> when called after startup. This |
| was always appropriate, but there are even more limitations with |
| a <code>NULL</code> <code>server_rec</code> in 2.4 than in |
| previous releases. Beginning with 2.3.12, the global variable |
| <code>ap_server_conf</code> can always be used as |
| the <code>server_rec</code> parameter, as it will be |
| <code>NULL</code> only when it is valid to pass <code>NULL</code> |
| to <code>ap_log_error()</code>. <code>ap_server_conf</code> |
| should be used only when a more appropriate <code>server_rec</code> |
| is not available.</p> |
| |
| <p>Consider the following changes to take advantage of the new |
| <code>APLOG_TRACE1..8</code> log levels:</p> |
| <ul> |
| <li>Check current use of <code>APLOG_DEBUG</code> and |
| consider if one of the <code>APLOG_TRACEn</code> levels is |
| more appropriate.</li> |
| <li>If your module currently has a mechanism for configuring |
| the amount of debug logging which is performed, consider |
| eliminating that mechanism and relying on the use of |
| different <code>APLOG_TRACEn</code> levels. If expensive |
| trace processing needs to be bypassed depending on the |
| configured log level, use the <code>APLOGtrace<em>n</em></code> |
| and <code>APLOGrtrace<em>n</em></code> macros to first check |
| if tracing is enabled.</li> |
| </ul> |
| |
| <p>Modules sometimes add process id and/or thread id to their log |
| messages. These ids are now logged by default, so it may not |
| be necessary for the module to log them explicitly. (Users may |
| remove them from the error log format, but they can be |
| instructed to add it back if necessary for problem diagnosis.)</p> |
| </section> |
| |
| <section id="upgrading_byfunction"> |
| <title>If your module uses these existing APIs...</title> |
| |
| <dl> |
| <dt><code>ap_default_type()</code></dt> |
| <dd>This is no longer available; Content-Type must be configured |
| explicitly or added by the application.</dd> |
| |
| <dt><code>ap_get_server_name()</code></dt> |
| <dd>If the returned server name is used in a URL, |
| use <code>ap_get_server_name_for_url()</code> instead. This new |
| function handles the odd case where the server name is an IPv6 |
| literal address.</dd> |
| |
| <dt><code>ap_get_server_version()</code></dt> |
| <dd>For logging purposes, where detailed information is |
| appropriate, use <code>ap_get_server_description()</code>. |
| When generating output, where the amount of information |
| should be configurable by ServerTokens, use |
| <code>ap_get_server_banner()</code>.</dd> |
| |
| <dt><code>ap_graceful_stop_signalled()</code></dt> |
| <dd>Replace with a call |
| to <code>ap_mpm_query(AP_MPMQ_MPM_STATE)</code> and checking for |
| state <code>AP_MPMQ_STOPPING</code>.</dd> |
| |
| <dt><code>ap_max_daemons_limit</code>, <code>ap_my_generation</code>, |
| and <code>ap_threads_per_child</code></dt> |
| <dd>Use <code>ap_mpm_query()</code> query codes |
| <code>AP_MPMQ_MAX_DAEMON_USED</code>, <code>AP_MPMQ_GENERATION</code>, |
| and <code>AP_MPMQ_MAX_THREADS</code>, respectively.</dd> |
| |
| <dt><code>ap_mpm_query()</code></dt> |
| <dd>Ensure that it is not used until after the register-hooks |
| hook has completed. Otherwise, an MPM built as a DSO |
| would not have had a chance to enable support for this |
| function.</dd> |
| |
| <dt><code>ap_requires()</code></dt> |
| <dd>The core server now provides better infrastructure for handling |
| <directive module="mod_authz_core">Require</directive> configuration. |
| Register an auth provider function for each supported entity using |
| <code>ap_register_auth_provider()</code>. The function will be |
| called as necessary during <directive>Require</directive> |
| processing. (Consult bundled modules for detailed examples.)</dd> |
| |
| <dt><code>ap_server_conf->process->pool</code> |
| userdata</dt> |
| <dd> |
| Optional: |
| <ul> |
| <li>If your module uses this to determine which pass of the |
| startup hooks is being run, |
| use <code>ap_state_query(AP_SQ_MAIN_STATE)</code>.</li> |
| <li>If your module uses this to maintain data across the |
| unloading and reloading of your module, use |
| <code>ap_retained_data_create()</code> and |
| <code>ap_retained_data_get()</code>.</li> |
| </ul> |
| </dd> |
| |
| <dt><code>apr_global_mutex_create()</code>, |
| <code>apr_proc_mutex_create()</code></dt> |
| <dd>Optional: See <code>ap_mutex_register()</code>, |
| <code>ap_global_mutex_create()</code>, and |
| <code>ap_proc_mutex_create()</code>; these allow your |
| mutexes to be configurable with |
| the <directive module="core">Mutex</directive> directive; |
| you can also remove any configuration mechanisms in your |
| module for such mutexes |
| </dd> |
| |
| <dt><code>CORE_PRIVATE</code></dt> |
| <dd>This is now unnecessary and ignored.</dd> |
| |
| <dt><code>dav_new_error()</code> |
| and <code>dav_new_error_tag()</code></dt> |
| <dd>Previously, these assumed that <code>errno</code> contained |
| information describing the failure. Now, |
| an <code>apr_status_t</code> parameter must be provided. Pass |
| 0/APR_SUCCESS if there is no such error information, or a valid |
| <code>apr_status_t</code> value otherwise.</dd> |
| |
| <dt><code>mpm_default.h</code>, <code>DEFAULT_LOCKFILE</code>, |
| <code>DEFAULT_THREAD_LIMIT</code>, <code>DEFAULT_PIDLOG</code>, |
| etc.</dt> |
| <dd>The header file and most of the default configuration |
| values set in it are no longer visible to modules. (Most can |
| still be overridden at build time.) <code>DEFAULT_PIDLOG</code> |
| and <code>DEFAULT_REL_RUNTIMEDIR</code> are now universally |
| available via <code>ap_config.h</code>.</dd> |
| |
| <dt><code>unixd_config</code></dt> |
| <dd>This has been renamed to ap_unixd_config.</dd> |
| |
| <dt><code>unixd_setup_child()</code></dt> |
| <dd>This has been renamed to ap_unixd_setup_child(), but most callers |
| should call the added ap_run_drop_privileges() hook.</dd> |
| |
| <dt><code>conn_rec->remote_ip</code> and |
| <code>conn_rec->remote_addr</code></dt> |
| <dd>These fields have been renamed in order to distinguish between |
| the client IP address of the connection and the useragent IP address |
| of the request (potentially overridden by a load balancer or proxy). |
| References to either of these fields must be updated with one of the |
| following options, as appropriate for the module: |
| <ul> |
| <li>When you require the IP address of the user agent, which |
| might be connected directly to the server, or might optionally be |
| separated from the server by a transparent load balancer or |
| proxy, use <code>request_rec->useragent_ip</code> and |
| <code>request_rec->useragent_addr</code>.</li> |
| <li>When you require the IP address of the client that is |
| connected directly to the server, which might be the useragent or |
| might be the load balancer or proxy itself, use |
| <code>conn_rec->client_ip</code> and |
| <code>conn_rec->client_addr</code>.</li> |
| </ul> |
| </dd> |
| </dl> |
| </section> |
| |
| <section id="upgrading_byfeature"> |
| <title>If your module interfaces with this feature...</title> |
| <dl> |
| <dt>suEXEC</dt> |
| <dd>Optional: If your module logs an error |
| when <code>ap_unixd_config.suexec_enabled</code> is 0, |
| also log the value of the new |
| field <code>suexec_disabled_reason</code>, which contains an |
| explanation of why it is not available.</dd> |
| |
| <dt>Extended status data in the scoreboard</dt> |
| <dd>In previous releases, <code>ExtendedStatus</code> had to be |
| set to <code>On</code>, which in turn required that |
| mod_status was loaded. In 2.4, just |
| set <code>ap_extended_status</code> to <code>1</code> in a |
| pre-config hook and the extended status data will be |
| available.</dd> |
| </dl> |
| </section> |
| |
| <section id="upgrading_newfeatures"> |
| <title>Does your module...</title> |
| <dl> |
| <dt>Parse query args</dt> |
| <dd>Consider if <code>ap_args_to_table()</code> would be |
| helpful.</dd> |
| |
| <dt>Parse form data...</dt> |
| <dd>Use <code>ap_parse_form_data()</code>.</dd> |
| |
| <dt>Check for request header fields <code>Content-Length</code> |
| and <code>Transfer-Encoding</code> to see if a body was |
| specified</dt> |
| <dd>Use <code>ap_request_has_body()</code>.</dd> |
| |
| <dt>Implement cleanups which clear pointer variables</dt> |
| <dd>Use <code>ap_pool_cleanup_set_null()</code>.</dd> |
| |
| <dt>Create run-time files such as shared memory files, pid files, |
| etc.</dt> |
| <dd>Use <code>ap_runtime_dir_relative()</code> so that the global |
| configuration for the location of such files, either by the |
| <code>DEFAULT_REL_RUNTIMEDIR</code> compile setting or the |
| <directive module="core">DefaultRuntimeDir</directive> directive, |
| will be respected. <em>Apache httpd 2.4.2 and above.</em></dd> |
| |
| </dl> |
| </section> |
| |
| </section> |
| |
| </manualpage> |