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

Push stream data and PUSH_PROMISE reordering clarification #2527

Merged
merged 3 commits into from
Apr 16, 2019
Merged

Push stream data and PUSH_PROMISE reordering clarification #2527

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
84b4cc4
Push stream data and PUSH_PROMISE reordering clarification
rmarx Mar 18, 2019
dbba914
CMOS change for consistency
rmarx Mar 19, 2019
32327c1
Update draft-ietf-quic-http.md
martinthomson Mar 24, 2019
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
11 changes: 9 additions & 2 deletions draft-ietf-quic-http.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1198,7 +1198,7 @@ DUPLICATE_PUSH frame (see {{frame-duplicate-push}}). Ordering of a
DUPLICATE_PUSH in relation to certain parts of the response is similarly
important. Due to reordering, DUPLICATE_PUSH frames can arrive before the
corresponding PUSH_PROMISE frame, in which case the request headers of the push
would not be immediately available. Clients which receive a DUPLICATE_PUSH
would not be immediately available. Clients that receive a DUPLICATE_PUSH
frame for an as-yet-unknown Push ID can either delay generating new requests for
content referenced following the DUPLICATE_PUSH frame until the request headers
become available, or can initiate requests for discovered resources and cancel
Expand All @@ -1207,7 +1207,14 @@ the requests if the requested resource is already being pushed.
When a server later fulfills a promise, the server push response is conveyed on
a push stream (see {{push-streams}}). The push stream identifies the Push ID of
the promise that it fulfills, then contains a response to the promised request
using the same format described for responses in {{request-response}}.
using the same format described for responses in {{request-response}}. Due to
reordering, data on a push stream can arrive before the corresponding
PUSH_PROMISE, in which case both the associated client request and the pushed
request headers are unknown. Clients that receive a new push stream with an
as-yet-unknown Push ID can buffer the stream data in expectation of the matching
PUSH_PROMISE. A client can use stream flow control (see section 4.1 of
{{QUIC-TRANSPORT}}) to limit the amount of data a server may commit to the
pushed stream.

If a promised server push is not needed by the client, the client SHOULD send a
CANCEL_PUSH frame. If the push stream is already open or opens after sending the
Expand Down