From 84b4cc4e1b11ddfbcaa02149b7bf84417b39fee9 Mon Sep 17 00:00:00 2001 From: Robin Marx Date: Mon, 18 Mar 2019 10:37:10 +0100 Subject: [PATCH 1/3] Push stream data and PUSH_PROMISE reordering clarification --- draft-ietf-quic-http.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index b69e26fb35..b3a911d411 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -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 which 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 From dbba914d996d274c209d8e592c7aa080291b4e2c Mon Sep 17 00:00:00 2001 From: Robin Marx Date: Tue, 19 Mar 2019 10:46:48 +0100 Subject: [PATCH 2/3] CMOS change for consistency --- draft-ietf-quic-http.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index b3a911d411..7ef26ba837 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -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 From 32327c1739625f81cddf8e59bf9ee5fa53ecb696 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Sun, 24 Mar 2019 09:54:55 +0100 Subject: [PATCH 3/3] Update draft-ietf-quic-http.md Co-Authored-By: rmarx --- draft-ietf-quic-http.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 7ef26ba837..568f08a116 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -1210,7 +1210,7 @@ the promise that it fulfills, then contains a response to the promised request 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 which receive a new push stream with an +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