Re: [quicwg/base-drafts] Authoritative access in HTTP/3 (#3558)

[ianswett <[e-mail]>]

@ianswett approved this pull request.



> +
+The "https" scheme associates authority with the ability of a server to use a
+private key associated with a certificate that the client considers to be
+trustworthy for the host identified by the authority component of the URL. If a
+server presents a certificate that verifiably applies to the host, along with
+proof that it controls the corresponding private key, then a client will accept
+a secured connection to that server as being authoritative for all origins with
+the same scheme and host.
+
+When an "https" URI is used within a context that calls for access to the
+indicated resource, a client MAY attempt access by resolving the host identifier
+to an IP address, establishing a QUIC connection to that address on the
+indicated port, and sending an HTTP/3 request message to the server over that
+secured connection containing the URI's identifying data.
+
+Connectivity problems (e.g., firewall blocking UDP) can result in QUIC

```suggestion
Connectivity problems (e.g., blocking UDP) can result in QUIC
```
nit: I'd probably remove firewall, since lots of things can block UDP.

> +private key associated with a certificate that the client considers to be
+trustworthy for the host identified by the authority component of the URL. If a
+server presents a certificate that verifiably applies to the host, along with
+proof that it controls the corresponding private key, then a client will accept
+a secured connection to that server as being authoritative for all origins with
+the same scheme and host.
+
+When an "https" URI is used within a context that calls for access to the
+indicated resource, a client MAY attempt access by resolving the host identifier
+to an IP address, establishing a QUIC connection to that address on the
+indicated port, and sending an HTTP/3 request message to the server over that
+secured connection containing the URI's identifying data.
+
+Connectivity problems (e.g., firewall blocking UDP) can result in QUIC
+connection establishment failure; clients SHOULD attempt to use TCP-based
+versions of HTTP in this case.

Is there any need to mention TCP with TLS since this is in the context of HTTPS requests?

-- 
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/3558#pullrequestreview-385053922