Skip to content
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

Merged
merged 4 commits into from Jan 4, 2018
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
15 changes: 8 additions & 7 deletions draft-ietf-quic-http.md
Expand Up @@ -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
Expand Down Expand Up @@ -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
Copy link
Member

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"?

Copy link
Contributor Author

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.

{{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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"SHOULD NOT assume"? "cannot" or "MUST NOT" perhaps

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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
Expand Down