```
- `<glossary>` — Use for glossary-defined terms. Use `ref` attribute when link target differs from display text.
+## External Link Conventions
+
+### RFC Links
+Always link to the IETF Datatracker for RFC references:
+```
+https://datatracker.ietf.org/doc/html/rfcNNNN
+```
+For section-specific links, use fragment anchors: `#section-N.N`
+
+Do NOT use `tools.ietf.org`, `www.rfc-editor.org`, `www.ietf.org/rfc/`, `www.w3.org/Protocols/`, `www.faqs.org/rfcs/`, or any other RFC mirror. These are legacy patterns — `datatracker.ietf.org` is the canonical standard for this documentation.
+
## Directive Syntax Definitions
- Use `<var>` for all user-supplied arguments in `<syntax>` blocks.
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="http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html">Section
+ <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-13">Section
13 of RFC2616</a>.
<module>mod_cache</module>
is aimed at both simple and complex caching configurations, where
<p>The HTTP protocol contains built in support for an in-line caching
mechanism
- <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html">
+ <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-13">
described by section 13 of RFC2616</a>, 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="http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html">
+ <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-13">
Section 13 of RFC2616</a>.</p>
<section>
<p>The full definition of which responses can be cached by an HTTP
cache is defined in
- <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.4">
+ <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
follows:</p>
</related>
<p>The HTTP protocol follows the <strong>robustness principle</strong>
- as described in <a href="http://tools.ietf.org/html/rfc1122">RFC1122</a>,
+ as described in <a href="https://datatracker.ietf.org/doc/html/rfc1122">RFC1122</a>,
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
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="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24">
+ <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.24">
RFC2616 section 14.24</a>.</dd>
<dt><code>If-None-Match</code></dt>
<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="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.26">
+ <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.26">
RFC2616 section 14.26</a>.</dd>
<dt><code>If-Modified-Since</code></dt>
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="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.25">
+ <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.25">
RFC2616 section 14.25</a>.</dd>
<dt><code>If-Unmodified-Since</code></dt>
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="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.28">
+ <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.28">
RFC2616 section 14.28</a>.</dd>
<dt><code>If-Range</code></dt>
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="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.27">
+ <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.27">
RFC2616 section 14.27</a>.</dd>
</dl>
<p>There are a number of ways of determining the length of a response
body, described in full in
- <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4">
+ <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-4.4">
RFC2616 section 4.4 Message Length</a>.</p>
<p>When the <code>Content-Length</code> header is present, the size of
<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="http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7">
+ <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-3.7">
RFC2616 section 3.7 Media Types</a>.</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="http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4">
+ <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-4.4">
RFC2616 section 4.4 Message Length</a>.</p>
<p>When the <code>Content-Length</code> header is present, the size of
<p>Full details of how a freshness lifetime is calculated is described in
full in
- <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2">
+ <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-13.2">
RFC2616 section 13.2 Expiration Model</a>.</p>
<p>During the freshness lifetime, a cache does not need to contact the
<p>Full details of how content may be declared uncacheable is described in
full in
- <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1">
+ <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
for the <code>Pragma</code> header in
- <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.32">
+ <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.32">
RFC2616 section 14.32 Pragma</a>.</p>
<p>Most specifically, should any of the following header combinations
<code>Last-Modified</code> header.</p>
<p>The <code>ETag</code> header is described in full in
- <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.19">
+ <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
is described in full in
- <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.29">
+ <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.29">
RFC2616 section 14.29 Last-Modified</a>.</p>
<p>In addition to being checked present, the headers are checked for
forbidden by the administrator.</p>
<p>The <code>Vary</code> header is described in full in
- <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44">
+ <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.44">
RFC2616 section 14.44 Vary</a>.</p>
<p>Some client provided headers, such as <code>User-Agent</code>,
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="http://www.ietf.org/rfc/rfc3875">CGI
+ the <a href="https://datatracker.ietf.org/doc/html/rfc3875">CGI
specification</a>.</p>
</section>
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="http://www.ietf.org/rfc/rfc3875">Informational
+ There is an <a href="https://datatracker.ietf.org/doc/html/rfc3875">Informational
RFC</a> which covers the specifics.<br />
See: <a href="howto/cgi.html">Dynamic Content with CGI</a>
</dd>
<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="http://ietf.org/rfc/rfc2616.txt">RFC 2616</a>.
+ defined by <a href="https://datatracker.ietf.org/doc/html/rfc2616">RFC 2616</a>.
</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="http://www.ietf.org/rfc/rfc3546.txt">RFC 3546</a>
+ and <a href="https://datatracker.ietf.org/doc/html/rfc3546">RFC 3546</a>
</dd>
<dt><a name="serversideincludes" id="serversideincludes">Server Side
<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="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396</a>. URIs used on the
+ href="https://datatracker.ietf.org/doc/html/rfc2396">RFC 2396</a>. 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="http://tools.ietf.org/html/rfc2616">RFC 2616</a>,
+ <a href="https://datatracker.ietf.org/doc/html/rfc2616">RFC 2616</a>,
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>
<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="http://www.ietf.org/rfc/rfc3875">Common Gateway
+ <a href="https://datatracker.ietf.org/doc/html/rfc3875">Common Gateway
Interface RFC</a>.</p>
<p>This simple Perl CGI program will display all of the
<title>For more information</title>
<p>The current CGI specification is available in the
- <a href="http://www.ietf.org/rfc/rfc3875">Common Gateway
+ <a href="https://datatracker.ietf.org/doc/html/rfc3875">Common Gateway
Interface RFC</a>.</p>
<p>When you post a question about a CGI problem that you're
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://tools.ietf.org/html/rfc7540">RFC 7540</a>
- (<a href="http://httpwg.org/specs/rfc7540.html">also available in more readable formatting, YMMV</a>).
+ its <a href="https://datatracker.ietf.org/doc/html/rfc7540">RFC 7540</a>
+ (<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
<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="http://httpwg.org/specs/rfc7540.html#FramingLayer"> 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="http://httpwg.org/specs/rfc7540.html#StreamsLayer"> 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 <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>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="http://httpwg.org/specs/rfc7540.html#BadCipherSuites">HTTP/2 TLS reject list</a>.</p>
+ the ones listed in the <a href="https://datatracker.ietf.org/doc/html/rfc7540">HTTP/2 TLS reject list</a>.</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
<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://tools.ietf.org/html/rfc8297">RFC 8297</a>.</p>
+ is described in <a href="https://datatracker.ietf.org/doc/html/rfc8297">RFC 8297</a>.</p>
<p>In order to use this, you need to explicitly enable it on the server via</p>
<highlight language="config">
H2EarlyHints on
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="http://www.w3.org/Protocols/rfc2616/rfc2616.txt">HTTP
+ href="https://datatracker.ietf.org/doc/html/rfc2616">HTTP
specification</a> (RFC2616 section 10).</dd>
<dt><code>2326</code> (<code>%b</code>)</dt>
<title>Lingering Close</title>
<p>As discussed in <a
- href="http://www.ics.uci.edu/pub/ietf/http/draft-ietf-http-connection-00.txt">
+ href="https://datatracker.ietf.org/doc/html/draft-ietf-http-connection-00">
draft-ietf-http-connection-00.txt</a> section 8, in order for
an HTTP server to <strong>reliably</strong> implement the
protocol, it needs to shut down each direction of the
http://www.rfc-editor.org/errata.php</a> - RFC Errata
</li>
<li>
- <a href="http://ftp.ics.uci.edu/pub/ietf/http/#RFC">
- http://ftp.ics.uci.edu/pub/ietf/http/#RFC</a> - A pre-compiled list
+ <a href="https://httpwg.org/specs/">
+ https://httpwg.org/specs/</a> - A pre-compiled list
of HTTP related RFCs
</li>
</ul>
basic web server complies with the following IETF recommendations:</p>
<dl>
- <dt><a href="http://www.rfc-editor.org/rfc/rfc1945.txt">RFC 1945</a>
+ <dt><a href="https://datatracker.ietf.org/doc/html/rfc1945">RFC 1945</a>
(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="http://www.rfc-editor.org/rfc/rfc2616.txt">RFC 2616</a>
+ <dt><a href="https://datatracker.ietf.org/doc/html/rfc2616">RFC 2616</a>
(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="http://www.rfc-editor.org/rfc/rfc2396.txt">RFC 2396</a>
+ <dt><a href="https://datatracker.ietf.org/doc/html/rfc2396">RFC 2396</a>
(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="http://www.rfc-editor.org/rfc/rfc4346.txt">RFC 4346</a>
+ <dt><a href="https://datatracker.ietf.org/doc/html/rfc4346">RFC 4346</a>
(Standards Track)</dt>
<dd>The TLS protocol provides communications security over the
the following IETF and W3C recommendations:</p>
<dl>
- <dt><a href="http://www.rfc-editor.org/rfc/rfc2854.txt">RFC 2854</a>
+ <dt><a href="https://datatracker.ietf.org/doc/html/rfc2854">RFC 2854</a>
(Informational)</dt>
<dd>This document summarizes the history of HTML development,
follows the following IETF recommendations:</p>
<dl>
- <dt><a href="http://www.rfc-editor.org/rfc/rfc2617.txt">RFC 2617</a>
+ <dt><a href="https://datatracker.ietf.org/doc/html/rfc2617">RFC 2617</a>
(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="http://www.rfc-editor.org/rfc/rfc3066.txt">RFC 3066</a></dt>
+ <a href="https://datatracker.ietf.org/doc/html/rfc3066">RFC 3066</a></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="http://www.rfc-editor.org/rfc/rfc3282.txt">RFC 3282</a>
+ <dt><a href="https://datatracker.ietf.org/doc/html/rfc3282">RFC 3282</a>
(Standards Track)</dt>
<dd>This document defines a "Content-language:" header, for use in
<usage>
<p>This directive changes the rules applied to the HTTP Request Line
- (<a href="https://tools.ietf.org/html/rfc7230#section-3.1.1"
+ (<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://tools.ietf.org/html/rfc7230#section-3.2"
+ (<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
the <code>Strict</code> option. Due to legacy modules, applications or
custom user-agents which must be deprecated the <code>Unsafe</code>
<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://tools.ietf.org/html/rfc7230#section-9.4"
+ <a href="https://datatracker.ietf.org/doc/html/rfc7230#section-9.4"
>RFC 7230 §9.4 Request Splitting</a> and
- <a href="https://tools.ietf.org/html/rfc7230#section-9.5"
+ <a href="https://datatracker.ietf.org/doc/html/rfc7230#section-9.5"
>§9.5 Response Smuggling</a> call out only two of the potential
risks of accepting non-conformant request messages, while
- <a href="https://tools.ietf.org/html/rfc7230#section-3.5"
+ <a href="https://datatracker.ietf.org/doc/html/rfc7230#section-3.5"
>RFC 7230 §3.5</a> "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
</dd>
<dt>RegisteredMethods|LenientMethods</dt>
<dd>
- <p><a href="https://tools.ietf.org/html/rfc7231#section-4.1"
+ <p><a href="https://datatracker.ietf.org/doc/html/rfc7231#section-4.1"
>RFC 7231 §4.1</a> "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.
</dd>
<dt>Allow0.9|Require1.0</dt>
<dd>
- <p><a href="https://tools.ietf.org/html/rfc2616#section-19.6"
+ <p><a href="https://datatracker.ietf.org/doc/html/rfc2616#section-19.6"
>RFC 2616 §19.6</a> "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://tools.ietf.org/html/rfc7230#appendix-A"
+ <a href="https://datatracker.ietf.org/doc/html/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="http://tools.ietf.org/html/rfc2617#section-3.2.2.2">
+ <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
for this encrypted string.)</p>
<summary>
<p>This module implements HTTP Digest Authentication
- (<a href="http://www.faqs.org/rfcs/rfc2617.html">RFC2617</a>), and
+ (<a href="https://datatracker.ietf.org/doc/html/rfc2617">RFC2617</a>), 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://www.rfc-editor.org/rfc/rfc7519">RFC 7519</a>.</p>
+ <a href="https://datatracker.ietf.org/doc/html/rfc7519">RFC 7519</a>.</p>
<p>A JWT token is read from the <var>Authorization</var> header
with an <var>auth-scheme</var> of <var>Bearer</var>.</p>
variable.</note>
<p><module>mod_cache</module> implements an <a
- href="https://www.rfc-editor.org/rfc/rfc2616">RFC 2616</a> compliant
+ href="https://datatracker.ietf.org/doc/html/rfc2616">RFC 2616</a> compliant
<strong>HTTP content caching filter</strong>, with support for the caching
of content negotiated responses containing the Vary header.</p>
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="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.26">If-None-Match</a>
+ <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.26">If-None-Match</a>
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="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9">Cache-Control</a>
+ <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.9">Cache-Control</a>
and
- <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.32">Pragma</a>
+ <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.32">Pragma</a>
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="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.46">Warning</a>
+ <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.46">Warning</a>
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="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.46">Warning</a>
+ <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.46">Warning</a>
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="http://www.ietf.org/rfc/rfc3875">CGI Specification</a></seealso>
+<seealso><a href="https://datatracker.ietf.org/doc/html/rfc3875">CGI Specification</a></seealso>
<section id="env"><title>CGI Environment variables</title>
<p>The server will set the CGI environment variables as described
- in the <a href="http://www.ietf.org/rfc/rfc3875">CGI specification</a>,
+ in the <a href="https://datatracker.ietf.org/doc/html/rfc3875">CGI specification</a>,
with the following provisions:</p>
<dl>
<summary>
<p>This module provides the ability to convert a response into
- an <a href="http://tools.ietf.org/html/rfc2397">RFC2397 data URL</a>.
+ an <a href="https://datatracker.ietf.org/doc/html/rfc2397">RFC2397 data URL</a>.
</p>
<p>Data URLs can be embedded inline within web pages using something
<p>To modify <code>Cache-Control</code> directives other than
<code>max-age</code> (see <a
- href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9">RFC
+ href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.9">RFC
2616 section 14.9</a>), you can use the <directive
module="mod_headers">Header</directive> directive.</p>
<compatibility>Available in version 2.4.17 and later</compatibility>
<summary>
- <p>This module provides HTTP/2 (<a href="https://tools.ietf.org/html/rfc7540">RFC 7540</a>)
+ <p>This module provides HTTP/2 (<a href="https://datatracker.ietf.org/doc/html/rfc7540">RFC 7540</a>)
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://www.rfc-editor.org/rfc/rfc1413"
+ <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
a connection.</p>
</summary>
<context>directory</context></contextlist>
<usage>
- <p>This directive enables <a href="https://www.rfc-editor.org/rfc/rfc1413"
+ <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
connection, where the client machine runs identd or something similar.
This information is logged in the access log using the <code>%...l</code>
<usage>
<p>This directive specifies the timeout duration of an ident
request. The default value of 30 seconds is recommended by <a
- href="https://www.rfc-editor.org/rfc/rfc1413">RFC 1413</a>, mainly because
+ href="https://datatracker.ietf.org/doc/html/rfc1413">RFC 1413</a>, 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://tools.ietf.org/html/rfc8555">RFC 8555</a>).
+ ACME protocol (<a href="https://datatracker.ietf.org/doc/html/rfc8555">RFC 8555</a>).
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
designed for transmitting a binary file in an ASCII (text)
format.</p>
- <p>The <a href="https://www.rfc-editor.org/rfc/rfc2616">HTTP/1.1
+ <p>The <a href="https://datatracker.ietf.org/doc/html/rfc2616">HTTP/1.1
RFC</a>, section 14.11 puts it this way:</p>
<blockquote cite="https://www.rfc-editor.org/rfc/rfc2616">
<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://www.rfc-editor.org/rfc/rfc9110.html#name-content-encoding">RFC 9110</a>.</li>
+ <a href="https://datatracker.ietf.org/doc/html/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
<dt><code>Content-Language:</code></dt>
<dd>The language(s) of the variant, as an Internet standard
- language tag (<a href="https://www.rfc-editor.org/rfc/rfc1766"
+ language tag (<a href="https://datatracker.ietf.org/doc/html/rfc1766"
>RFC 1766</a>). An example is <code>en</code>,
meaning English. If the variant contains more than one
language, they are separated by a comma.</dd>
<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://www.ietf.org/rfc/rfc9110.html#name-upgrade">RFC 9110 - Upgrade</a>).
+ <a href="https://datatracker.ietf.org/doc/html/rfc9110#name-upgrade">RFC 9110 - Upgrade</a>).
See the <a href="#protoupgrade">Protocol Upgrade</a> note below</p>
</td></tr>
<tr><td>mapping</td>
<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://www.rfc-editor.org/rfc/rfc2616">RFC 2616</a> (HTTP/1.1), section
+ href="https://datatracker.ietf.org/doc/html/rfc2616">RFC 2616</a> (HTTP/1.1), section
14.45 for an explanation of <code>Via:</code> header lines.</p>
<ul>
<highlight language="config">ProxyFCGISetEnvIf true VARIABLE</highlight>
The CGI/1.1 specification
- <a href="https://tools.ietf.org/html/rfc3875#section-4.1">does not
+ <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 exist. However, many CGI and FastCGI implementations distinguish (or
allow scripts to distinguish) between the two. The choice of which to use is
<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://tools.ietf.org/html/rfc8297">RFC 8297</a>. This will give
+ <a href="https://datatracker.ietf.org/doc/html/rfc8297">RFC 8297</a>. 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>
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="http://www.ietf.org/rfc/rfc3875">CGI
+ or the <a href="https://datatracker.ietf.org/doc/html/rfc3875">CGI
specification</a>.</p>
<p>SERVER_NAME and SERVER_PORT depend on the values of
<ol>
<li>An HTTP request header field (see <a
- href="http://www.rfc-editor.org/rfc/rfc2616.txt">RFC2616</a>
+ href="https://datatracker.ietf.org/doc/html/rfc2616">RFC2616</a>
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://www.rfc-editor.org/rfc/rfc7568">RFC 7568</a>.</p></li>
+ deprecated in <a href="https://datatracker.ietf.org/doc/html/rfc7568">RFC 7568</a>.</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://www.rfc-editor.org/rfc/rfc2246">RFC 2246</a>.
+ <a href="https://datatracker.ietf.org/doc/html/rfc2246">RFC 2246</a>.
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://www.rfc-editor.org/rfc/rfc4346">RFC 4346</a>.</p></li>
+ <a href="https://datatracker.ietf.org/doc/html/rfc4346">RFC 4346</a>.</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://www.rfc-editor.org/rfc/rfc5246">RFC 5246</a>.</p></li>
+ <a href="https://datatracker.ietf.org/doc/html/rfc5246">RFC 5246</a>.</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://www.rfc-editor.org/rfc/rfc8446">RFC 8446</a>.</p></li>
+ <a href="https://datatracker.ietf.org/doc/html/rfc8446">RFC 8446</a>.</p></li>
<li><code>all</code>
<p>
<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://tools.ietf.org/html/rfc7512">PKCS#11 URIs</a> are
+href="https://datatracker.ietf.org/doc/html/rfc7512">PKCS#11 URIs</a> 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
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://www.rfc-editor.org/rfc/rfc3526">RFC 3526</a>), and hands
+(from <a href="https://datatracker.ietf.org/doc/html/rfc3526">RFC 3526</a>), 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
<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://tools.ietf.org/html/rfc7512">PKCS#11 URIs</a> are recognized as private key
+token. Currently, only <a href="https://datatracker.ietf.org/doc/html/rfc7512">PKCS#11 URIs</a> 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://tools.ietf.org/html/rfc7512">PKCS#11 URIs</a>
+is specified using a <a href="https://datatracker.ietf.org/doc/html/rfc7512">PKCS#11 URIs</a>
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://tools.ietf.org/html/rfc7512">PKCS#11 URIs</a>.
+for <a href="https://datatracker.ietf.org/doc/html/rfc7512">PKCS#11 URIs</a>.
</p>
</usage>
</directivesynopsis>
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://www.rfc-editor.org/rfc/rfc6961">RFC 6961</a>
+<a href="https://datatracker.ietf.org/doc/html/rfc6961">RFC 6961</a>
(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://www.rfc-editor.org/rfc/rfc5077">RFC 5077</a>.
+<a href="https://datatracker.ietf.org/doc/html/rfc5077">RFC 5077</a>.
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="http://www.ietf.org/rfc/rfc2817.txt">RFC 2817</a>, which
+ <a href="https://datatracker.ietf.org/doc/html/rfc2817">RFC 2817</a>, which
allows connections to upgrade from clear text to TLS encryption.</dd>
<dt><module>mod_imagemap</module></dt>
<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://tools.ietf.org/html/rfc7231#appendix-B">
+ <a href="https://datatracker.ietf.org/doc/html/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="http://tools.ietf.org/html/rfc2617#section-3.2.1">
+ <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.
</dd>
<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="http://www.ietf.org/rfc/rfc2409.txt">RFC 2409</a>,
+ parameters from <a href="https://datatracker.ietf.org/doc/html/rfc2409">RFC 2409</a>,
section 6.2:</p>
<example><pre>-----BEGIN DH PARAMETERS-----
MIGHAoGBAP//////////yQ/aoiFowjTExmKLgNwc0SkCTgiKZ8x0Agu+pjsTmyJR
<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="http://tools.ietf.org/html/rfc2045"
+See for instance <a href="https://datatracker.ietf.org/doc/html/rfc2045"
>http://tools.ietf.org/html/rfc2045</a>.</dd>
<dt><a id="SSL3" name="SSL3">[SSL3]</a></dt>
<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="http://ietf.org/rfc/rfc2246.txt"
+1999. See <a href="https://datatracker.ietf.org/doc/html/rfc2246"
>http://ietf.org/rfc/rfc2246.txt</a>.</dd>
<dt><a id="TLS11" name="TLS11">[TLS11]</a></dt>
<dd><q>The TLS Protocol Version 1.1</q>,
-2006. See <a href="http://tools.ietf.org/html/rfc4346"
+2006. See <a href="https://datatracker.ietf.org/doc/html/rfc4346"
>http://tools.ietf.org/html/rfc4346</a>.</dd>
<dt><a id="TLS12" name="TLS12">[TLS12]</a></dt>
<dd><q>The TLS Protocol Version 1.2</q>,
-2008. See <a href="http://tools.ietf.org/html/rfc5246"
+2008. See <a href="https://datatracker.ietf.org/doc/html/rfc5246"
>http://tools.ietf.org/html/rfc5246</a>.</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://tools.ietf.org/html/rfc8446"
+2018. See <a href="https://datatracker.ietf.org/doc/html/rfc8446"
>https://tools.ietf.org/html/rfc8446</a>.</dd>
</dl>
</section>
projects / thirdparty / apache / httpd.git / commitdiff
