</related>
<p>The HTTP protocol follows the <strong>robustness principle</strong>
- as described in <a href="https://datatracker.ietf.org/doc/html/rfc1122">RFC1122</a>,
+ as described in <rfc>1122</rfc>,
which states <strong>"Be liberal in what you accept, and conservative in
what you send"</strong>. As a result of this principle, HTTP clients will
compensate for and recover from incorrect or misconfigured responses, or
<a name="http" id="hhtp">(HTTP)</a></dt>
<dd>The standard transmission protocol used on the World Wide Web. httpd
implements version 1.1 of the protocol, referred to as HTTP/1.1 and
- defined by <a href="https://datatracker.ietf.org/doc/html/rfc2616">RFC 2616</a>.
+ defined by <rfc>2616</rfc>.
</dd>
<dt><a name="https" id="https">HTTPS</a></dt>
in processing the SSL handshake. It was added to SSL starting
with the TLS extensions, RFC 3546. <br />
See: <a href="ssl/ssl_faq.html">the SSL FAQ</a>
- and <a href="https://datatracker.ietf.org/doc/html/rfc3546">RFC 3546</a>
+ and <rfc>3546</rfc>
</dd>
<dt><a name="serversideincludes" id="serversideincludes">Server Side
id="uniformresourceidentifier">Uniform Resource Identifier</a>
<a name="URI" id="URI">(URI)</a></dt>
<dd>A compact string of characters for identifying an abstract or physical
- resource. It is formally defined by <a
- href="https://datatracker.ietf.org/doc/html/rfc2396">RFC 2396</a>. URIs used on the
+ resource. It is formally defined by <rfc>2396</rfc>. URIs used on the
world-wide web are commonly referred to as <glossary
ref="url">URLs</glossary>.
</dd>
<p>When you miss HTTP headers from the environment, make
sure they are formatted according to
- <a href="https://datatracker.ietf.org/doc/html/rfc2616">RFC 2616</a>,
+ <rfc>2616</rfc>,
section 4.2: Header names must start with a letter,
followed only by letters, numbers or hyphen. Any header
violating this rule will be dropped silently.</p>
of HTTP, the semantics. There are still request and responses and headers and all that. So, if
you already know HTTP/1, you know 95% about HTTP/2 as well.</p>
<p>There has been a lot written about HTTP/2 and how it works. The most normative is, of course,
- its <a href="https://datatracker.ietf.org/doc/html/rfc7540">RFC 7540</a>
+ its <rfc>7540</rfc>
(<a href="https://datatracker.ietf.org/doc/html/rfc7540">also available in more readable formatting, YMMV</a>).
So, there you'll find the nuts and bolts.</p>
<p>But, as RFC do, it's not really a good thing to read first. It's better to first understand
<title>Early Hints</title>
<p>An alternative to PUSHing resources is to send <code>Link</code> headers to the
client before the response is even ready. This uses the HTTP feature called "Early Hints" and
- is described in <a href="https://datatracker.ietf.org/doc/html/rfc8297">RFC 8297</a>.</p>
+ is described in <rfc>8297</rfc>.</p>
<p>In order to use this, you need to explicitly enable it on the server via</p>
<highlight language="config">
H2EarlyHints on
basic web server complies with the following IETF recommendations:</p>
<dl>
- <dt><a href="https://datatracker.ietf.org/doc/html/rfc1945">RFC 1945</a>
+ <dt><rfc>1945</rfc>
(Informational)</dt>
<dd>The Hypertext Transfer Protocol (HTTP) is an application-level
collaborative, hypermedia information systems. This documents
HTTP/1.0.</dd>
- <dt><a href="https://datatracker.ietf.org/doc/html/rfc2616">RFC 2616</a>
+ <dt><rfc>2616</rfc>
(Standards Track)</dt>
<dd>The Hypertext Transfer Protocol (HTTP) is an
application-level protocol for distributed, collaborative,
hypermedia information systems. This documents HTTP/1.1.</dd>
- <dt><a href="https://datatracker.ietf.org/doc/html/rfc2396">RFC 2396</a>
+ <dt><rfc>2396</rfc>
(Standards Track)</dt>
<dd>A Uniform Resource Identifier (URI) is a compact string of
characters for identifying an abstract or physical resource.</dd>
- <dt><a href="https://datatracker.ietf.org/doc/html/rfc4346">RFC 4346</a>
+ <dt><rfc>4346</rfc>
(Standards Track)</dt>
<dd>The TLS protocol provides communications security over the
the following IETF and W3C recommendations:</p>
<dl>
- <dt><a href="https://datatracker.ietf.org/doc/html/rfc2854">RFC 2854</a>
+ <dt><rfc>2854</rfc>
(Informational)</dt>
<dd>This document summarizes the history of HTML development,
follows the following IETF recommendations:</p>
<dl>
- <dt><a href="https://datatracker.ietf.org/doc/html/rfc2617">RFC 2617</a>
+ <dt><rfc>2617</rfc>
(Standards Track)</dt>
<dd>"HTTP/1.0", includes the specification for a Basic
<dt><a href="http://www.rfc-editor.org/rfc/bcp/bcp47.txt">BCP 47</a>
(Best Current Practice),
- <a href="https://datatracker.ietf.org/doc/html/rfc3066">RFC 3066</a></dt>
+ <rfc>3066</rfc></dt>
<dd>This document describes a language tag for use in cases where
it is desired to indicate the language used in an information
object, how to register values for use in this language tag,
and a construct for matching such language tags.</dd>
- <dt><a href="https://datatracker.ietf.org/doc/html/rfc3282">RFC 3282</a>
+ <dt><rfc>3282</rfc>
(Standards Track)</dt>
<dd>This document defines a "Content-language:" header, for use in
<summary>
<p>This module implements HTTP Digest Authentication
- (<a href="https://datatracker.ietf.org/doc/html/rfc2617">RFC2617</a>), and
+ (<rfc>2617</rfc>), and
provides an alternative to <module>mod_auth_basic</module> where the
password is not transmitted as cleartext. However, this does
<strong>not</strong> lead to a significant security advantage over
<p>This module provides token parsing front-ends such as
<module>mod_auth_bearer</module> the ability to authenticate users
by verifying a JWT token as described in
- <a href="https://datatracker.ietf.org/doc/html/rfc7519">RFC 7519</a>.</p>
+ <rfc>7519</rfc>.</p>
<p>A JWT token is read from the <var>Authorization</var> header
with an <var>auth-scheme</var> of <var>Bearer</var>.</p>
wish to limit access by client host name, address or environment
variable.</note>
- <p><module>mod_cache</module> implements an <a
- href="https://datatracker.ietf.org/doc/html/rfc2616">RFC 2616</a> compliant
+ <p><module>mod_cache</module> implements an <rfc>2616</rfc> compliant
<strong>HTTP content caching filter</strong>, with support for the caching
of content negotiated responses containing the Vary header.</p>
source.</p>
<p>To modify <code>Cache-Control</code> directives other than
- <code>max-age</code> (see <a
- href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.9">RFC
- 2616 section 14.9</a>), you can use the <directive
+ <code>max-age</code> (see <rfc section="14.9">2616</rfc>,
+ section 14.9), you can use the <directive
module="mod_headers">Header</directive> directive.</p>
<p> When the <code>Expires</code> header is already part of the response
<compatibility>Available in version 2.4.17 and later</compatibility>
<summary>
- <p>This module provides HTTP/2 (<a href="https://datatracker.ietf.org/doc/html/rfc7540">RFC 7540</a>)
+ <p>This module provides HTTP/2 (<rfc>7540</rfc>)
support for the Apache HTTP Server.</p>
<p>This module relies on <a href="http://nghttp2.org/">libnghttp2</a>
<identifier>ident_module</identifier>
<summary>
- <p>This module queries an <a href="https://datatracker.ietf.org/doc/html/rfc1413"
- >RFC 1413</a> compatible daemon on a remote host to look up the owner of
+ <p>This module queries an <rfc>1413</rfc> compatible daemon on a remote host to look up the owner of
a connection.</p>
</summary>
<seealso><module>mod_log_config</module></seealso>
<context>directory</context></contextlist>
<usage>
- <p>This directive enables <a href="https://datatracker.ietf.org/doc/html/rfc1413"
- >RFC 1413</a>-compliant logging of the remote user name for each
+ <p>This directive enables <rfc>1413</rfc>-compliant logging of the remote user name for each
connection, where the client machine runs identd or something similar.
This information is logged in the access log using the <code>%...l</code>
<a href="mod_log_config.html#formats">format string</a>.</p>
<context>directory</context></contextlist>
<usage>
<p>This directive specifies the timeout duration of an ident
- request. The default value of 30 seconds is recommended by <a
- href="https://datatracker.ietf.org/doc/html/rfc1413">RFC 1413</a>, mainly because
+ request. The default value of 30 seconds is recommended by <rfc>1413</rfc>, mainly because
of possible network latency. However, you may want to adjust the
timeout value according to your local network speed.</p>
</usage>
<p>
This module manages common properties of domains for one or more virtual hosts.
Its serves two main purposes: for one, supervise/renew TLS certificates via the
- ACME protocol (<a href="https://datatracker.ietf.org/doc/html/rfc8555">RFC 8555</a>).
+ ACME protocol (<rfc>8555</rfc>).
Certificates will be renewed by the module ahead of their expiration to account
for disruption in internet services. There are ways to monitor the status of all
certificates managed this way and configurations that will run your own
<dt><code>Content-Language:</code></dt>
<dd>The language(s) of the variant, as an Internet standard
- language tag (<a href="https://datatracker.ietf.org/doc/html/rfc1766"
- >RFC 1766</a>). An example is <code>en</code>,
+ language tag (<rfc>1766</rfc>). An example is <code>en</code>,
meaning English. If the variant contains more than one
language, they are separated by a comma.</dd>
<usage>
<p>This directive controls the use of the <code>Via:</code> HTTP
header by the proxy. Its intended use is to control the flow of
- proxy requests along a chain of proxy servers. See <a
- href="https://datatracker.ietf.org/doc/html/rfc2616">RFC 2616</a> (HTTP/1.1), section
+ proxy requests along a chain of proxy servers. See <rfc>2616</rfc> (HTTP/1.1), section
14.45 for an explanation of <code>Via:</code> header lines.</p>
<ul>
<code>Link</code> headers.</p>
<p>If available, they may do so using the <code>"103 Early Hints"</code>
intermediate responses as specified in
- <a href="https://datatracker.ietf.org/doc/html/rfc8297">RFC 8297</a>. This will give
+ <rfc>8297</rfc>. This will give
the best performance. If the client is talking HTTP/2 as well, this may
then result in a PUSH from Apache to the client or just in forwarding
the 103 response.</p>
following things:</p>
<ol>
-<li>An HTTP request header field (see <a
- href="https://datatracker.ietf.org/doc/html/rfc2616">RFC2616</a>
+<li>An HTTP request header field (see <rfc>2616</rfc>
for more information about these); for example: <code>Host</code>,
<code>User-Agent</code>, <code>Referer</code>, and
<code>Accept-Language</code>. A regular expression may be
This is the Secure Sockets Layer (SSL) protocol, version 3.0, from
the Netscape Corporation.
It is the successor to SSLv2 and the predecessor to TLSv1, but is
- deprecated in <a href="https://datatracker.ietf.org/doc/html/rfc7568">RFC 7568</a>.</p></li>
+ deprecated in <rfc>7568</rfc>.</p></li>
<li><code>TLSv1</code>
<p>
This is the Transport Layer Security (TLS) protocol, version 1.0.
It is the successor to SSLv3 and is defined in
- <a href="https://datatracker.ietf.org/doc/html/rfc2246">RFC 2246</a>.
+ <rfc>2246</rfc>.
It is supported by nearly every client.</p></li>
<li><code>TLSv1.1</code> (when using OpenSSL 1.0.1 and later)
<p>
A revision of the TLS 1.0 protocol, as defined in
- <a href="https://datatracker.ietf.org/doc/html/rfc4346">RFC 4346</a>.</p></li>
+ <rfc>4346</rfc>.</p></li>
<li><code>TLSv1.2</code> (when using OpenSSL 1.0.1 and later)
<p>
A revision of the TLS 1.1 protocol, as defined in
- <a href="https://datatracker.ietf.org/doc/html/rfc5246">RFC 5246</a>.</p></li>
+ <rfc>5246</rfc>.</p></li>
<li><code>TLSv1.3</code> (when using OpenSSL 1.1.1 and later)
<p>
A new version of the TLS protocol, as defined in
- <a href="https://datatracker.ietf.org/doc/html/rfc8446">RFC 8446</a>.</p></li>
+ <rfc>8446</rfc>.</p></li>
<li><code>all</code>
<p>
standardized DH parameters with prime lengths of 2048, 3072 and 4096 bits
and with additional prime lengths of 6144 and 8192 bits beginning with
version 2.4.10
-(from <a href="https://datatracker.ietf.org/doc/html/rfc3526">RFC 3526</a>), and hands
+(from <rfc>3526</rfc>), and hands
them out to clients based on the length of the certificate's RSA/DSA key.
With Java-based clients in particular (Java 7 or earlier), this may lead
to handshake failures - see this
CA certificates in their chain (the typical case nowadays),
stapling in its current implementation therefore only partially achieves the
stated goal of "saving roundtrips and resources" - see also
-<a href="https://datatracker.ietf.org/doc/html/rfc6961">RFC 6961</a>
+<rfc>6961</rfc>
(TLS Multiple Certificate Status Extension).
</p>
<usage>
<p>Optionally configures a secret key for encrypting and decrypting
TLS session tickets, as defined in
-<a href="https://datatracker.ietf.org/doc/html/rfc5077">RFC 5077</a>.
+<rfc>5077</rfc>.
Primarily suitable for clustered environments where TLS sessions information
should be shared between multiple nodes. For single-instance httpd setups,
it is recommended to <em>not</em> configure a ticket key file, but to
<dt><module>mod_ssl</module></dt>
<!-- Need Info on SSLEngine Support? -->
<dd>Added a support for
- <a href="https://datatracker.ietf.org/doc/html/rfc2817">RFC 2817</a>, which
+ <rfc>2817</rfc>, which
allows connections to upgrade from clear text to TLS encryption.</dd>
<dt><module>mod_imagemap</module></dt>
<p>To generate custom DH parameters, use the <code>openssl dhparam 1024</code>
command. Alternatively, you can use the following standard 1024-bit DH
- parameters from <a href="https://datatracker.ietf.org/doc/html/rfc2409">RFC 2409</a>,
+ parameters from <rfc>2409</rfc>,
section 6.2:</p>
<example><pre>-----BEGIN DH PARAMETERS-----
MIGHAoGBAP//////////yQ/aoiFowjTExmKLgNwc0SkCTgiKZ8x0Agu+pjsTmyJR
<dt><a id="SSL3" name="SSL3">[SSL3]</a></dt>
<dd>Alan O. Freier, Philip Karlton, Paul C. Kocher, <q>The SSL Protocol
-Version 3.0</q>, 1996. See <a
-href="https://datatracker.ietf.org/doc/html/rfc6101"
->RFC 6101</a>.</dd>
+Version 3.0</q>, 1996. See <rfc>6101</rfc>.</dd>
<dt><a id="TLS1" name="TLS1">[TLS1]</a></dt>
<dd>Tim Dierks, Christopher Allen, <q>The TLS Protocol Version 1.0</q>,
projects / thirdparty / apache / httpd.git / commitdiff
