From: Rich Bowen Date: Tue, 28 Apr 2026 18:56:55 +0000 (+0000) Subject: Standardize all RFC links to datatracker.ietf.org; fix broken external links; update... X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=9e46c5a83e0dffa96832874d6eea84e9d0db6fc4;p=thirdparty%2Fapache%2Fhttpd.git Standardize all RFC links to datatracker.ietf.org; fix broken external links; update AGENTS.md git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1933451 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/AGENTS.md b/docs/manual/AGENTS.md index 893c8d8415..dd44fae854 100644 --- a/docs/manual/AGENTS.md +++ b/docs/manual/AGENTS.md @@ -25,6 +25,17 @@ This is the documentation source for the [Apache HTTP Server](https://httpd.apac ``` - `` — 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 `` for all user-supplied arguments in `` blocks. diff --git a/docs/manual/caching.xml b/docs/manual/caching.xml index b8fb632b3d..39af97168f 100644 --- a/docs/manual/caching.xml +++ b/docs/manual/caching.xml @@ -49,7 +49,7 @@ 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 - Section + Section 13 of RFC2616. mod_cache is aimed at both simple and complex caching configurations, where @@ -105,7 +105,7 @@

The HTTP protocol contains built in support for an in-line caching mechanism - + described by section 13 of RFC2616, and the mod_cache module can be used to take advantage of this.

@@ -159,7 +159,7 @@

Full details of how HTTP caching works can be found in - + Section 13 of RFC2616.

@@ -324,7 +324,7 @@

The full definition of which responses can be cached by an HTTP cache is defined in - + RFC2616 Section 13.4 Response Cacheability, and can be summed up as follows:

diff --git a/docs/manual/compliance.xml b/docs/manual/compliance.xml index 143e1c1195..3e6e7ac36c 100644 --- a/docs/manual/compliance.xml +++ b/docs/manual/compliance.xml @@ -55,7 +55,7 @@

The HTTP protocol follows the robustness principle - as described in RFC1122, + as described in RFC1122, which states "Be liberal in what you accept, and conservative in what you send". As a result of this principle, HTTP clients will compensate for and recover from incorrect or misconfigured responses, or @@ -137,7 +137,7 @@ the ETag of the response, the server should return 412 Precondition Failed. Full details of how to handle an If-Match header can be found in - + RFC2616 section 14.24.

If-None-Match
@@ -146,7 +146,7 @@ 304 Not Modified for GET/HEAD requests, or 412 Precondition Failed for other methods. Full details of how to handle an If-None-Match header can be found in - + RFC2616 section 14.26.
If-Modified-Since
@@ -154,7 +154,7 @@ older than the Last-Modified header of the response, the server should return 304 Not Modified. Full details of how to handle an If-Modified-Since header can be found in - + RFC2616 section 14.25.
If-Unmodified-Since
@@ -162,7 +162,7 @@ newer than the Last-Modified header of the response, the server should return 412 Precondition Failed. Full details of how to handle an If-Unmodified-Since header can be found in - + RFC2616 section 14.28.
If-Range
@@ -171,7 +171,7 @@ is present, the server should return 206 Partial Response. Full details of how to handle an If-Range header can be found in - + RFC2616 section 14.27. @@ -202,7 +202,7 @@

There are a number of ways of determining the length of a response body, described in full in - + RFC2616 section 4.4 Message Length.

When the Content-Length header is present, the size of @@ -256,7 +256,7 @@

The media type of the body is placed in the Content-Type header, and the format of the header is described in full in - + RFC2616 section 3.7 Media Types.

A syntactically valid content type might look as follows:

@@ -302,7 +302,7 @@ Content-Type:

There are a number of ways of determining the length of a response body, described in full in - + RFC2616 section 4.4 Message Length.

When the Content-Length header is present, the size of @@ -373,7 +373,7 @@ Content-Type:

Full details of how a freshness lifetime is calculated is described in full in - + RFC2616 section 13.2 Expiration Model.

During the freshness lifetime, a cache does not need to contact the @@ -412,10 +412,10 @@ Content-Type:

Full details of how content may be declared uncacheable is described in full in - + RFC2616 section 14.9.1 What is Cacheable, and within the definition for the Pragma header in - + RFC2616 section 14.32 Pragma.

Most specifically, should any of the following header combinations @@ -453,10 +453,10 @@ Content-Type: Last-Modified header.

The ETag header is described in full in - + RFC2616 section 14.19 Etag, and the Last-Modified header is described in full in - + RFC2616 section 14.29 Last-Modified.

In addition to being checked present, the headers are checked for @@ -488,7 +488,7 @@ Content-Type: forbidden by the administrator.

The Vary header is described in full in - + RFC2616 section 14.44 Vary.

Some client provided headers, such as User-Agent, diff --git a/docs/manual/env.xml b/docs/manual/env.xml index 6eeaef42ee..4a45dcf7a9 100644 --- a/docs/manual/env.xml +++ b/docs/manual/env.xml @@ -117,7 +117,7 @@ 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 CGI + the CGI specification.

diff --git a/docs/manual/glossary.xml b/docs/manual/glossary.xml index bc07bdd572..a5abdde4f5 100644 --- a/docs/manual/glossary.xml +++ b/docs/manual/glossary.xml @@ -122,7 +122,7 @@ Gateway Interface (CGI)
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 Informational + There is an Informational RFC which covers the specifics.
See: Dynamic Content with CGI
@@ -261,7 +261,7 @@ (HTTP)
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 RFC 2616. + defined by RFC 2616.
HTTPS
@@ -416,7 +416,7 @@ in processing the SSL handshake. It was added to SSL starting with the TLS extensions, RFC 3546.
See: the SSL FAQ - and RFC 3546 + and RFC 3546
Server Side @@ -477,7 +477,7 @@ (URI)
A compact string of characters for identifying an abstract or physical resource. It is formally defined by RFC 2396. URIs used on the + href="https://datatracker.ietf.org/doc/html/rfc2396">RFC 2396. URIs used on the world-wide web are commonly referred to as URLs.
diff --git a/docs/manual/howto/cgi.xml b/docs/manual/howto/cgi.xml index 25fa99032c..fee0f23865 100644 --- a/docs/manual/howto/cgi.xml +++ b/docs/manual/howto/cgi.xml @@ -376,7 +376,7 @@ print "Hello, World.";

When you miss HTTP headers from the environment, make sure they are formatted according to - RFC 2616, + RFC 2616, 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.

@@ -479,7 +479,7 @@ print "Hello, World.";

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 - Common Gateway + Common Gateway Interface RFC.

This simple Perl CGI program will display all of the @@ -572,7 +572,7 @@ foreach my $key (keys %ENV) { For more information

The current CGI specification is available in the - Common Gateway + Common Gateway Interface RFC.

When you post a question about a CGI problem that you're diff --git a/docs/manual/howto/http2.xml b/docs/manual/howto/http2.xml index d52cccdf60..40804e2b77 100644 --- a/docs/manual/howto/http2.xml +++ b/docs/manual/howto/http2.xml @@ -40,8 +40,8 @@ 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.

There has been a lot written about HTTP/2 and how it works. The most normative is, of course, - its RFC 7540 - (also available in more readable formatting, YMMV). + its RFC 7540 + (also available in more readable formatting, YMMV). So, there you'll find the nuts and bolts.

But, as RFC do, it's not really a good thing to read first. It's better to first understand what a thing wants to do and then read the RFC about how it is done. A much @@ -53,8 +53,8 @@

  • HTTP/2 is a binary protocol, 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 question.
  • h2 is HTTP/2 over TLS (protocol negotiation via ALPN).
  • h2c is HTTP/2 over TCP.
    • -
  • A frame 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 section.
    • -
  • A stream 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 section.
    • +
  • A frame 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 section.
    • +
  • A stream 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 section.
  • HTTP/2 is able to run multiple streams 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).
    • @@ -129,7 +129,7 @@ Protocols http/1.1 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 HTTP/2 TLS reject list.

    + the ones listed in the HTTP/2 TLS reject list.

    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 @@ -294,7 +294,7 @@ H2Push Off Early Hints

    An alternative to PUSHing resources is to send Link headers to the client before the response is even ready. This uses the HTTP feature called "Early Hints" and - is described in RFC 8297.

    + is described in RFC 8297.

    In order to use this, you need to explicitly enable it on the server via

    H2EarlyHints on diff --git a/docs/manual/logs.xml b/docs/manual/logs.xml index 75f4d7e527..8f7f0bd416 100644 --- a/docs/manual/logs.xml +++ b/docs/manual/logs.xml @@ -364,7 +364,7 @@ CustomLog "logs/access_log" common 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 HTTP + href="https://datatracker.ietf.org/doc/html/rfc2616">HTTP specification (RFC2616 section 10).
    2326 (%b)
    diff --git a/docs/manual/misc/perf-tuning.xml b/docs/manual/misc/perf-tuning.xml index 66837517cd..68262211d3 100644 --- a/docs/manual/misc/perf-tuning.xml +++ b/docs/manual/misc/perf-tuning.xml @@ -708,7 +708,7 @@ DirectoryIndex index.cgi index.pl index.shtml index.html Lingering Close

    As discussed in + href="https://datatracker.ietf.org/doc/html/draft-ietf-http-connection-00"> draft-ietf-http-connection-00.txt section 8, in order for an HTTP server to reliably implement the protocol, it needs to shut down each direction of the diff --git a/docs/manual/misc/relevant_standards.xml b/docs/manual/misc/relevant_standards.xml index 244023c623..699c1fa813 100644 --- a/docs/manual/misc/relevant_standards.xml +++ b/docs/manual/misc/relevant_standards.xml @@ -42,8 +42,8 @@ http://www.rfc-editor.org/errata.php - RFC Errata

  • - - http://ftp.ics.uci.edu/pub/ietf/http/#RFC - A pre-compiled list + + https://httpwg.org/specs/ - A pre-compiled list of HTTP related RFCs
    • @@ -60,7 +60,7 @@ basic web server complies with the following IETF recommendations:

    -
    RFC 1945 +
    RFC 1945 (Informational)
    The Hypertext Transfer Protocol (HTTP) is an application-level @@ -68,20 +68,20 @@ collaborative, hypermedia information systems. This documents HTTP/1.0.
    -
    RFC 2616 +
    RFC 2616 (Standards Track)
    The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This documents HTTP/1.1.
    -
    RFC 2396 +
    RFC 2396 (Standards Track)
    A Uniform Resource Identifier (URI) is a compact string of characters for identifying an abstract or physical resource.
    -
    RFC 4346 +
    RFC 4346 (Standards Track)
    The TLS protocol provides communications security over the @@ -97,7 +97,7 @@ the following IETF and W3C recommendations:

    -
    RFC 2854 +
    RFC 2854 (Informational)
    This document summarizes the history of HTML development, @@ -146,7 +146,7 @@ follows the following IETF recommendations:

    -
    RFC 2617 +
    RFC 2617 (Standards Track)
    "HTTP/1.0", includes the specification for a Basic @@ -177,14 +177,14 @@
    BCP 47 (Best Current Practice), - RFC 3066
    + RFC 3066
    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.
    -
    RFC 3282 +
    RFC 3282 (Standards Track)
    This document defines a "Content-language:" header, for use in diff --git a/docs/manual/mod/core.xml b/docs/manual/mod/core.xml index 1e73ab2ee6..74084176ad 100644 --- a/docs/manual/mod/core.xml +++ b/docs/manual/mod/core.xml @@ -1281,9 +1281,9 @@ EnableSendfile On

    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 deprecated the Unsafe @@ -1303,12 +1303,12 @@ EnableSendfile On

    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 grammar rules of the @@ -1342,7 +1342,7 @@ EnableSendfile On

    RegisteredMethods|LenientMethods
    -

    RFC 7231 §4.1 "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. @@ -1369,12 +1369,12 @@ EnableSendfile On

    Allow0.9|Require1.0
    -

    RFC 2616 §19.6 "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 - RFC 7230 Appendix A. The Require1.0 option allows the user to remove support of the default Allow0.9 option's behavior.

    diff --git a/docs/manual/mod/mod_auth_basic.xml b/docs/manual/mod/mod_auth_basic.xml index 4f0a3271ba..6ce56b0530 100644 --- a/docs/manual/mod/mod_auth_basic.xml +++ b/docs/manual/mod/mod_auth_basic.xml @@ -213,7 +213,7 @@ Digest Authentication was in force instead of Basic Authentication. Authentication case, the value associated with each stored username must be an encrypted string composed from the username, realm name, and password. (See - + RFC 2617, Section 3.2.2.2 for more details on the format used for this encrypted string.)

    diff --git a/docs/manual/mod/mod_auth_digest.xml b/docs/manual/mod/mod_auth_digest.xml index 250b317a05..421c0af5b4 100644 --- a/docs/manual/mod/mod_auth_digest.xml +++ b/docs/manual/mod/mod_auth_digest.xml @@ -31,7 +31,7 @@

    This module implements HTTP Digest Authentication - (RFC2617), and + (RFC2617), and provides an alternative to mod_auth_basic where the password is not transmitted as cleartext. However, this does not lead to a significant security advantage over diff --git a/docs/manual/mod/mod_autht_jwt.xml b/docs/manual/mod/mod_autht_jwt.xml index 87815d4086..6c33d901a5 100644 --- a/docs/manual/mod/mod_autht_jwt.xml +++ b/docs/manual/mod/mod_autht_jwt.xml @@ -32,7 +32,7 @@

    This module provides token parsing front-ends such as mod_auth_bearer the ability to authenticate users by verifying a JWT token as described in - RFC 7519.

    + RFC 7519.

    A JWT token is read from the Authorization header with an auth-scheme of Bearer.

    diff --git a/docs/manual/mod/mod_cache.xml b/docs/manual/mod/mod_cache.xml index b50c7203aa..693c96657d 100644 --- a/docs/manual/mod/mod_cache.xml +++ b/docs/manual/mod/mod_cache.xml @@ -39,7 +39,7 @@ variable.

    mod_cache implements an RFC 2616 compliant + href="https://datatracker.ietf.org/doc/html/rfc2616">RFC 2616 compliant HTTP content caching filter, with support for the caching of content negotiated responses containing the Vary header.

    @@ -47,7 +47,7 @@ stale or expired content is still fresh, and can represent a significant performance boost when the origin server supports conditional requests by honoring the - If-None-Match + If-None-Match HTTP request header. Content is only regenerated from scratch when the content has changed, and not when the cached entry expires.

    @@ -76,9 +76,9 @@

    Under normal operation, mod_cache will respond to and can be controlled by the - Cache-Control + Cache-Control and - Pragma + Pragma headers sent from a client in a request, or from a server within a response. Under exceptional circumstances, mod_cache can be configured to override these headers @@ -92,12 +92,12 @@ by mod_cache when the CacheLock directive is suitably configured. Such responses will contain a - Warning + Warning 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 mod_cache. Such responses will contain a - Warning + Warning HTTP header with a 111 response code.

    mod_cache requires the services of one or more diff --git a/docs/manual/mod/mod_cgi.xml b/docs/manual/mod/mod_cgi.xml index b6b28e1044..ef1a47be16 100644 --- a/docs/manual/mod/mod_cgi.xml +++ b/docs/manual/mod/mod_cgi.xml @@ -58,11 +58,11 @@ AddHandler Running CGI programs under different user IDs -CGI Specification +CGI Specification

    CGI Environment variables

    The server will set the CGI environment variables as described - in the CGI specification, + in the CGI specification, with the following provisions:

    diff --git a/docs/manual/mod/mod_data.xml b/docs/manual/mod/mod_data.xml index b4852fba15..f595bbccee 100644 --- a/docs/manual/mod/mod_data.xml +++ b/docs/manual/mod/mod_data.xml @@ -31,7 +31,7 @@

    This module provides the ability to convert a response into - an RFC2397 data URL. + an RFC2397 data URL.

    Data URLs can be embedded inline within web pages using something diff --git a/docs/manual/mod/mod_expires.xml b/docs/manual/mod/mod_expires.xml index 40d488ab52..f83b4b1f8c 100644 --- a/docs/manual/mod/mod_expires.xml +++ b/docs/manual/mod/mod_expires.xml @@ -47,7 +47,7 @@ criteria

    To modify Cache-Control directives other than max-age (see RFC + href="https://datatracker.ietf.org/doc/html/rfc2616#section-14.9">RFC 2616 section 14.9), you can use the Header directive.

    diff --git a/docs/manual/mod/mod_http2.xml b/docs/manual/mod/mod_http2.xml index bec2af3523..85d526baeb 100644 --- a/docs/manual/mod/mod_http2.xml +++ b/docs/manual/mod/mod_http2.xml @@ -30,7 +30,7 @@ Available in version 2.4.17 and later -

    This module provides HTTP/2 (RFC 7540) +

    This module provides HTTP/2 (RFC 7540) support for the Apache HTTP Server.

    This module relies on libnghttp2 diff --git a/docs/manual/mod/mod_ident.xml b/docs/manual/mod/mod_ident.xml index 7bc4551612..4502a6a3d5 100644 --- a/docs/manual/mod/mod_ident.xml +++ b/docs/manual/mod/mod_ident.xml @@ -29,7 +29,7 @@ ident_module

    -

    This module queries an This module queries an RFC 1413 compatible daemon on a remote host to look up the owner of a connection.

     @@ -45,7 +45,7 @@ user directory -

    This directive enables This directive enables RFC 1413-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 %...l @@ -77,7 +77,7 @@ user

    This directive specifies the timeout duration of an ident request. The default value of 30 seconds is recommended by RFC 1413, mainly because + href="https://datatracker.ietf.org/doc/html/rfc1413">RFC 1413, mainly because of possible network latency. However, you may want to adjust the timeout value according to your local network speed.

     diff --git a/docs/manual/mod/mod_md.xml b/docs/manual/mod/mod_md.xml index e024816fbb..68ea479d22 100644 --- a/docs/manual/mod/mod_md.xml +++ b/docs/manual/mod/mod_md.xml @@ -34,7 +34,7 @@

    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 (RFC 8555). + ACME protocol (RFC 8555). 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 diff --git a/docs/manual/mod/mod_mime.xml b/docs/manual/mod/mod_mime.xml index a34c8f17f2..61244eaa5e 100644 --- a/docs/manual/mod/mod_mime.xml +++ b/docs/manual/mod/mod_mime.xml @@ -162,7 +162,7 @@ module="mod_mime_magic">MimeMagicFile designed for transmitting a binary file in an ASCII (text) format.

    -

    The HTTP/1.1 +

    The HTTP/1.1 RFC, section 14.11 puts it this way:

    diff --git a/docs/manual/mod/mod_mime_magic.xml b/docs/manual/mod/mod_mime_magic.xml index 18ff7d2633..ba750e7f94 100644 --- a/docs/manual/mod/mod_mime_magic.xml +++ b/docs/manual/mod/mod_mime_magic.xml @@ -294,7 +294,7 @@ using the specified magic file
  • Not RFC-compliant: Standards documents consistently recommend against setting Content-Encoding for files that are already compressed (such as .zip or .gz files). See - RFC 9110.
    • + RFC 9110.
  • Breaks content integrity: When Content-Encoding is set, most HTTP clients will decompress the file before writing it to disk. This diff --git a/docs/manual/mod/mod_negotiation.xml b/docs/manual/mod/mod_negotiation.xml index d5f0c3f308..0a166f64e4 100644 --- a/docs/manual/mod/mod_negotiation.xml +++ b/docs/manual/mod/mod_negotiation.xml @@ -76,7 +76,7 @@ Negotiation
    Content-Language:
    The language(s) of the variant, as an Internet standard - language tag (RFC 1766). An example is en, meaning English. If the variant contains more than one language, they are separated by a comma.
    diff --git a/docs/manual/mod/mod_proxy.xml b/docs/manual/mod/mod_proxy.xml index 79eb5c25ce..606778db93 100644 --- a/docs/manual/mod/mod_proxy.xml +++ b/docs/manual/mod/mod_proxy.xml @@ -1286,7 +1286,7 @@ ProxyPass "/example" "http://backend.example.com" max=20 ttl=120 retry=300

    Protocol accepted by mod_proxy_http or mod_proxy_wstunnel for the HTTP Upgrade mechanism upon negotiation by the HTTP client/browser (per - RFC 9110 - Upgrade). + RFC 9110 - Upgrade). See the Protocol Upgrade note below

    mapping @@ -2089,7 +2089,7 @@ header for proxied requests

    This directive controls the use of the Via: HTTP header by the proxy. Its intended use is to control the flow of proxy requests along a chain of proxy servers. See RFC 2616 (HTTP/1.1), section + href="https://datatracker.ietf.org/doc/html/rfc2616">RFC 2616 (HTTP/1.1), section 14.45 for an explanation of Via: header lines.

      diff --git a/docs/manual/mod/mod_proxy_fcgi.xml b/docs/manual/mod/mod_proxy_fcgi.xml index 9d8f54e7de..83dbf557bd 100644 --- a/docs/manual/mod/mod_proxy_fcgi.xml +++ b/docs/manual/mod/mod_proxy_fcgi.xml @@ -345,7 +345,7 @@ ProxyFCGISetEnvIf "reqenv('PATH_TRANSLATED') =~ m|(/.*prefix)(\d+)(.*)|" PATH_TR ProxyFCGISetEnvIf true VARIABLE The CGI/1.1 specification - does not + does not distinguish 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 diff --git a/docs/manual/mod/mod_proxy_http2.xml b/docs/manual/mod/mod_proxy_http2.xml index b4d39feaaf..160d98c3e7 100644 --- a/docs/manual/mod/mod_proxy_http2.xml +++ b/docs/manual/mod/mod_proxy_http2.xml @@ -123,7 +123,7 @@ ProxyPassReverse "/app" "http://app.example.com" Link headers.

      If available, they may do so using the "103 Early Hints" intermediate responses as specified in - RFC 8297. This will give + RFC 8297. 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.

      diff --git a/docs/manual/mod/mod_rewrite.xml b/docs/manual/mod/mod_rewrite.xml index 4a7e38a059..b86f265c4d 100644 --- a/docs/manual/mod/mod_rewrite.xml +++ b/docs/manual/mod/mod_rewrite.xml @@ -597,7 +597,7 @@ AliasMatch "^/myapp" "/opt/myapp-1.2.3" Most are documented in the Expressions doc, in the Environment Variables doc, - or the CGI + or the CGI specification.

      SERVER_NAME and SERVER_PORT depend on the values of diff --git a/docs/manual/mod/mod_setenvif.xml b/docs/manual/mod/mod_setenvif.xml index 71eebf6f26..f83ae42c2e 100644 --- a/docs/manual/mod/mod_setenvif.xml +++ b/docs/manual/mod/mod_setenvif.xml @@ -156,7 +156,7 @@ SetEnvIfNoCase User-Agent Robot is_a_robot

      1. An HTTP request header field (see RFC2616 + href="https://datatracker.ietf.org/doc/html/rfc2616">RFC2616 for more information about these); for example: Host, User-Agent, Referer, and Accept-Language. A regular expression may be diff --git a/docs/manual/mod/mod_ssl.xml b/docs/manual/mod/mod_ssl.xml index 433bb453ab..c23ee79fd3 100644 --- a/docs/manual/mod/mod_ssl.xml +++ b/docs/manual/mod/mod_ssl.xml @@ -657,29 +657,29 @@ The available (case-insensitive) protocols are:

        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 RFC 7568.

        2. + deprecated in RFC 7568.

      2. TLSv1

        This is the Transport Layer Security (TLS) protocol, version 1.0. It is the successor to SSLv3 and is defined in - RFC 2246. + RFC 2246. It is supported by nearly every client.

      3. TLSv1.1 (when using OpenSSL 1.0.1 and later)

        A revision of the TLS 1.0 protocol, as defined in - RFC 4346.

        4. + RFC 4346.

      4. TLSv1.2 (when using OpenSSL 1.0.1 and later)

        A revision of the TLS 1.1 protocol, as defined in - RFC 5246.

        5. + RFC 5246.

      5. TLSv1.3 (when using OpenSSL 1.1.1 and later)

        A new version of the TLS protocol, as defined in - RFC 8446.

        6. + RFC 8446.

      6. all

        @@ -971,7 +971,7 @@ key is encrypted, the pass phrase dialog is forced at startup time.

        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 PKCS#11 URIs are +href="https://datatracker.ietf.org/doc/html/rfc7512">PKCS#11 URIs are recognized as certificate identifiers, and can be used in conjunction with the OpenSSL pkcs11 engine or provider. If SSLCertificateKeyFile is omitted, the @@ -986,7 +986,7 @@ Beginning with version 2.4.7, mod_ssl makes use of 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 RFC 3526), and hands +(from RFC 3526), 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 @@ -1070,7 +1070,7 @@ key file.

        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 PKCS#11 URIs are recognized as private key +token. Currently, only PKCS#11 URIs are recognized as private key identifiers, and can be used in conjunction with the OpenSSL pkcs11 engine or provider.

        @@ -2617,11 +2617,11 @@ SSLCryptoDevice ubsec

        With OpenSSL 3.0 or later, if no engine is specified but the key or certificate -is specified using a PKCS#11 URIs +is specified using a PKCS#11 URIs 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 STORE method -for PKCS#11 URIs. +for PKCS#11 URIs.

        @@ -2819,7 +2819,7 @@ OCSP response for a single cert. For server certificates with intermediate 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 -RFC 6961 +RFC 6961 (TLS Multiple Certificate Status Extension).

        @@ -3002,7 +3002,7 @@ One potential use is when a proxy is used for retrieving OCSP queries.

        Optionally configures a secret key for encrypting and decrypting TLS session tickets, as defined in -RFC 5077. +RFC 5077. Primarily suitable for clustered environments where TLS sessions information should be shared between multiple nodes. For single-instance httpd setups, it is recommended to not configure a ticket key file, but to diff --git a/docs/manual/new_features_2_2.xml b/docs/manual/new_features_2_2.xml index 49760ddb1b..7b165ba3b2 100644 --- a/docs/manual/new_features_2_2.xml +++ b/docs/manual/new_features_2_2.xml @@ -149,7 +149,7 @@

        mod_ssl
        Added a support for - RFC 2817, which + RFC 2817, which allows connections to upgrade from clear text to TLS encryption.
        mod_imagemap
        diff --git a/docs/manual/new_features_2_6.xml b/docs/manual/new_features_2_6.xml index 54cff96b5f..5fddc7d01c 100644 --- a/docs/manual/new_features_2_6.xml +++ b/docs/manual/new_features_2_6.xml @@ -38,7 +38,7 @@
        The ContentDigest directive and support for the the Content-MD5 header has been removed from the server, corresponding with the removal of this header from - + RFC7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content.
        diff --git a/docs/manual/programs/htdigest.xml b/docs/manual/programs/htdigest.xml index 1c29815040..7aba8a8d76 100644 --- a/docs/manual/programs/htdigest.xml +++ b/docs/manual/programs/htdigest.xml @@ -58,7 +58,7 @@
        realm
        The realm name to which the user name belongs. See - + http://tools.ietf.org/html/rfc2617#section-3.2.1 for more details.
        diff --git a/docs/manual/ssl/ssl_faq.xml b/docs/manual/ssl/ssl_faq.xml index c9dc24b8eb..37c6d27d18 100644 --- a/docs/manual/ssl/ssl_faq.xml +++ b/docs/manual/ssl/ssl_faq.xml @@ -762,7 +762,7 @@ SetEnvIf User-Agent "MSIE [2-5]" \

        To generate custom DH parameters, use the openssl dhparam 1024 command. Alternatively, you can use the following standard 1024-bit DH - parameters from RFC 2409, + parameters from RFC 2409, section 6.2:

        -----BEGIN DH PARAMETERS-----
 MIGHAoGBAP//////////yQ/aoiFowjTExmKLgNwc0SkCTgiKZ8x0Agu+pjsTmyJR
diff --git a/docs/manual/ssl/ssl_intro.xml b/docs/manual/ssl/ssl_intro.xml
index 8a46237184..878152b27a 100644
--- a/docs/manual/ssl/ssl_intro.xml
+++ b/docs/manual/ssl/ssl_intro.xml
@@ -649,7 +649,7 @@ href="https://en.wikipedia.org/wiki/PKCS"
 
        [MIME]
        
 
        N. Freed, N. Borenstein, Multipurpose Internet Mail Extensions
 (MIME) Part One: Format of Internet Message Bodies, RFC2045.
-See for instance http://tools.ietf.org/html/rfc2045.
        
 
 
        [SSL3]
        
@@ -660,22 +660,22 @@ href="https://datatracker.ietf.org/doc/html/rfc6101"
 
 
        [TLS1]
        
 
        Tim Dierks, Christopher Allen, The TLS Protocol Version 1.0,
-1999. See http://ietf.org/rfc/rfc2246.txt.
        
 
 
        [TLS11]
        
 
        The TLS Protocol Version 1.1,
-2006. See http://tools.ietf.org/html/rfc4346.
        
 
 
        [TLS12]
        
 
        The TLS Protocol Version 1.2,
-2008. See http://tools.ietf.org/html/rfc5246.
        
 
 
        [TLS13]
        
 
        The Transport Layer Security (TLS) Protocol Version 1.3,
-2018. See https://tools.ietf.org/html/rfc8446.