Source: http://httpd.apache.org/docs/2.2/en/mod/core.html
Timestamp: 2019-04-24 19:55:57+00:00

Document:
The httpready accept filter buffers entire HTTP requests at the kernel level. Once an entire request is received, the kernel then sends it to the server. See the accf_http(9) man page for more details. Since HTTPS requests are encrypted, only the accf_data(9) filter is used.
When the server finds an .htaccess file (as specified by AccessFileName), it needs to know which directives declared in that file can override earlier configuration directives.
Allow use of the directives controlling specific directory features (Options and XBitHack). An equal sign may be given followed by a comma-separated list, without spaces, of options that may be set using the Options command.
In the example above, all directives that are neither in the group AuthConfig nor Indexes cause an internal server error.
Note that when you specify an ErrorDocument that points to a remote URL (ie. anything with a method such as http in front of it), Apache will send a redirect to the client to tell it where to find the document, even if the document ends up being on the same server. This has several implications, the most important being that the client will not receive the original error status code, but instead will receive a redirect status code. This in turn can confuse web robots and other clients which try to determine if a URL is valid using the status code. In addition, if you use a remote URL in an ErrorDocument 401, the client will not know to prompt the user for a password since it will not receive the 401 status code. Therefore, if you use an ErrorDocument 401 directive, then it must refer to a local document.
An ETag is not generated for responses parsed by mod_include since the response entity can change without a change of the INode, MTime, or Size of the static file with embedded SSI directives.
This directive changes the rules applied to the HTTP Request Line (RFC 7230 §3.1.1) and the HTTP Request Header Fields (RFC 7230 §3.2), which are now applied by default or using the Strict option. Due to legacy modules, applications or custom user-agents which must be deperecated the Unsafe option has been added to revert to the legacy behaviors. These rules are applied prior to request processing, so must be configured at the global or default (first) matching virtual host section, by IP/port interface (and not by name) to be honored.
Prior to the introduction of this directive, the Apache HTTP Server request message parsers were tolerant of a number of forms of input which did not conform to the protocol. RFC 7230 §9.4 Request Splitting and §9.5 Response Smuggling call out only two of the potential risks of accepting non-conformant request messages, while RFC 7230 §3.5 "Message Parsing Robustness" identify the risks of accepting obscure whitespace and request message formatting. As of the introduction of this directive, all grammer rules of the specification are enforced in the default Strict operating mode, and the strict whitespace suggested by section 3.5 is enforced and cannot be relaxed.
Users are strongly cautioned against toggling the Unsafe mode of operation, particularly on outward-facing, publicly accessible server deployments. If an interface is required for faulty monitoring or other custom service consumers running on an intranet, users should toggle the Unsafe option only on a specific virtual host configured to service their internal private network.
Reviewing the messages logged to the ErrorLog, configured with LogLevel debug level, can help identify such faulty requests along with their origin. Users should pay particular attention to the 400 responses in the access log for invalid requests which were unexpectedly rejected.
RFC 7231 §4.1 "Request Methods" "Overview" requires that origin servers shall respond with an error when an unsupported method is encountered in the request line. This already happens when the LenientMethods option is used, but administrators may wish to toggle the RegisteredMethods option and register any non-standard methods using the RegisterHttpMethod directive, particularly if the Unsafe option has been toggled. The RegisteredMethods option should not be toggled for forward proxy hosts, as the methods supported by the origin servers are unknown to the proxy server.
RFC 2616 §19.6 "Compatibility With Previous Versions" had encouraged HTTP servers to support legacy HTTP/0.9 requests. RFC 7230 superceeds this with "The expectation to support HTTP/0.9 requests has been removed" and offers additional comments in RFC 7230 Appendix A. The Require1.0 option allows the user to remove support of the default Allow0.9 option's behavior.
When a client uses a Keep-Alive connection, it will be counted as a single "request" for the MaxRequestsPerChild directive, regardless of how many requests are sent using the connection.
The method names listed can be one or more of: GET, POST, PUT, DELETE, CONNECT, OPTIONS, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, and UNLOCK. The method name is case-sensitive. If GET is used, it will also restrict HEAD requests. The TRACE method cannot be limited.
The directive stores two different limits, which are evaluated on per-request basis. The first number is the maximum number of internal redirects that may follow each other. The second number determines how deeply subrequests may be nested. If you specify only one number, it will be assigned to both limits.
When logging to a regular file, messages of the level notice cannot be suppressed and thus are always logged. However, this doesn't apply when logging is done using syslog.
This directive controls whether HTTP trailers are copied into the internal representation of HTTP headers. This merging occurs when the request body has been completely consumed, long after most header processing would have a chance to examine or modify request headers.
This option is provided for compatibility with releases prior to 2.2.28, where trailers were always merged.
If a URL which maps to a directory is requested and there is no DirectoryIndex (e.g., index.html) in that directory, then mod_autoindex will return a formatted listing of the directory.
Mixing Options with a + or - with those without is not valid syntax and is likely to cause unexpected results.
This directive specifies the protocol used for a specific listening socket. The protocol is used to determine which module should handle a request and to apply protocol specific optimizations with the AcceptFilter directive.
You only need to set the protocol if you are running on non-standard ports; otherwise, http is assumed for port 80 and https for port 443.
HTTP Methods that are not conforming to the relvant RFCs are normally rejected by request processing in Apache HTTPD. To avoid this, modules can register non-standard HTTP methods they support. The RegisterHttpMethod allows to register such methods manually. This can be useful for if such methods are forwared for external processing, e.g. to a CGI script.
Multiple Require directives do operate as logical "OR", but some underlying authentication modules may require an explicit configuration to let authentication be chained to others. This is typically the case with mod_authnz_ldap, which exports the AuthzLDAPAuthoritative in that intent.
Takes 1 or 2 parameters. The first parameter sets the soft resource limit for all processes and the second parameter sets the maximum resource limit. Either parameter can be a number, or max to indicate to the server that the limit should be set to the maximum allowed by the operating system configuration. Raising the maximum resource limit requires that the server is running as root or in the initial startup phase.
This applies to processes forked from Apache children servicing requests, not the Apache children themselves. This includes CGI scripts and SSI exec commands, but not any processes forked from the Apache parent, such as piped logs.
Takes 1 or 2 parameters. The first parameter sets the soft resource limit for all processes, and the second parameter sets the maximum resource limit. Either parameter can be a number, or max to indicate to the server that the limit should be set to the maximum allowed by the operating system configuration. Raising the maximum resource limit requires that the server is running as root or in the initial startup phase.
This setting applies to the entire server and cannot be enabled or disabled on a virtualhost-by-virtualhost basis.
An example where this may be useful is on an intranet server where you have users connecting to the machine using short names such as www. You'll notice that if the users type a shortname and a URL which is a directory, such as http://www/splat, without the trailing slash, then Apache will redirect them to http://www.domain.com/splat/. If you have authentication enabled, this will cause the user to have to authenticate twice (once for www and once again for www.domain.com -- see the FAQ on this subject for more information). But if UseCanonicalName is set Off, then Apache will redirect to http://www/splat/.
There is a third option, UseCanonicalName DNS, which is intended for use with mass IP-based virtual hosting to support ancient clients that do not provide a Host: header. With this option, Apache does a reverse DNS lookup on the server IP address that the client connected to in order to work out self-referential URLs.
If CGIs make assumptions about the values of SERVER_NAME, they may be broken by this option. The client is essentially free to give whatever value they want as a hostname. But if the CGI is only using SERVER_NAME to construct self-referential URLs, then it should be just fine.
In many situations Apache must construct a self-referential URL -- that is, a URL that refers back to the same server. With UseCanonicalPhysicalPort On, Apache will, when constructing the canonical port for the server to honor the UseCanonicalName directive, provide the actual physical port number being used by this request as a potential port. With UseCanonicalPhysicalPort Off, Apache will not ever use the actual physical port number, instead relying on all configured information to construct a valid port number.
Each Virtual Host must correspond to a different IP address, different port number, or a different host name for the server, in the former case the server machine must be configured to accept IP packets for multiple addresses. (If the machine does not have multiple network interfaces, then this can be accomplished with the ifconfig alias command -- if your OS supports it).

References: §3
 §3
 §9
 §9
 §3
 §4
 §19