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.

Sign up for GitHub

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

Jump to bottom

Expand connection management text #1024

Merged
merged 4 commits into from
Jan 4, 2018
Merged

Expand connection management text #1024

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
fbf1461
Expand connection management text (Fixes #940, #794)
MikeBishop Dec 18, 2017
66bd92c
Require cert validation
MikeBishop Dec 18, 2017
bf482f1
Lucas's feedback
MikeBishop Dec 23, 2017
4909203
MUST NOT assume
MikeBishop Jan 4, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 7 additions & 5 deletions draft-ietf-quic-http.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -195,11 +195,13 @@ Once a connection exists to a server endpoint, this connection MAY be reused for
requests with multiple different URI authority components. The client MAY send
any requests for which the client considers the server authoritative.

This typically means that the client has received an Alt-Svc record from the
request's origin in question which nominates the server endpoint as a valid HTTP
Alternative Service for that origin. Clients SHOULD NOT assume that an
HTTP/QUIC endpoint is authoritative for other origins without an explicit
signal.
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.
Copy link
Member

Choose a reason for hiding this comment

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

"validate a validated certificate" sounds odd.

Clients SHOULD NOT assume that an HTTP/QUIC endpoint is authoritative for other
origins without 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