Update to use rfc-editor.org URLs throughout.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1924775 13f79535-47bb-0310-9956-ffa450edef68

diff --git a/docs/manual/mod/mod_autht_jwt.xml b/docs/manual/mod/mod_autht_jwt.xml
index 08c49ba8bc5ce3199173aebfca9213d827000c59..87815d4086835fac5b24280282051f5f70b12b80 100644 (file)
--- a/docs/manual/mod/mod_autht_jwt.xml
+++ b/docs/manual/mod/mod_autht_jwt.xml
@@ -32,7 +32,7 @@
     <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="http://www.ietf.org/rfc/rfc7519.txt">RFC 7519</a>.</p>
+    <a href="https://www.rfc-editor.org/rfc/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>

diff --git a/docs/manual/mod/mod_cache.xml b/docs/manual/mod/mod_cache.xml
index 5c1f5134debb2f9dccae9384fbc34d50887e4f55..23471d828a15bf67625805db8998f393817ab06f 100644 (file)
--- a/docs/manual/mod/mod_cache.xml
+++ b/docs/manual/mod/mod_cache.xml
@@ -39,7 +39,7 @@
     variable.</note>
 
     <p><module>mod_cache</module> implements an <a
-    href="http://www.ietf.org/rfc/rfc2616.txt">RFC 2616</a> compliant
+    href="https://www.rfc-editor.org/rfc/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>
 

diff --git a/docs/manual/mod/mod_ident.xml b/docs/manual/mod/mod_ident.xml
index 82b33218e1c477f76b260cec97480893d2e9c34d..7bc455161279c91f5e149a4a93e915d99fd11db4 100644 (file)
--- a/docs/manual/mod/mod_ident.xml
+++ b/docs/manual/mod/mod_ident.xml
@@ -29,7 +29,7 @@
 <identifier>ident_module</identifier>
 
 <summary>
-    <p>This module queries an <a href="http://www.ietf.org/rfc/rfc1413.txt"
+    <p>This module queries an <a href="https://www.rfc-editor.org/rfc/rfc1413"
     >RFC 1413</a> compatible daemon on a remote host to look up the owner of
     a connection.</p>
 </summary>
@@ -45,7 +45,7 @@ user</description>
 <context>directory</context></contextlist>
 
 <usage>
-    <p>This directive enables <a href="http://www.ietf.org/rfc/rfc1413.txt"
+    <p>This directive enables <a href="https://www.rfc-editor.org/rfc/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>
@@ -77,7 +77,7 @@ user</description>
 <usage>
     <p>This directive specifies the timeout duration of an ident
     request. The default value of 30 seconds is recommended by <a
-    href="http://www.ietf.org/rfc/rfc1413.txt">RFC 1413</a>, mainly because
+    href="https://www.rfc-editor.org/rfc/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>

diff --git a/docs/manual/mod/mod_mime.xml b/docs/manual/mod/mod_mime.xml
index c73b953d1aa94ca5928289016deb4fac0509c6d9..f774d3b562d6d324d262fde446edeae46c88335a 100644 (file)
--- a/docs/manual/mod/mod_mime.xml
+++ b/docs/manual/mod/mod_mime.xml
@@ -161,10 +161,10 @@ module="mod_mime_magic">MimeMagicFile</directive></seealso>
     designed for transmitting a binary file in an ASCII (text)
     format.</p>
 
-    <p>The <a href="http://www.ietf.org/rfc/rfc2616.txt">HTTP/1.1
+    <p>The <a href="https://www.rfc-editor.org/rfc/rfc2616">HTTP/1.1
     RFC</a>, section 14.11 puts it this way:</p>
 
-    <blockquote cite="http://www.ietf.org/rfc/rfc2616.txt">
+    <blockquote cite="https://www.rfc-editor.org/rfc/rfc2616">
       <p>The Content-Encoding entity-header field is used as a modifier to
       the media-type. When present, its value indicates what additional
       content codings have been applied to the entity-body, and thus what

diff --git a/docs/manual/mod/mod_negotiation.xml b/docs/manual/mod/mod_negotiation.xml
index 97a11b04b06ae0edcaae6575d2002dcebdda1b98..d5f0c3f308dd7ab3a0eb33040aaf8500e9e4b5b0 100644 (file)
--- a/docs/manual/mod/mod_negotiation.xml
+++ b/docs/manual/mod/mod_negotiation.xml
@@ -76,7 +76,7 @@ Negotiation</a></seealso>
 
       <dt><code>Content-Language:</code></dt>
       <dd>The language(s) of the variant, as an Internet standard
-      language tag (<a href="http://www.ietf.org/rfc/rfc1766.txt"
+      language tag (<a href="https://www.rfc-editor.org/rfc/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>

diff --git a/docs/manual/mod/mod_proxy.xml b/docs/manual/mod/mod_proxy.xml
index 4a44ad5bb95afbbec2ab670d7c031a030369e0ba..4205b86c13eed708dfe8e678f1ada4f126370e25 100644 (file)
--- a/docs/manual/mod/mod_proxy.xml
+++ b/docs/manual/mod/mod_proxy.xml
@@ -2087,7 +2087,7 @@ header for proxied requests</description>
     <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="http://www.ietf.org/rfc/rfc2616.txt">RFC 2616</a> (HTTP/1.1), section
+    href="https://www.rfc-editor.org/rfc/rfc2616">RFC 2616</a> (HTTP/1.1), section
     14.45 for an explanation of <code>Via:</code> header lines.</p>
 
     <ul>

diff --git a/docs/manual/mod/mod_ssl.xml b/docs/manual/mod/mod_ssl.xml
index 4cc50c1ff4b8dc36455d4622157f8effd1cd021f..cbe9d67de8b7f73cb0d175d06e53a4b7933ea59d 100644 (file)
--- a/docs/manual/mod/mod_ssl.xml
+++ b/docs/manual/mod/mod_ssl.xml
@@ -601,7 +601,7 @@ SSLEngine on
 </example>
 <p><directive>SSLEngine</directive> can be set to <code>optional</code>: 
 this enables support for
-<a href="http://www.ietf.org/rfc/rfc2817.txt">RFC 2817</a>.
+<a href="https://www.rfc-editor.org/rfc/rfc2817">RFC 2817</a>.
 </p>
 </usage>
 </directivesynopsis>
@@ -653,29 +653,29 @@ The available (case-insensitive) <em>protocol</em>s are:</p>
     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="http://www.ietf.org/rfc/rfc7568.txt">RFC 7568</a>.</p></li>
+    deprecated in <a href="https://www.rfc-editor.org/rfc/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="http://www.ietf.org/rfc/rfc2246.txt">RFC 2246</a>.
+    <a href="https://www.rfc-editor.org/rfc/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="http://www.ietf.org/rfc/rfc4346.txt">RFC 4346</a>.</p></li>
+    <a href="https://www.rfc-editor.org/rfc/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="http://www.ietf.org/rfc/rfc5246.txt">RFC 5246</a>.</p></li>
+    <a href="https://www.rfc-editor.org/rfc/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="http://www.ietf.org/rfc/rfc8446.txt">RFC 8446</a>.</p></li>
+    <a href="https://www.rfc-editor.org/rfc/rfc8446">RFC 8446</a>.</p></li>
 
 <li><code>all</code>
     <p>
@@ -981,7 +981,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 <a href="http://www.ietf.org/rfc/rfc3526.txt">RFC 3526</a>), and hands
+(from <a href="https://www.rfc-editor.org/rfc/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
@@ -2660,7 +2660,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
-<a href="http://www.ietf.org/rfc/rfc6961.txt">RFC 6961</a>
+<a href="https://www.rfc-editor.org/rfc/rfc6961">RFC 6961</a>
 (TLS Multiple Certificate Status Extension).
 </p>
 
@@ -2843,7 +2843,7 @@ One potential use is when a proxy is used for retrieving OCSP queries.</p>
 <usage>
 <p>Optionally configures a secret key for encrypting and decrypting
 TLS session tickets, as defined in
-<a href="http://www.ietf.org/rfc/rfc5077.txt">RFC 5077</a>.
+<a href="https://www.rfc-editor.org/rfc/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