From: Rich Bowen Date: Wed, 29 Apr 2026 15:31:13 +0000 (+0000) Subject: docs: Convert RFC links to use new tag X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=779fcf9f6a9168affd75cb2b7be5671c44c8ea25;p=thirdparty%2Fapache%2Fhttpd.git docs: Convert RFC links to use new tag git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1933502 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/compliance.xml b/docs/manual/compliance.xml index 3e6e7ac36c..7dbfe34b16 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 1122, 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 diff --git a/docs/manual/glossary.xml b/docs/manual/glossary.xml index a5abdde4f5..5129b962ee 100644 --- a/docs/manual/glossary.xml +++ b/docs/manual/glossary.xml @@ -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 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 3546
Server Side @@ -476,8 +476,7 @@ id="uniformresourceidentifier">Uniform Resource Identifier (URI)
A compact string of characters for identifying an abstract or physical - resource. It is formally defined by RFC 2396. URIs used on the + resource. It is formally defined by 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 fee0f23865..2e5f3c179f 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, + 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.

diff --git a/docs/manual/howto/http2.xml b/docs/manual/howto/http2.xml index 40804e2b77..e9dfa6c1b2 100644 --- a/docs/manual/howto/http2.xml +++ b/docs/manual/howto/http2.xml @@ -40,7 +40,7 @@ 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 + its 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 @@ -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 8297.

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

H2EarlyHints on diff --git a/docs/manual/misc/relevant_standards.xml b/docs/manual/misc/relevant_standards.xml index 699c1fa813..05d1bc9e18 100644 --- a/docs/manual/misc/relevant_standards.xml +++ b/docs/manual/misc/relevant_standards.xml @@ -60,7 +60,7 @@ basic web server complies with the following IETF recommendations:

-
RFC 1945 +
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 +
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 +
2396 (Standards Track)
A Uniform Resource Identifier (URI) is a compact string of characters for identifying an abstract or physical resource.
-
RFC 4346 +
4346 (Standards Track)
The TLS protocol provides communications security over the @@ -97,7 +97,7 @@ the following IETF and W3C recommendations:

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

-
RFC 2617 +
2617 (Standards Track)
"HTTP/1.0", includes the specification for a Basic @@ -177,14 +177,14 @@
BCP 47 (Best Current Practice), - RFC 3066
+ 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 +
3282 (Standards Track)
This document defines a "Content-language:" header, for use in diff --git a/docs/manual/mod/mod_auth_digest.xml b/docs/manual/mod/mod_auth_digest.xml index 421c0af5b4..471922439c 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 + (2617), 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 6c33d901a5..9b418ae15c 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.

+ 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 693c96657d..c96d271b05 100644 --- a/docs/manual/mod/mod_cache.xml +++ b/docs/manual/mod/mod_cache.xml @@ -38,8 +38,7 @@ wish to limit access by client host name, address or environment variable. -

mod_cache implements an RFC 2616 compliant +

mod_cache implements an 2616 compliant HTTP content caching filter, with support for the caching of content negotiated responses containing the Vary header.

diff --git a/docs/manual/mod/mod_expires.xml b/docs/manual/mod/mod_expires.xml index f83b4b1f8c..2f356ae890 100644 --- a/docs/manual/mod/mod_expires.xml +++ b/docs/manual/mod/mod_expires.xml @@ -46,9 +46,8 @@ criteria source.

To modify Cache-Control directives other than - max-age (see RFC - 2616 section 14.9), you can use the max-age (see 2616, + section 14.9), you can use the Header directive.

When the Expires header is already part of the response diff --git a/docs/manual/mod/mod_http2.xml b/docs/manual/mod/mod_http2.xml index 85d526baeb..d979c22a31 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 (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 4502a6a3d5..d51528c257 100644 --- a/docs/manual/mod/mod_ident.xml +++ b/docs/manual/mod/mod_ident.xml @@ -29,8 +29,7 @@ ident_module

-

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

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

 mod_log_config @@ -45,8 +44,7 @@ user directory -

This directive enables RFC 1413-compliant logging of the remote user name for each +

This directive enables 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 format string.

@@ -76,8 +74,7 @@ user directory

This directive specifies the timeout duration of an ident - request. The default value of 30 seconds is recommended by RFC 1413, mainly because + request. The default value of 30 seconds is recommended by 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 68ea479d22..6a17897631 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 (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_negotiation.xml b/docs/manual/mod/mod_negotiation.xml index f3eb6a79e4..c7f3aae6d8 100644 --- a/docs/manual/mod/mod_negotiation.xml +++ b/docs/manual/mod/mod_negotiation.xml @@ -76,8 +76,7 @@ Negotiation

Content-Language:
The language(s) of the variant, as an Internet standard - language tag (RFC 1766). An example is en, + language tag (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 24c75a3e45..1728a5520d 100644 --- a/docs/manual/mod/mod_proxy.xml +++ b/docs/manual/mod/mod_proxy.xml @@ -2094,8 +2094,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 + proxy requests along a chain of proxy servers. See 2616 (HTTP/1.1), section 14.45 for an explanation of Via: header lines.

    diff --git a/docs/manual/mod/mod_proxy_http2.xml b/docs/manual/mod/mod_proxy_http2.xml index 160d98c3e7..5ffb194def 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 + 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_setenvif.xml b/docs/manual/mod/mod_setenvif.xml index f83ae42c2e..51df2ecce4 100644 --- a/docs/manual/mod/mod_setenvif.xml +++ b/docs/manual/mod/mod_setenvif.xml @@ -155,8 +155,7 @@ SetEnvIfNoCase User-Agent Robot is_a_robot following things:

      -
    1. An HTTP request header field (see RFC2616 +
    2. An HTTP request header field (see 2616 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 5178f9ade7..af35051d80 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.

      3. + deprecated in 7568.

    3. TLSv1

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

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

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

      5. + 4346.

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

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

      6. + 5246.

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

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

      7. + 8446.

    7. all

      @@ -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 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 @@ -2820,7 +2820,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 +6961 (TLS Multiple Certificate Status Extension).

      @@ -3003,7 +3003,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. +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 7b165ba3b2..31d00876d4 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 + 2817, which allows connections to upgrade from clear text to TLS encryption.
      mod_imagemap
      diff --git a/docs/manual/ssl/ssl_faq.xml b/docs/manual/ssl/ssl_faq.xml index 37c6d27d18..a412b27dd6 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 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 878152b27a..76e8e654ce 100644
--- a/docs/manual/ssl/ssl_intro.xml
+++ b/docs/manual/ssl/ssl_intro.xml
@@ -654,9 +654,7 @@ See for instance [SSL3]
 
      Alan O. Freier, Philip Karlton, Paul C. Kocher, The SSL Protocol
-Version 3.0, 1996. See RFC 6101.
      
+Version 3.0, 1996. See 6101.
[TLS1]
Tim Dierks, Christopher Allen, The TLS Protocol Version 1.0,