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

Don't specify RTT in HTTP #3358

Merged
merged 2 commits into from Jan 20, 2020
Merged

Don't specify RTT in HTTP #3358

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
b35941a
Don't specify RTT
MikeBishop Jan 17, 2020
e123d9f
Do the can-can
MikeBishop Jan 20, 2020
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
2 changes: 1 addition & 1 deletion draft-ietf-quic-http.md
View file
Open in desktop
Expand Up @@ -732,7 +732,7 @@ initial GOAWAY frame with the last Stream ID set to the maximum possible value
for a client-initiated, bidirectional stream (i.e. 2^62-4 in case of QUIC
version 1). This GOAWAY frame signals to the client that shutdown is imminent
and that initiating further requests is prohibited. After allowing time for any
in-flight requests to reach the server, the server MAY send another GOAWAY frame
in-flight requests to reach the server, the server can send another GOAWAY frame
indicating which requests it will accept before the end of the connection. This
Copy link
Member

@kazuho kazuho Jan 17, 2020 •
edited

Choose a reason for hiding this comment

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

Now that we do not use RFC 2119 keywords in describing the procedure of gracefully shutting down the connection, it might be a good idea to change:
"the server MAY send another GOAWAY frame indicating which requests it will accept before the end of the connection."
to: "the server sends another GOAWAY frame indicating the requests it accepted."

Copy link
Member

Choose a reason for hiding this comment

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

Don't you mean "can send"?

Copy link
Member

Choose a reason for hiding this comment

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

My view has been "server sends" is better than "can send", because this sentence is part of what a server "can" do to gracefully shutdown a connection. But I'll leave that up to the editors.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Perhaps, but "can" is used other places through this description. Unless we rewrite the whole thing to be can-free, I'm choosing consistency.

ensures that a connection can be cleanly shut down without causing requests to
fail.
Expand Down