The "https" scheme associates authority with possession of a certificate that the client considers to be trustworthy for the host identified by the authority -component of the URI.¶
-If a server presents a valid certificate and proof that it controls the -corresponding private key, then a client will accept a secured TLS session with -that server as being authoritative for all origins with the "https" scheme and a -host identified in the certificate. The host must be listed either as the CN -field of the certificate subject or as a dNSName in the subjectAltName field of -the certificate; see [RFC6125]. For a host that is an IP address, the client -MUST verify that the address appears as an iPAddress in the subjectAltName field -of the certificate.¶
-If the hostname or address is not present in the certificate, the client MUST -NOT consider the server authoritative for origins containing that hostname or -address. See Section 4.3 of [SEMANTICS] for more detail on authoritative -access.¶
-A client MAY attempt access to a resource with an "https" URI by resolving the +component of the URI. Upon receiving a server certificate in the TLS handshake, +the client MUST verify that the certificate is an acceptable match for the URI's +origin server using the process described in Section 4.3.4 of [SEMANTICS]. If +the certificate cannot be verified with respect to the URI's origin server, the +client MUST NOT consider the server authoritative for that origin.¶
+A client MAY attempt access to a resource with an "https" URI by resolving the host identifier to an IP address, establishing a QUIC connection to that address on the indicated port (including validation of the server certificate as described above), and sending an HTTP/3 request message targeting the URI to the server over that secured connection. Unless some other mechanism is used to select HTTP/3, the token "h3" is used in the Application Layer Protocol -Negotiation (ALPN; see [RFC7301]) extension during the TLS handshake.¶
-Connectivity problems (e.g., blocking UDP) can result in QUIC connection +Negotiation (ALPN; see [RFC7301]) extension during the TLS handshake.¶
+Connectivity problems (e.g., blocking UDP) can result in QUIC connection establishment failure; clients SHOULD attempt to use TCP-based versions of HTTP -in this case.¶
-Servers MAY serve HTTP/3 on any UDP port; an alternative service advertisement +in this case.¶
+Servers MAY serve HTTP/3 on any UDP port; an alternative service advertisement always includes an explicit port, and URIs contain either an explicit port or a -default port associated with the scheme.¶
+default port associated with the scheme.¶Once a connection exists to a server endpoint, this connection MAY be reused for -requests with multiple different URI authority components. Clients SHOULD NOT -open more than one HTTP/3 connection to a given host and port pair, where the -host is derived from a URI, a selected alternative service ([ALTSVC]), or a -configured proxy. A client MAY open multiple HTTP/3 connections to the same IP -address and UDP port using different transport or TLS configurations but SHOULD -avoid creating multiple connections with the same configuration.¶
-Servers are encouraged to maintain open HTTP/3 connections for as long as +requests with multiple different URI authority components. To use an existing +connection for a new origin, clients MUST validate the certificate presented by +the server for the new origin server using the process described in Section +4.3.4 of [SEMANTICS]. This implies that clients will need to retain the +server certificate and any additional information needed to verify that +certificate; clients which do not do so will be unable to reuse the connection +for additional origins.¶
+If the certificate is not acceptable with regard to the new origin for any +reason, the connection MUST NOT be reused and a new connection SHOULD be +established for the new origin. If the reason the certificate cannot be +verified might apply to other origins already associated with the connection, +the client SHOULD re-validate the server certificate for those origins. For +instance, if validation of a certificate fails because the certificate has +expired or been revoked, this might be used to invalidate all other origins for +which that certificate was used to establish authority.¶
+Clients SHOULD NOT open more than one HTTP/3 connection to a given IP address +and UDP port, where the IP address and port might be derived from a URI, a +selected alternative service ([ALTSVC]), a configured proxy, or name +resolution of any of these. A client MAY open multiple HTTP/3 connections to the +same IP address and UDP port using different transport or TLS configurations but +SHOULD avoid creating multiple connections with the same configuration.¶
+Servers are encouraged to maintain open HTTP/3 connections for as long as possible but are permitted to terminate idle connections if necessary. When either endpoint chooses to close the HTTP/3 connection, the terminating endpoint SHOULD first send a GOAWAY frame (Section 5.2) so that both endpoints can reliably determine whether previously sent frames have been -processed and gracefully complete or terminate any necessary remaining tasks.¶
-A server that does not wish clients to reuse HTTP/3 connections for a particular +processed and gracefully complete or terminate any necessary remaining tasks.¶
+A server that does not wish clients to reuse HTTP/3 connections for a particular origin can indicate that it is not authoritative for a request by sending a 421 -(Misdirected Request) status code in response to the request; see Section 9.1.2 -of [HTTP2].¶
+(Misdirected Request) status code in response to the request; see Section 7.4 +of [SEMANTICS].¶The server MUST include a value in the ":authority" pseudo-header field for -which the server is authoritative; see Section 3.3.¶
+which the server is authoritative. If the client has not yet validated the +connection for the origin indicated by the pushed request, it MUST perform the +same verification process it would do before sending a request for that origin +on the connection; see Section 3.3. If this verification fails, +the client MUST NOT consider the server authoritative for that origin.¶Clients SHOULD send a CANCEL_PUSH frame upon receipt of a PUSH_PROMISE frame carrying a request that is not cacheable, is not known to be safe, that indicates the presence of a request body, or for which it does not consider the @@ -4180,6 +4191,10 @@