From: Rich Bowen Date: Wed, 29 Apr 2026 16:05:21 +0000 (+0000) Subject: docs: Convert RFC links to use new tag; update draft-ietf-tls-esni to RFC 9849 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=baf9004076449245c405cbb06cfc03c9f301d877;p=thirdparty%2Fapache%2Fhttpd.git docs: Convert RFC links to use new tag; update draft-ietf-tls-esni to RFC 9849 git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1933506 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/caching.xml b/docs/manual/caching.xml index 39af97168f..a48e664e46 100644 --- a/docs/manual/caching.xml +++ b/docs/manual/caching.xml @@ -49,8 +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 - 13 of RFC2616. + 2616. mod_cache is aimed at both simple and complex caching configurations, where you are dealing with proxied content, dynamic local content or @@ -105,8 +104,7 @@

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

@@ -159,8 +157,7 @@

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

+ 2616.

Interaction with the Server @@ -324,8 +321,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 + 2616 (Response Cacheability), and can be summed up as follows:

    diff --git a/docs/manual/compliance.xml b/docs/manual/compliance.xml index 7dbfe34b16..f226efa3f3 100644 --- a/docs/manual/compliance.xml +++ b/docs/manual/compliance.xml @@ -137,8 +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. + 2616.
    If-None-Match
    If the provided ETag in the If-None-Match header matches @@ -146,24 +145,21 @@ 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.
    + 2616.
    If-Modified-Since
    If the provided date in the If-Modified-Since header is 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.
    + 2616.
    If-Unmodified-Since
    If the provided date in the If-Modified-Since header is 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.
    + 2616.
    If-Range
    If the provided ETag or date in the If-Range header matches @@ -171,8 +167,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.
    + 2616. @@ -202,8 +197,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.

    + 2616 (Message Length).

    When the Content-Length header is present, the size of the body is declared at the start of the response. If this information @@ -256,8 +250,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.

    + 2616 (Media Types).

    A syntactically valid content type might look as follows:

    @@ -302,8 +295,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.

    + 2616 (Message Length).

    When the Content-Length header is present, the size of the body is declared at the start of the response. HTTP/1.1 defines the @@ -373,8 +365,7 @@ Content-Type:

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

    + 2616 (Expiration Model).

    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 @@ -412,11 +403,9 @@ 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 + 2616 (What is Cacheable), and within the definition for the Pragma header in - - RFC2616 section 14.32 Pragma.

    + 2616 (Pragma).

    Most specifically, should any of the following header combinations exist in the response headers, the response will be rejected:

    @@ -453,11 +442,9 @@ Content-Type: Last-Modified header.

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

    + 2616 (Last-Modified).

    In addition to being checked present, the headers are checked for syntax.

    @@ -488,8 +475,7 @@ Content-Type: forbidden by the administrator.

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

    + 2616 (Vary).

    Some client provided headers, such as User-Agent, can contain thousands or millions of combinations of values over a period diff --git a/docs/manual/env.xml b/docs/manual/env.xml index 4a45dcf7a9..a0529e7959 100644 --- a/docs/manual/env.xml +++ b/docs/manual/env.xml @@ -117,8 +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 - specification.

    + the CGI specification (3875).

@@ -288,9 +287,7 @@
CGI environment variables -

The CGI specification defines a number of environment +

The CGI specification (3875) 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 diff --git a/docs/manual/glossary.xml b/docs/manual/glossary.xml index 5129b962ee..2a7e570be0 100644 --- a/docs/manual/glossary.xml +++ b/docs/manual/glossary.xml @@ -122,8 +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 - RFC which covers the specifics.
+ There is an Informational RFC (3875) which covers the specifics.
See: Dynamic Content with CGI
diff --git a/docs/manual/howto/cgi.xml b/docs/manual/howto/cgi.xml index 2e5f3c179f..bbea81a565 100644 --- a/docs/manual/howto/cgi.xml +++ b/docs/manual/howto/cgi.xml @@ -479,8 +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 - Interface RFC.

+ Common Gateway Interface RFC (3875).

This simple Perl CGI program will display all of the environment variables that are being passed around. Two @@ -572,8 +571,7 @@ foreach my $key (keys %ENV) { For more information

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

+ Common Gateway Interface RFC (3875).

When you post a question about a CGI problem that you're having, whether to a mailing list, or to a newsgroup, make sure diff --git a/docs/manual/howto/http2.xml b/docs/manual/howto/http2.xml index e9dfa6c1b2..909e0be4de 100644 --- a/docs/manual/howto/http2.xml +++ b/docs/manual/howto/http2.xml @@ -41,7 +41,7 @@ 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 7540 - (also available in more readable formatting, YMMV). + (also available in more readable formatting, YMMV (7540)). 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 7540.
    • +
  • 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 7540.
  • 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 (7540).

    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 diff --git a/docs/manual/logs.xml b/docs/manual/logs.xml index fe462da531..78f43aa218 100644 --- a/docs/manual/logs.xml +++ b/docs/manual/logs.xml @@ -363,9 +363,7 @@ CustomLog "logs/access_log" common 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 HTTP - specification (RFC2616 section 10). + possible status codes can be found in the HTTP specification (2616) (RFC2616 section 10).

    2326 (%b)
    diff --git a/docs/manual/mod/core.xml b/docs/manual/mod/core.xml index fc514a5582..d04a75c92a 100644 --- a/docs/manual/mod/core.xml +++ b/docs/manual/mod/core.xml @@ -1281,10 +1281,8 @@ 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 + (7230) and the HTTP Request Header Fields + (7230), 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 option has been added to revert to the legacy behaviors.

    @@ -1303,13 +1301,10 @@ 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 + 7230 (Request Splitting) and + 7230 (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 + 7230 "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 Strict operating @@ -1342,8 +1337,7 @@ EnableSendfile On

    RegisteredMethods|LenientMethods
    -

    RFC 7231 §4.1 "Request Methods" "Overview" requires that +

    7231 "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 LenientMethods option is used, @@ -1369,12 +1363,11 @@ EnableSendfile On

    Allow0.9|Require1.0
    -

    RFC 2616 §19.6 "Compatibility With Previous Versions" had +

    2616 "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 6ce56b0530..c09941f2e6 100644 --- a/docs/manual/mod/mod_auth_basic.xml +++ b/docs/manual/mod/mod_auth_basic.xml @@ -213,8 +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 + 2617 for more details on the format used for this encrypted string.)

    As a consequence of the difference in the stored values between diff --git a/docs/manual/mod/mod_cache.xml b/docs/manual/mod/mod_cache.xml index c96d271b05..ff669a1c8b 100644 --- a/docs/manual/mod/mod_cache.xml +++ b/docs/manual/mod/mod_cache.xml @@ -46,7 +46,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 (2616) HTTP request header. Content is only regenerated from scratch when the content has changed, and not when the cached entry expires.

    @@ -75,9 +75,9 @@

    Under normal operation, mod_cache will respond to and can be controlled by the - Cache-Control + Cache-Control (2616) and - Pragma + Pragma (2616) 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 @@ -91,12 +91,12 @@ by mod_cache when the CacheLock directive is suitably configured. Such responses will contain a - Warning + Warning (2616) 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 (2616) 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 ef1a47be16..1eb6add1b1 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 (3875)

    CGI Environment variables

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

    diff --git a/docs/manual/mod/mod_data.xml b/docs/manual/mod/mod_data.xml index f595bbccee..3342ed05f6 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 2397 (data URL).

    Data URLs can be embedded inline within web pages using something diff --git a/docs/manual/mod/mod_mime.xml b/docs/manual/mod/mod_mime.xml index d749aad8af..a3c58f862e 100644 --- a/docs/manual/mod/mod_mime.xml +++ b/docs/manual/mod/mod_mime.xml @@ -162,10 +162,9 @@ module="mod_mime_magic">MimeMagicFile designed for transmitting a binary file in an ASCII (text) format.

    -

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

    +

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

    -
    +

    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 diff --git a/docs/manual/mod/mod_mime_magic.xml b/docs/manual/mod/mod_mime_magic.xml index ba750e7f94..0fa9b47f3e 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_proxy.xml b/docs/manual/mod/mod_proxy.xml index 1728a5520d..45a1bd6163 100644 --- a/docs/manual/mod/mod_proxy.xml +++ b/docs/manual/mod/mod_proxy.xml @@ -1292,7 +1292,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 diff --git a/docs/manual/mod/mod_proxy_fcgi.xml b/docs/manual/mod/mod_proxy_fcgi.xml index 83dbf557bd..0d4010cc04 100644 --- a/docs/manual/mod/mod_proxy_fcgi.xml +++ b/docs/manual/mod/mod_proxy_fcgi.xml @@ -345,8 +345,7 @@ ProxyFCGISetEnvIf "reqenv('PATH_TRANSLATED') =~ m|(/.*prefix)(\d+)(.*)|" PATH_TR ProxyFCGISetEnvIf true VARIABLE The CGI/1.1 specification - does not - distinguish between a variable with an empty value and a variable that + does not distinguish (3875) 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. diff --git a/docs/manual/mod/mod_rewrite.xml b/docs/manual/mod/mod_rewrite.xml index b86f265c4d..e51fa173e6 100644 --- a/docs/manual/mod/mod_rewrite.xml +++ b/docs/manual/mod/mod_rewrite.xml @@ -597,8 +597,7 @@ AliasMatch "^/myapp" "/opt/myapp-1.2.3" Most are documented in the Expressions doc, in the Environment Variables doc, - or the CGI - specification.

    + or the CGI specification (3875).

    SERVER_NAME and SERVER_PORT depend on the values of UseCanonicalName and diff --git a/docs/manual/mod/mod_ssl.xml b/docs/manual/mod/mod_ssl.xml index af35051d80..6fed4671b2 100644 --- a/docs/manual/mod/mod_ssl.xml +++ b/docs/manual/mod/mod_ssl.xml @@ -970,8 +970,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 +stored in a token. Currently, only PKCS#11 URIs (7512) are recognized as certificate identifiers, and can be used in conjunction with the OpenSSL pkcs11 engine or provider. If SSLCertificateKeyFile is omitted, the @@ -1070,7 +1069,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 (7512) are recognized as private key identifiers, and can be used in conjunction with the OpenSSL pkcs11 engine or provider.

    @@ -2618,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 (7512) 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 (7512).

    @@ -3185,7 +3184,7 @@ httpd -t -D DUMP_SSL_POLICIES

    ECH is specified in - draft-ietf-tls-esni + 9849 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. diff --git a/docs/manual/new_features_2_6.xml b/docs/manual/new_features_2_6.xml index 5fddc7d01c..55ac276365 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 7aba8a8d76..8b189e41f2 100644 --- a/docs/manual/programs/htdigest.xml +++ b/docs/manual/programs/htdigest.xml @@ -58,8 +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. + 2617 for more details.
    username
    diff --git a/docs/manual/ssl/ssl_intro.xml b/docs/manual/ssl/ssl_intro.xml index 76e8e654ce..4471b37f44 100644 --- a/docs/manual/ssl/ssl_intro.xml +++ b/docs/manual/ssl/ssl_intro.xml @@ -649,8 +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.
    +See for instance 2045.
    • [SSL3]
    Alan O. Freier, Philip Karlton, Paul C. Kocher, The SSL Protocol @@ -658,23 +657,19 @@ Version 3.0, 1996. See 6101.
    [TLS1]
    Tim Dierks, Christopher Allen, The TLS Protocol Version 1.0, -1999. See http://ietf.org/rfc/rfc2246.txt.
    +1999. See 2246.
    [TLS11]
    The TLS Protocol Version 1.1, -2006. See http://tools.ietf.org/html/rfc4346.
    +2006. See 4346.
    [TLS12]
    The TLS Protocol Version 1.2, -2008. See http://tools.ietf.org/html/rfc5246.
    +2008. See 5246.
    [TLS13]
    The Transport Layer Security (TLS) Protocol Version 1.3, -2018. See https://tools.ietf.org/html/rfc8446.
    +2018. See 8446.