in the cache, and mod_cache aims to honor all of the various HTTP
headers and options that control the cacheability of content
as described in
- <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-13">Section
- 13 of RFC2616</a>.
+ <rfc section="13">2616</rfc>.
<module>mod_cache</module>
is aimed at both simple and complex caching configurations, where
you are dealing with proxied content, dynamic local content or
<p>The HTTP protocol contains built in support for an in-line caching
mechanism
- <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-13">
- described by section 13 of RFC2616</a>, and the
+ <rfc section="13">2616</rfc>, and the
<module>mod_cache</module> module can be used to take advantage of
this.</p>
</dl>
<p>Full details of how HTTP caching works can be found in
- <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-13">
- Section 13 of RFC2616</a>.</p>
+ <rfc section="13">2616</rfc>.</p>
<section>
<title>Interaction with the Server</title>
<p>The full definition of which responses can be cached by an HTTP
cache is defined in
- <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-13.4">
- RFC2616 Section 13.4 Response Cacheability</a>, and can be summed up as
+ <rfc section="13.4">2616</rfc> (Response Cacheability), and can be summed up as
follows:</p>
<ol>
the ETag of the response, the server should return
<code>412 Precondition Failed</code>. Full details of how to handle an
<code>If-Match</code> header can be found in
- <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.24">
- RFC2616 section 14.24</a>.</dd>
+ <rfc section="14.24">2616</rfc>.</dd>
<dt><code>If-None-Match</code></dt>
<dd>If the provided ETag in the <code>If-None-Match</code> header matches
<code>304 Not Modified</code> for GET/HEAD requests, or
<code>412 Precondition Failed</code> for other methods. Full details of how
to handle an <code>If-None-Match</code> header can be found in
- <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.26">
- RFC2616 section 14.26</a>.</dd>
+ <rfc section="14.26">2616</rfc>.</dd>
<dt><code>If-Modified-Since</code></dt>
<dd>If the provided date in the <code>If-Modified-Since</code> header is
older than the <code>Last-Modified</code> header of the response, the server
should return <code>304 Not Modified</code>. Full details of how to handle an
<code>If-Modified-Since</code> header can be found in
- <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.25">
- RFC2616 section 14.25</a>.</dd>
+ <rfc section="14.25">2616</rfc>.</dd>
<dt><code>If-Unmodified-Since</code></dt>
<dd>If the provided date in the <code>If-Modified-Since</code> header is
newer than the <code>Last-Modified</code> header of the response, the server
should return <code>412 Precondition Failed</code>. Full details of how to
handle an <code>If-Unmodified-Since</code> header can be found in
- <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.28">
- RFC2616 section 14.28</a>.</dd>
+ <rfc section="14.28">2616</rfc>.</dd>
<dt><code>If-Range</code></dt>
<dd>If the provided ETag or date in the <code>If-Range</code> header matches
is present, the server should return
<code>206 Partial Response</code>. Full details of how to handle an
<code>If-Range</code> header can be found in
- <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.27">
- RFC2616 section 14.27</a>.</dd>
+ <rfc section="14.27">2616</rfc>.</dd>
</dl>
<p>There are a number of ways of determining the length of a response
body, described in full in
- <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-4.4">
- RFC2616 section 4.4 Message Length</a>.</p>
+ <rfc section="4.4">2616</rfc> (Message Length).</p>
<p>When the <code>Content-Length</code> header is present, the size of
the body is declared at the start of the response. If this information
<p>The media type of the body is placed in the <code>Content-Type</code>
header, and the format of the header is described in full in
- <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-3.7">
- RFC2616 section 3.7 Media Types</a>.</p>
+ <rfc section="3.7">2616</rfc> (Media Types).</p>
<p>A syntactically valid content type might look as follows:</p>
<p>There are a number of ways of determining the length of a response
body, described in full in
- <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-4.4">
- RFC2616 section 4.4 Message Length</a>.</p>
+ <rfc section="4.4">2616</rfc> (Message Length).</p>
<p>When the <code>Content-Length</code> header is present, the size of
the body is declared at the start of the response. HTTP/1.1 defines the
<p>Full details of how a freshness lifetime is calculated is described in
full in
- <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-13.2">
- RFC2616 section 13.2 Expiration Model</a>.</p>
+ <rfc section="13.2">2616</rfc> (Expiration Model).</p>
<p>During the freshness lifetime, a cache does not need to contact the
origin server at all, it can simply pass the cached content as is back
<p>Full details of how content may be declared uncacheable is described in
full in
- <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.9.1">
- RFC2616 section 14.9.1 What is Cacheable</a>, and within the definition
+ <rfc section="14.9.1">2616</rfc> (What is Cacheable), and within the definition
for the <code>Pragma</code> header in
- <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.32">
- RFC2616 section 14.32 Pragma</a>.</p>
+ <rfc section="14.32">2616</rfc> (Pragma).</p>
<p>Most specifically, should any of the following header combinations
exist in the response headers, the response will be rejected:</p>
<code>Last-Modified</code> header.</p>
<p>The <code>ETag</code> header is described in full in
- <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.19">
- RFC2616 section 14.19 Etag</a>, and the <code>Last-Modified</code> header
+ <rfc section="14.19">2616</rfc> (Etag), and the <code>Last-Modified</code> header
is described in full in
- <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.29">
- RFC2616 section 14.29 Last-Modified</a>.</p>
+ <rfc section="14.29">2616</rfc> (Last-Modified).</p>
<p>In addition to being checked present, the headers are checked for
syntax.</p>
forbidden by the administrator.</p>
<p>The <code>Vary</code> header is described in full in
- <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.44">
- RFC2616 section 14.44 Vary</a>.</p>
+ <rfc section="14.44">2616</rfc> (Vary).</p>
<p>Some client provided headers, such as <code>User-Agent</code>,
can contain thousands or millions of combinations of values over a period
Apache configuration and passed from the shell, CGI scripts and
SSI pages are provided with a set of environment variables
containing meta-information about the request as required by
- the <a href="https://datatracker.ietf.org/doc/html/rfc3875">CGI
- specification</a>.</p>
+ the CGI specification (<rfc>3875</rfc>).</p>
</section>
<section id="caveats">
<section id="cgi">
<title>CGI environment variables</title>
- <p>The <a
- href="https://datatracker.ietf.org/doc/html/rfc3875#section-4.1"
- >CGI specification</a> defines a number of environment
+ <p>The CGI specification (<rfc section="4.1">3875</rfc>) defines a number of environment
variables that expand on those defined by the HTTP spec.
These have been adopted more broadly, and are a standard
part of passing information between the browser and the
Gateway Interface</a> <a name="cgi" id="cgi">(CGI)</a></dt>
<dd>A standard definition for an interface between a web server and an
external program that allows the external program to service requests.
- There is an <a href="https://datatracker.ietf.org/doc/html/rfc3875">Informational
- RFC</a> which covers the specifics.<br />
+ There is an Informational RFC (<rfc>3875</rfc>) which covers the specifics.<br />
See: <a href="howto/cgi.html">Dynamic Content with CGI</a>
</dd>
<p>These variables are available to the CGI programmer, and
are half of the story of the client-server communication. The
complete list of required variables is at
- <a href="https://datatracker.ietf.org/doc/html/rfc3875">Common Gateway
- Interface RFC</a>.</p>
+ Common Gateway Interface RFC (<rfc>3875</rfc>).</p>
<p>This simple Perl CGI program will display all of the
environment variables that are being passed around. Two
<title>For more information</title>
<p>The current CGI specification is available in the
- <a href="https://datatracker.ietf.org/doc/html/rfc3875">Common Gateway
- Interface RFC</a>.</p>
+ Common Gateway Interface RFC (<rfc>3875</rfc>).</p>
<p>When you post a question about a CGI problem that you're
having, whether to a mailing list, or to a newsgroup, make sure
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 <rfc>7540</rfc>
- (<a href="https://datatracker.ietf.org/doc/html/rfc7540">also available in more readable formatting, YMMV</a>).
+ (also available in more readable formatting, YMMV (<rfc>7540</rfc>)).
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
<em>what</em> a thing wants to do and then read the RFC about <em>how</em> it is done. A much
<li>HTTP/2 is a <strong>binary protocol</strong>, as opposed to HTTP 1.1 that is plain text. The latter is meant to be human readable (for example sniffing network traffic) meanwhile the former is not. More info in the official FAQ <a href="https://http2.github.io/faq/#why-is-http2-binary">question</a>.</li>
<li><strong>h2</strong> is HTTP/2 over TLS (protocol negotiation via ALPN).</li>
<li><strong>h2c</strong> is HTTP/2 over TCP.</li>
- <li>A <strong>frame</strong> is the smallest unit of communication within an HTTP/2 connection, consisting of a header and a variable-length sequence of octets structured according to the frame type. More info in the official documentation <a href="https://datatracker.ietf.org/doc/html/rfc7540"> section</a>.</li>
- <li>A <strong>stream</strong> is a bidirectional flow of frames within the HTTP/2 connection. The correspondent concept in HTTP 1.1 is a request/response message exchange. More info in the official documentation <a href="https://datatracker.ietf.org/doc/html/rfc7540"> section</a>.</li>
+ <li>A <strong>frame</strong> is the smallest unit of communication within an HTTP/2 connection, consisting of a header and a variable-length sequence of octets structured according to the frame type. More info in the official documentation <rfc>7540</rfc>.</li>
+ <li>A <strong>stream</strong> is a bidirectional flow of frames within the HTTP/2 connection. The correspondent concept in HTTP 1.1 is a request/response message exchange. More info in the official documentation <rfc>7540</rfc>.</li>
<li>HTTP/2 is able to run <strong>multiple streams</strong> of data over the same TCP connection, avoiding the classic HTTP 1.1 head of blocking slow request and avoiding to re-instantiate TCP connections for each request/response (KeepAlive patched the problem in HTTP 1.1 but did not fully solve it).</li>
</ul>
</section>
cipher suite will force it to simply refuse and fall back to HTTP 1.1. This is a common mistake
that is done while configuring httpd for HTTP/2 the first time, so please keep it in mind to avoid
long debugging sessions! If you want to be sure about the cipher suite to choose please avoid
- the ones listed in the <a href="https://datatracker.ietf.org/doc/html/rfc7540">HTTP/2 TLS reject list</a>.</p>
+ the ones listed in the HTTP/2 TLS reject list (<rfc>7540</rfc>).</p>
</note>
<p>The order of protocols mentioned is also relevant. By default, the first one is the
most preferred protocol. When a client offers multiple choices, the one most to the
beginning in 2), a redirection (codes beginning in 3), an
error caused by the client (codes beginning in 4), or an
error in the server (codes beginning in 5). The full list of
- possible status codes can be found in the <a
- href="https://datatracker.ietf.org/doc/html/rfc2616">HTTP
- specification</a> (RFC2616 section 10).</dd>
+ possible status codes can be found in the HTTP specification (<rfc>2616</rfc>) (RFC2616 section 10).</dd>
<dt><code>2326</code> (<code>%b</code>)</dt>
<usage>
<p>This directive changes the rules applied to the HTTP Request Line
- (<a href="https://datatracker.ietf.org/doc/html/rfc7230#section-3.1.1"
- >RFC 7230 §3.1.1</a>) and the HTTP Request Header Fields
- (<a href="https://datatracker.ietf.org/doc/html/rfc7230#section-3.2"
- >RFC 7230 §3.2</a>), which are now applied by default or using
+ (<rfc section="3.1.1">7230</rfc>) and the HTTP Request Header Fields
+ (<rfc section="3.2">7230</rfc>), which are now applied by default or using
the <code>Strict</code> option. Due to legacy modules, applications or
custom user-agents which must be deprecated the <code>Unsafe</code>
option has been added to revert to the legacy behaviors.</p>
<p>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.
- <a href="https://datatracker.ietf.org/doc/html/rfc7230#section-9.4"
- >RFC 7230 §9.4 Request Splitting</a> and
- <a href="https://datatracker.ietf.org/doc/html/rfc7230#section-9.5"
- >§9.5 Response Smuggling</a> call out only two of the potential
+ <rfc section="9.4">7230</rfc> (Request Splitting) and
+ <rfc section="9.5">7230</rfc> (Response Smuggling) call out only two of the potential
risks of accepting non-conformant request messages, while
- <a href="https://datatracker.ietf.org/doc/html/rfc7230#section-3.5"
- >RFC 7230 §3.5</a> "Message Parsing Robustness" identify the
+ <rfc section="3.5">7230</rfc> "Message Parsing Robustness" identify the
risks of accepting obscure whitespace and request message formatting.
As of the introduction of this directive, all grammar rules of the
specification are enforced in the default <code>Strict</code> operating
</dd>
<dt>RegisteredMethods|LenientMethods</dt>
<dd>
- <p><a href="https://datatracker.ietf.org/doc/html/rfc7231#section-4.1"
- >RFC 7231 §4.1</a> "Request Methods" "Overview" requires that
+ <p><rfc section="4.1">7231</rfc> "Request Methods" "Overview" requires that
origin servers shall respond with a HTTP 501 status code when an
unsupported method is encountered in the request line.
This already happens when the <code>LenientMethods</code> option is used,
</dd>
<dt>Allow0.9|Require1.0</dt>
<dd>
- <p><a href="https://datatracker.ietf.org/doc/html/rfc2616#section-19.6"
- >RFC 2616 §19.6</a> "Compatibility With Previous Versions" had
+ <p><rfc section="19.6">2616</rfc> "Compatibility With Previous Versions" had
encouraged HTTP servers to support legacy HTTP/0.9 requests. RFC 7230
supersedes this with "The expectation to support HTTP/0.9 requests has
been removed" and offers additional comments in
- <a href="https://datatracker.ietf.org/doc/html/rfc7230#appendix-A"
+ <a href="https://www.rfc-editor.org/rfc/rfc7230#appendix-A"
>RFC 7230 Appendix A</a>. The <code>Require1.0</code> option allows
the user to remove support of the default <code>Allow0.9</code> option's
behavior.</p>
Authentication case, the value associated with each stored username
must be an encrypted string composed from the username, realm name,
and password. (See
- <a href="https://datatracker.ietf.org/doc/html/rfc2617#section-3.2.2.2">
- RFC 2617, Section 3.2.2.2</a> for more details on the format used
+ <rfc section="3.2.2.2">2617</rfc> for more details on the format used
for this encrypted string.)</p>
<p>As a consequence of the difference in the stored values between
stale or expired content is still fresh, and can represent a significant
performance boost when the origin server supports <strong>conditional
requests</strong> by honoring the
- <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.26">If-None-Match</a>
+ If-None-Match (<rfc section="14.26">2616</rfc>)
HTTP request header. Content is only regenerated from scratch when the content
has changed, and not when the cached entry expires.</p>
<p>Under normal operation, <module>mod_cache</module> will respond to
and can be controlled by the
- <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.9">Cache-Control</a>
+ Cache-Control (<rfc section="14.9">2616</rfc>)
and
- <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.32">Pragma</a>
+ Pragma (<rfc section="14.32">2616</rfc>)
headers sent from a client in a request, or from a
server within a response. Under exceptional circumstances,
<module>mod_cache</module> can be configured to override these headers
by <module>mod_cache</module> when the
<directive module="mod_cache">CacheLock</directive> directive is suitably
configured. Such responses will contain a
- <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.46">Warning</a>
+ Warning (<rfc section="14.46">2616</rfc>)
HTTP header with a 110 response code. RFC 2616 also allows a cache to return
stale data when the attempt made to refresh the stale data returns an
error 500 or above, and this behavior is supported by default by
<module>mod_cache</module>. Such responses will contain a
- <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.46">Warning</a>
+ Warning (<rfc section="14.46">2616</rfc>)
HTTP header with a 111 response code.</p>
<p><module>mod_cache</module> requires the services of one or more
<seealso><directive module="mod_mime">AddHandler</directive></seealso>
<seealso><a href="../suexec.html">Running CGI programs under different
user IDs</a></seealso>
-<seealso><a href="https://datatracker.ietf.org/doc/html/rfc3875">CGI Specification</a></seealso>
+<seealso>CGI Specification (<rfc>3875</rfc>)</seealso>
<section id="env"><title>CGI Environment variables</title>
<p>The server will set the CGI environment variables as described
- in the <a href="https://datatracker.ietf.org/doc/html/rfc3875">CGI specification</a>,
+ in the CGI specification (<rfc>3875</rfc>),
with the following provisions:</p>
<dl>
<summary>
<p>This module provides the ability to convert a response into
- an <a href="https://datatracker.ietf.org/doc/html/rfc2397">RFC2397 data URL</a>.
+ an <rfc>2397</rfc> (data URL).
</p>
<p>Data URLs can be embedded inline within web pages using something
designed for transmitting a binary file in an ASCII (text)
format.</p>
- <p>The <a href="https://datatracker.ietf.org/doc/html/rfc2616">HTTP/1.1
- RFC</a>, section 14.11 puts it this way:</p>
+ <p>The HTTP/1.1 RFC (<rfc>2616</rfc>), section 14.11 puts it this way:</p>
- <blockquote cite="https://datatracker.ietf.org/doc/html/rfc2616">
+ <blockquote cite="https://www.rfc-editor.org/rfc/rfc2616">
<p>The Content-Encoding entity-header field is used as a modifier to
the media-type. When present, its value indicates what additional
content codings have been applied to the entity-body, and thus what
<li><strong>Not RFC-compliant:</strong> Standards documents consistently
recommend against setting Content-Encoding for files that are already
compressed (such as .zip or .gz files). See
- <a href="https://datatracker.ietf.org/doc/html/rfc9110#name-content-encoding">RFC 9110</a>.</li>
+ <a href="https://www.rfc-editor.org/rfc/rfc9110#name-content-encoding">RFC 9110</a>.</li>
<li><strong>Breaks content integrity:</strong> When Content-Encoding is set,
most HTTP clients will decompress the file before writing it to disk. This
<td><p>Protocol accepted by <module>mod_proxy_http</module> or
<module>mod_proxy_wstunnel</module> for the HTTP Upgrade mechanism
upon negotiation by the HTTP client/browser (per
- <a href="https://datatracker.ietf.org/doc/html/rfc9110#name-upgrade">RFC 9110 - Upgrade</a>).
+ <a href="https://www.rfc-editor.org/rfc/rfc9110#name-upgrade">RFC 9110 - Upgrade</a>).
See the <a href="#protoupgrade">Protocol Upgrade</a> note below</p>
</td></tr>
<tr><td>mapping</td>
<highlight language="config">ProxyFCGISetEnvIf true VARIABLE</highlight>
The CGI/1.1 specification
- <a href="https://datatracker.ietf.org/doc/html/rfc3875#section-4.1">does not
- distinguish</a> between a variable with an empty value and a variable that
+ does not distinguish (<rfc section="4.1">3875</rfc>) between a variable with an empty value and a variable that
does not exist. However, many CGI and FastCGI implementations distinguish (or
allow scripts to distinguish) between the two. The choice of which to use is
dependent upon your implementation and your reason for modifying the variable.
Most are documented in the
<a href="../expr.html#vars">Expressions doc</a>, in the
<a href="../env.html">Environment Variables doc</a>,
- or the <a href="https://datatracker.ietf.org/doc/html/rfc3875">CGI
- specification</a>.</p>
+ or the CGI specification (<rfc>3875</rfc>).</p>
<p>SERVER_NAME and SERVER_PORT depend on the values of
<directive module="core">UseCanonicalName</directive> and
<p>As an alternative to storing certificates and private keys in
files, a certificate identifier can be used to identify a certificate
-stored in a token. Currently, only <a
-href="https://datatracker.ietf.org/doc/html/rfc7512">PKCS#11 URIs</a> are
+stored in a token. Currently, only PKCS#11 URIs (<rfc>7512</rfc>) are
recognized as certificate identifiers, and can be used in conjunction
with the OpenSSL <code>pkcs11</code> engine or provider. If <directive
module="mod_ssl">SSLCertificateKeyFile</directive> is omitted, the
<p>As an alternative to storing private keys in files, a key
identifier can be used to identify a private key stored in a
-token. Currently, only <a href="https://datatracker.ietf.org/doc/html/rfc7512">PKCS#11 URIs</a> are recognized as private key
+token. Currently, only PKCS#11 URIs (<rfc>7512</rfc>) are recognized as private key
identifiers, and can be used in conjunction with the OpenSSL
<code>pkcs11</code> engine or provider.</p>
<p>
With OpenSSL 3.0 or later, if no engine is specified but the key or certificate
-is specified using a <a href="https://datatracker.ietf.org/doc/html/rfc7512">PKCS#11 URIs</a>
+is specified using a PKCS#11 URIs (<rfc>7512</rfc>)
then it is tried to load the key and certificate from an OpenSSL provider.
The OpenSSL provider to use must be defined and configured in the OpenSSL config file,
and it must support the <a href="https://docs.openssl.org/3.0/man7/provider-storemgmt/">STORE method</a>
-for <a href="https://datatracker.ietf.org/doc/html/rfc7512">PKCS#11 URIs</a>.
+for PKCS#11 URIs (<rfc>7512</rfc>).
</p>
</usage>
</directivesynopsis>
<p>
ECH is specified in
- <a href="https://datatracker.ietf.org/doc/draft-ietf-tls-esni/">draft-ietf-tls-esni</a>
+ <rfc>9849</rfc>
httpd supports ECH "shared-mode" where the httpd instance does the
ECH decryption and also hosts both the ECH `public-name` and `backend` web
sites.
<dd>The <code>ContentDigest</code> directive and support for the the
<code>Content-MD5</code> header has been removed from the server,
corresponding with the removal of this header from
- <a href="https://datatracker.ietf.org/doc/html/rfc7231#appendix-B">
+ <a href="https://www.rfc-editor.org/rfc/rfc7231#appendix-B">
RFC7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and
Content.</a></dd>
<dt><code><var>realm</var></code></dt>
<dd>The realm name to which the user name belongs. See
- <a href="https://datatracker.ietf.org/doc/html/rfc2617#section-3.2.1">
- http://tools.ietf.org/html/rfc2617#section-3.2.1</a> for more details.
+ <rfc section="3.2.1">2617</rfc> for more details.
</dd>
<dt><code><var>username</var></code></dt>
<dt><a id="MIME" name="MIME">[MIME]</a></dt>
<dd>N. Freed, N. Borenstein, <q>Multipurpose Internet Mail Extensions
(MIME) Part One: Format of Internet Message Bodies</q>, RFC2045.
-See for instance <a href="https://datatracker.ietf.org/doc/html/rfc2045"
->http://tools.ietf.org/html/rfc2045</a>.</dd>
+See for instance <rfc>2045</rfc>.</dd>
<dt><a id="SSL3" name="SSL3">[SSL3]</a></dt>
<dd>Alan O. Freier, Philip Karlton, Paul C. Kocher, <q>The SSL Protocol
<dt><a id="TLS1" name="TLS1">[TLS1]</a></dt>
<dd>Tim Dierks, Christopher Allen, <q>The TLS Protocol Version 1.0</q>,
-1999. See <a href="https://datatracker.ietf.org/doc/html/rfc2246"
->http://ietf.org/rfc/rfc2246.txt</a>.</dd>
+1999. See <rfc>2246</rfc>.</dd>
<dt><a id="TLS11" name="TLS11">[TLS11]</a></dt>
<dd><q>The TLS Protocol Version 1.1</q>,
-2006. See <a href="https://datatracker.ietf.org/doc/html/rfc4346"
->http://tools.ietf.org/html/rfc4346</a>.</dd>
+2006. See <rfc>4346</rfc>.</dd>
<dt><a id="TLS12" name="TLS12">[TLS12]</a></dt>
<dd><q>The TLS Protocol Version 1.2</q>,
-2008. See <a href="https://datatracker.ietf.org/doc/html/rfc5246"
->http://tools.ietf.org/html/rfc5246</a>.</dd>
+2008. See <rfc>5246</rfc>.</dd>
<dt><a id="TLS13" name="TLS13">[TLS13]</a></dt>
<dd><q>The Transport Layer Security (TLS) Protocol Version 1.3</q>,
-2018. See <a href="https://datatracker.ietf.org/doc/html/rfc8446"
->https://tools.ietf.org/html/rfc8446</a>.</dd>
+2018. See <rfc>8446</rfc>.</dd>
</dl>
</section>
<!-- /references -->
projects / thirdparty / apache / httpd.git / commitdiff
