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

Author: notroj

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>

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>
 

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>

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

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>

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>

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