New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expand connection management text #1024
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -153,12 +153,13 @@ MAY omit supported versions for any reason. | |
|
||
HTTP/QUIC relies on QUIC as the underlying transport. The QUIC version being | ||
used MUST use TLS version 1.3 or greater as its handshake protocol. The Server | ||
Name Indication extension {{!RFC6066}} MUST be included in the TLS handshake. | ||
Name Indication (SNI) extension {{!RFC6066}} MUST be included in the TLS | ||
handshake. | ||
|
||
QUIC connections are established as described in {{QUIC-TRANSPORT}}. During | ||
connection establishment, HTTP/QUIC support is indicated by selecting the ALPN | ||
token "hq" in the crypto handshake. Support for other application-layer | ||
protocols MAY be offered in the same handshake. | ||
token "hq" in the TLS handshake. Support for other application-layer protocols | ||
MAY be offered in the same handshake. | ||
|
||
While connection-level options pertaining to the core QUIC protocol are set in | ||
the initial crypto handshake, HTTP-specific settings are conveyed | ||
|
@@ -198,10 +199,10 @@ any requests for which the client considers the server authoritative. | |
An authoritative HTTP/QUIC endpoint is typically discovered because the client | ||
has received an Alt-Svc record from the request's origin which nominates the | ||
endpoint as a valid HTTP Alternative Service for that origin. As required by | ||
{{RFC7838}}, clients MUST validate that the nominated server can present a | ||
validated certificate for the origin before considering it authoritative. | ||
Clients SHOULD NOT assume that an HTTP/QUIC endpoint is authoritative for other | ||
origins without an explicit signal. | ||
{{RFC7838}}, clients MUST check that the nominated server can present a valid | ||
certificate for the origin before considering it authoritative. Clients SHOULD | ||
NOT assume that an HTTP/QUIC endpoint is authoritative for other origins without | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "SHOULD NOT assume"? "cannot" or "MUST NOT" perhaps There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, I don't remember what my logic was for that one. Probably trying to dance around the ORIGIN-style trust model. Either is fine. |
||
an explicit signal. | ||
|
||
A server that does not wish clients to reuse connections for a particular origin | ||
can indicate that it is not authoritative for a request by sending a 421 | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we use "server" here rather than "endpoint"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What led me to that wording is that the same server might offer both TCP(HTTP/2) and UDP(QUIC) endpoints, so we're not necessarily discovering a new server. It's ultimately an IP:port that we're connecting to, and I think "endpoint" is a more accurate term there. Alternate terms for that concept welcome.