Re: [quicwg/base-drafts] Rework HTTP authority/coalescing again (#4808)

[Mike Bishop <[e-mail]>]

@MikeBishop commented on this pull request.



> -component of the URL.
-
-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.
+component of the URL.  Upon receiving a server certificate in the TLS handshake,

#4812, but no harm fixing it here, too.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4808#discussion_r563901680