From 3e91cabfbe70294fafef2628d9b3f3d1282d79fb Mon Sep 17 00:00:00 2001 From: Ryan Hamilton Date: Fri, 20 Dec 2019 08:03:41 -0800 Subject: [PATCH 01/11] Remove DUPLICATE_PUSH and allow duplicate PUSH_PROMISE --- draft-ietf-quic-http.md | 108 +++++++++++----------------------------- 1 file changed, 30 insertions(+), 78 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index a519c03a41..c7b0ed44c4 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -151,7 +151,7 @@ Server push is an interaction mode introduced in HTTP/2 {{!HTTP2}} which permits a server to push a request-response exchange to a client in anticipation of the client making the indicated request. This trades off network usage against a potential latency gain. Several HTTP/3 frames are used to manage server push, -such as PUSH_PROMISE, DUPLICATE_PUSH, MAX_PUSH_ID, and CANCEL_PUSH. +such as PUSH_PROMISE, MAX_PUSH_ID, and CANCEL_PUSH. As in HTTP/2, request and response headers are compressed for transmission. Because HPACK {{?HPACK=RFC7541}} relies on in-order transmission of compressed @@ -387,10 +387,9 @@ An HTTP message (request or response) consists of: 3. optionally, trailing headers, if present (see Section 4.1.2 of {{!RFC7230}}), sent as a single HEADERS frame. -A server MAY send one or more PUSH_PROMISE (see {{frame-push-promise}}) or -DUPLICATE_PUSH (see {{frame-duplicate-push}}) frames before, after, or -interleaved with the frames of a response message. These PUSH_PROMISE and -DUPLICATE_PUSH frames are not part of the response; see {{server-push}} for +A server MAY send one or more PUSH_PROMISE (see {{frame-push-promise}}) frames +frames before, after, or interleaved with the frames of a response message. +These PUSH_PROMISE frames are not part of the response; see {{server-push}} for more details. Frames of unknown types ({{extensions}}), including reserved frames @@ -612,11 +611,10 @@ client making the indicated request. This trades off network usage against a potential latency gain. HTTP/3 server push is similar to what is described in HTTP/2 {{!HTTP2}}, but uses different mechanisms. -Each server push is identified by a unique Push ID. This Push ID is used in a -single PUSH_PROMISE frame (see {{frame-push-promise}}) which carries the request -headers, possibly included in one or more DUPLICATE_PUSH frames (see -{{frame-duplicate-push}}), then included with the push stream which ultimately -fulfills those promises. +Each server push is identified by a unique Push ID. This Push ID is used in all +PUSH_PROMISE frames (see {{frame-push-promise}}) which carries the request +headers, then included with the push stream which ultimately fulfills those +promises. Server push is only enabled on a connection when a client sends a MAX_PUSH_ID frame (see {{frame-max-push-id}}). A server cannot use server push until it @@ -633,33 +631,30 @@ requests MUST conform to the requirements in Section 8.2 of {{!HTTP2}}. Each pushed response is associated with one or more client requests. The push is associated with the request stream on which the PUSH_PROMISE frame was received. The same server push can be associated with additional client -requests using a DUPLICATE_PUSH frame (see {{frame-duplicate-push}}). These -associations do not affect the operation of the protocol, but MAY be used by -user agents when deciding how to use pushed resources. +requests using a PUSH_PROMISE frame with the same push id on multiple request +stream. These associations do not affect the operation of the protocol, but MAY +be used by user agents when deciding how to use pushed resources. -Ordering of a PUSH_PROMISE or DUPLICATE_PUSH in relation to certain parts of the -response is important. The server SHOULD send PUSH_PROMISE or DUPLICATE_PUSH -frames prior to sending HEADERS or DATA frames that reference the promised -responses. This reduces the chance that a client requests a resource that will -be pushed by the server. +Ordering of a PUSH_PROMISE in relation to certain parts of the response is +important. The server SHOULD send PUSH_PROMISE frames prior to sending HEADERS +or DATA frames that reference the promised responses. This reduces the chance +that a client requests a resource that will be pushed by the server. 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}}. -Due to reordering, DUPLICATE_PUSH frames or push stream data can arrive before -the corresponding PUSH_PROMISE frame. When a client receives a DUPLICATE_PUSH -frame for an as-yet-unknown Push ID, the request headers of the push are not -immediately available. The client 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 -the requests if the requested resource is already being pushed. When a client -receives a new push stream with an as-yet-unknown Push ID, both the associated -client request and the pushed request headers are unknown. The client can -buffer the stream data in expectation of the matching PUSH_PROMISE. The 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. +Due to reordering, push stream data can arrive before the corresponding +PUSH_PROMISE frame. When a client receives a new push stream with an +as-yet-unknown Push ID, both the associated client request and the pushed request +headers are unknown. The client can buffer the stream data in expectation of the +matching PUSH_PROMISE. The 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 the same Push ID is promised on multiple request streams, the decompressed +request headers MUST be byte-for-byte idential. 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 @@ -960,7 +955,6 @@ comparison between HTTP/2 and HTTP/3 frames is provided in {{h2-frames}}. | PUSH_PROMISE | No | Yes | No | {{frame-push-promise}} | | GOAWAY | Yes | No | No | {{frame-goaway}} | | MAX_PUSH_ID | Yes | No | No | {{frame-max-push-id}} | -| DUPLICATE_PUSH | No | Yes | No | {{frame-duplicate-push}} | | Reserved | Yes | Yes | Yes | {{frame-reserved}} | {: #stream-frame-mapping title="HTTP/3 Frames and Stream Type Overview"} @@ -1244,7 +1238,7 @@ The payload consists of: Push ID: : A variable-length integer that identifies the server push operation. A Push ID is used in push stream headers ({{server-push}}), CANCEL_PUSH frames - ({{frame-cancel-push}}), and DUPLICATE_PUSH frames ({{frame-duplicate-push}}). + ({{frame-cancel-push}}). Header Block: : QPACK-compressed request header fields for the promised response. See [QPACK] @@ -1255,9 +1249,10 @@ MAX_PUSH_ID frame ({{frame-max-push-id}}). A client MUST treat receipt of a PUSH_PROMISE frame that contains a larger Push ID than the client has advertised as a connection error of H3_ID_ERROR. -A server MUST NOT use the same Push ID in multiple PUSH_PROMISE frames. A client -MUST treat receipt of a Push ID which has already been promised as a connection -error of type H3_ID_ERROR. +A server MAY use the same Push ID in multiple PUSH_PROMISE frames. If so, the +decompressed request headers MUST be idential. A client MUST treat receipt of a +Push ID which has already been promised with different headers than the previous +promise as a connection error of type H3_ID_ERROR. If a PUSH_PROMISE frame is received on the control stream, the client MUST respond with a connection error ({{errors}}) of type H3_FRAME_UNEXPECTED. @@ -1334,48 +1329,6 @@ the maximum value for a Push ID that the server can use (see receipt of a MAX_PUSH_ID that contains a smaller value than previously received MUST be treated as a connection error of type H3_ID_ERROR. -### DUPLICATE_PUSH {#frame-duplicate-push} - -The DUPLICATE_PUSH frame (type=0xE) is used by servers to indicate that an -existing pushed resource is related to multiple client requests. - -The DUPLICATE_PUSH frame is always sent on a request stream. Receipt of a -DUPLICATE_PUSH frame on any other stream MUST be treated as a connection error -of type H3_FRAME_UNEXPECTED. - -A client MUST NOT send a DUPLICATE_PUSH frame. A server MUST treat the receipt -of a DUPLICATE_PUSH frame as a connection error of type H3_FRAME_UNEXPECTED. - -~~~~~~~~~~ drawing - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Push ID (i) ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -~~~~~~~~~~ -{: #fig-duplicate-push title="DUPLICATE_PUSH Frame Payload"} - -The DUPLICATE_PUSH frame carries a single variable-length integer that -identifies the Push ID of a resource that the server has previously promised -(see {{frame-push-promise}}), though that promise might not be received before -this frame. A server MUST NOT use a Push ID that is larger than the client has -provided in a MAX_PUSH_ID frame ({{frame-max-push-id}}). A client MUST treat -receipt of a DUPLICATE_PUSH that contains a larger Push ID than the client has -advertised as a connection error of type H3_ID_ERROR. - -This frame allows the server to use the same server push in response to multiple -concurrent requests. Referencing the same server push ensures that a promise -can be made in relation to every response in which server push might be needed -without duplicating request headers or pushed responses. - -Allowing duplicate references to the same Push ID is primarily to reduce -duplication caused by concurrent requests. A server SHOULD avoid reusing a Push -ID over a long period. Clients are likely to consume server push responses and -not retain them for reuse over time. Clients that see a DUPLICATE_PUSH that -uses a Push ID that they have since consumed and discarded are forced to ignore -the DUPLICATE_PUSH. - - ### Reserved Frame Types {#frame-reserved} Frame types of the format `0x1f * N + 0x21` for integer values of N are reserved @@ -1635,7 +1588,6 @@ The entries in {{iana-frame-table}} are registered by this document. | Reserved | 0x8 | N/A | | Reserved | 0x9 | N/A | | MAX_PUSH_ID | 0xD | {{frame-max-push-id}} | -| DUPLICATE_PUSH | 0xE | {{frame-duplicate-push}} | | ---------------- | ------ | -------------------------- | {: #iana-frame-table title="Initial HTTP/3 Frame Types"} From 7b2bae87a8f3504289970715d564f88e398aac76 Mon Sep 17 00:00:00 2001 From: Ryan Hamilton Date: Fri, 20 Dec 2019 09:10:19 -0800 Subject: [PATCH 02/11] wrap --- draft-ietf-quic-http.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index c7b0ed44c4..de02e62153 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -647,11 +647,11 @@ using the same format described for responses in {{request-response}}. Due to reordering, push stream data can arrive before the corresponding PUSH_PROMISE frame. When a client receives a new push stream with an -as-yet-unknown Push ID, both the associated client request and the pushed request -headers are unknown. The client can buffer the stream data in expectation of the -matching PUSH_PROMISE. The 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. +as-yet-unknown Push ID, both the associated client request and the pushed +request headers are unknown. The client can buffer the stream data in +expectation of the matching PUSH_PROMISE. The 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 the same Push ID is promised on multiple request streams, the decompressed request headers MUST be byte-for-byte idential. From 2e13c4e52b3a1fa8cd1a93ce4fe64574cf2e21ee Mon Sep 17 00:00:00 2001 From: Ryan Hamilton Date: Fri, 20 Dec 2019 18:27:32 -0800 Subject: [PATCH 03/11] one or more --- draft-ietf-quic-http.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index de02e62153..da69006abe 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -611,10 +611,11 @@ client making the indicated request. This trades off network usage against a potential latency gain. HTTP/3 server push is similar to what is described in HTTP/2 {{!HTTP2}}, but uses different mechanisms. -Each server push is identified by a unique Push ID. This Push ID is used in all -PUSH_PROMISE frames (see {{frame-push-promise}}) which carries the request +Each server push is identified by a unique Push ID. This Push ID is used in one +or more PUSH_PROMISE frames (see {{frame-push-promise}}) that carry the request headers, then included with the push stream which ultimately fulfills those -promises. +promises. When the same Push ID is promised on multiple request streams, the +decompressed request header fields MUST be byte-for-byte identical. Server push is only enabled on a connection when a client sends a MAX_PUSH_ID frame (see {{frame-max-push-id}}). A server cannot use server push until it From fcaf1b21aec75e8fc76f31506e8da5fad5e039f1 Mon Sep 17 00:00:00 2001 From: Ryan Hamilton Date: Mon, 6 Jan 2020 10:21:55 -0800 Subject: [PATCH 04/11] Apply suggestions from code review Co-Authored-By: Mike Bishop --- draft-ietf-quic-http.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index da69006abe..b84e215182 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -388,7 +388,7 @@ An HTTP message (request or response) consists of: sent as a single HEADERS frame. A server MAY send one or more PUSH_PROMISE (see {{frame-push-promise}}) frames -frames before, after, or interleaved with the frames of a response message. +before, after, or interleaved with the frames of a response message. These PUSH_PROMISE frames are not part of the response; see {{server-push}} for more details. @@ -632,7 +632,7 @@ requests MUST conform to the requirements in Section 8.2 of {{!HTTP2}}. Each pushed response is associated with one or more client requests. The push is associated with the request stream on which the PUSH_PROMISE frame was received. The same server push can be associated with additional client -requests using a PUSH_PROMISE frame with the same push id on multiple request +requests using a PUSH_PROMISE frame with the same Push ID on multiple request stream. These associations do not affect the operation of the protocol, but MAY be used by user agents when deciding how to use pushed resources. From a267e824653b7006e4e1a7f1ba9e255c55496f8f Mon Sep 17 00:00:00 2001 From: Ryan Hamilton Date: Mon, 6 Jan 2020 10:24:12 -0800 Subject: [PATCH 05/11] Update "identical" definition --- draft-ietf-quic-http.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index b84e215182..2d13a18965 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -615,7 +615,9 @@ Each server push is identified by a unique Push ID. This Push ID is used in one or more PUSH_PROMISE frames (see {{frame-push-promise}}) that carry the request headers, then included with the push stream which ultimately fulfills those promises. When the same Push ID is promised on multiple request streams, the -decompressed request header fields MUST be byte-for-byte identical. +decompressed request header set MUST contains the same set of fields in the +same order, and in each field both the name and and value MUST be byte-for-byte +matches. Server push is only enabled on a connection when a client sends a MAX_PUSH_ID frame (see {{frame-max-push-id}}). A server cannot use server push until it @@ -654,9 +656,6 @@ expectation of the matching PUSH_PROMISE. The 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 the same Push ID is promised on multiple request streams, the decompressed -request headers MUST be byte-for-byte idential. - 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 CANCEL_PUSH frame, the client can abort reading the stream with an error code of @@ -1251,9 +1250,12 @@ PUSH_PROMISE frame that contains a larger Push ID than the client has advertised as a connection error of H3_ID_ERROR. A server MAY use the same Push ID in multiple PUSH_PROMISE frames. If so, the -decompressed request headers MUST be idential. A client MUST treat receipt of a -Push ID which has already been promised with different headers than the previous -promise as a connection error of type H3_ID_ERROR. +decompressed request header set MUST contain the same set of fields in the same +order, and in each field both the name and and value MUST be byte-for-byte +matches. When a client receives a Push ID which has alread been promised, if the +client detects a mismatch, it MUST response with a connection error of type +H3_GENERAL_PROTOCOL_ERROR. Otherwise it MUST ignore the PUSH_PROMISE frame if no +mismatch is detected. If a PUSH_PROMISE frame is received on the control stream, the client MUST respond with a connection error ({{errors}}) of type H3_FRAME_UNEXPECTED. From 89ca34bbc27c42d6590d3e7b2dcb1886a07436ad Mon Sep 17 00:00:00 2001 From: Ryan Hamilton Date: Mon, 6 Jan 2020 10:53:53 -0800 Subject: [PATCH 06/11] Apply suggestions from code review from Lucas Co-Authored-By: Lucas Pardue --- draft-ietf-quic-http.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 2d13a18965..61cbb790dd 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -615,8 +615,8 @@ Each server push is identified by a unique Push ID. This Push ID is used in one or more PUSH_PROMISE frames (see {{frame-push-promise}}) that carry the request headers, then included with the push stream which ultimately fulfills those promises. When the same Push ID is promised on multiple request streams, the -decompressed request header set MUST contains the same set of fields in the -same order, and in each field both the name and and value MUST be byte-for-byte +decompressed request header set MUST contain the same set of fields in the +same order, and in each field both the name and value MUST be byte-for-byte matches. Server push is only enabled on a connection when a client sends a MAX_PUSH_ID From 7e3132322af5608292ce30e68bd0b2a8e3d2e0b5 Mon Sep 17 00:00:00 2001 From: Ryan Hamilton Date: Wed, 8 Jan 2020 06:45:24 -0800 Subject: [PATCH 07/11] Apply suggestions from Janacode review Co-Authored-By: Jana Iyengar --- draft-ietf-quic-http.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 61cbb790dd..431a82c9d9 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -387,7 +387,7 @@ An HTTP message (request or response) consists of: 3. optionally, trailing headers, if present (see Section 4.1.2 of {{!RFC7230}}), sent as a single HEADERS frame. -A server MAY send one or more PUSH_PROMISE (see {{frame-push-promise}}) frames +A server MAY send one or more PUSH_PROMISE frames (see {{frame-push-promise}}) before, after, or interleaved with the frames of a response message. These PUSH_PROMISE frames are not part of the response; see {{server-push}} for more details. @@ -615,8 +615,8 @@ Each server push is identified by a unique Push ID. This Push ID is used in one or more PUSH_PROMISE frames (see {{frame-push-promise}}) that carry the request headers, then included with the push stream which ultimately fulfills those promises. When the same Push ID is promised on multiple request streams, the -decompressed request header set MUST contain the same set of fields in the -same order, and in each field both the name and value MUST be byte-for-byte +decompressed request header sets MUST contain the same fields in the +same order, and both the name and the value in each field MUST be exact matches. Server push is only enabled on a connection when a client sends a MAX_PUSH_ID @@ -1250,12 +1250,12 @@ PUSH_PROMISE frame that contains a larger Push ID than the client has advertised as a connection error of H3_ID_ERROR. A server MAY use the same Push ID in multiple PUSH_PROMISE frames. If so, the -decompressed request header set MUST contain the same set of fields in the same -order, and in each field both the name and and value MUST be byte-for-byte -matches. When a client receives a Push ID which has alread been promised, if the -client detects a mismatch, it MUST response with a connection error of type -H3_GENERAL_PROTOCOL_ERROR. Otherwise it MUST ignore the PUSH_PROMISE frame if no -mismatch is detected. +decompressed request header sets MUST contain the same fields in the same +order, and both the name and and value in each field MUST be exact +matches. If a client receives a Push ID that has already been promised +and detects a mismatch, it MUST respond with a connection error of type +H3_GENERAL_PROTOCOL_ERROR. If the decompressed header sets match exactly, the +client MUST ignore the duplicate PUSH_PROMISE frame. If a PUSH_PROMISE frame is received on the control stream, the client MUST respond with a connection error ({{errors}}) of type H3_FRAME_UNEXPECTED. From 9b067934668f9ba7f6a60c05145d8f9e4450a3c8 Mon Sep 17 00:00:00 2001 From: Ryan Hamilton Date: Thu, 9 Jan 2020 13:49:57 -0800 Subject: [PATCH 08/11] Add motivation for duplicate push ids --- draft-ietf-quic-http.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 431a82c9d9..0280588666 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -1257,6 +1257,13 @@ and detects a mismatch, it MUST respond with a connection error of type H3_GENERAL_PROTOCOL_ERROR. If the decompressed header sets match exactly, the client MUST ignore the duplicate PUSH_PROMISE frame. +Allowing duplicate references to the same Push ID is primarily to reduce +duplication caused by concurrent requests. A server SHOULD avoid reusing a Push +ID over a long period. Clients are likely to consume server push responses and +not retain them for reuse over time. Clients that see a PUSH_PROMISE that uses +a Push ID that they have since consumed and discarded are forced to ignore the +PUSH_PROMISE. + If a PUSH_PROMISE frame is received on the control stream, the client MUST respond with a connection error ({{errors}}) of type H3_FRAME_UNEXPECTED. From 82c0a2615961fe18a9b1ed648573ffa4575f11c3 Mon Sep 17 00:00:00 2001 From: Ryan Hamilton Date: Fri, 10 Jan 2020 10:12:51 -0800 Subject: [PATCH 09/11] Apply suggestions from mbishop code review Co-Authored-By: Mike Bishop --- draft-ietf-quic-http.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 0280588666..0e360e4e48 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -635,8 +635,8 @@ Each pushed response is associated with one or more client requests. The push is associated with the request stream on which the PUSH_PROMISE frame was received. The same server push can be associated with additional client requests using a PUSH_PROMISE frame with the same Push ID on multiple request -stream. These associations do not affect the operation of the protocol, but MAY -be used by user agents when deciding how to use pushed resources. +streams. These associations do not affect the operation of the protocol, but +MAY be used by user agents when deciding how to use pushed resources. Ordering of a PUSH_PROMISE in relation to certain parts of the response is important. The server SHOULD send PUSH_PROMISE frames prior to sending HEADERS @@ -1252,7 +1252,8 @@ as a connection error of H3_ID_ERROR. A server MAY use the same Push ID in multiple PUSH_PROMISE frames. If so, the decompressed request header sets MUST contain the same fields in the same order, and both the name and and value in each field MUST be exact -matches. If a client receives a Push ID that has already been promised +matches. Clients SHOULD compare the request header sets for resources promised +multiple times. If a client receives a Push ID that has already been promised and detects a mismatch, it MUST respond with a connection error of type H3_GENERAL_PROTOCOL_ERROR. If the decompressed header sets match exactly, the client MUST ignore the duplicate PUSH_PROMISE frame. @@ -1261,7 +1262,7 @@ Allowing duplicate references to the same Push ID is primarily to reduce duplication caused by concurrent requests. A server SHOULD avoid reusing a Push ID over a long period. Clients are likely to consume server push responses and not retain them for reuse over time. Clients that see a PUSH_PROMISE that uses -a Push ID that they have since consumed and discarded are forced to ignore the +a Push ID that they have already consumed and discarded are forced to ignore the PUSH_PROMISE. If a PUSH_PROMISE frame is received on the control stream, the client MUST From 61223d6020d79653b4119e17a1feb6ae8522c60e Mon Sep 17 00:00:00 2001 From: Ryan Hamilton Date: Fri, 10 Jan 2020 15:03:32 -0800 Subject: [PATCH 10/11] Update draft-ietf-quic-http.md per mbishop Co-Authored-By: Mike Bishop --- draft-ietf-quic-http.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 0e360e4e48..d2ba32aabb 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -1256,7 +1256,8 @@ matches. Clients SHOULD compare the request header sets for resources promised multiple times. If a client receives a Push ID that has already been promised and detects a mismatch, it MUST respond with a connection error of type H3_GENERAL_PROTOCOL_ERROR. If the decompressed header sets match exactly, the -client MUST ignore the duplicate PUSH_PROMISE frame. +client SHOULD associate the pushed content with each stream on which +a PUSH_PROMISE was received. Allowing duplicate references to the same Push ID is primarily to reduce duplication caused by concurrent requests. A server SHOULD avoid reusing a Push From a42669cba1fac8fe27c7925c1cd4fe0eb297e2c6 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Tue, 11 Feb 2020 15:26:52 -0500 Subject: [PATCH 11/11] Use less --- 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 d2ba32aabb..c68dee9fdd 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -636,7 +636,7 @@ is associated with the request stream on which the PUSH_PROMISE frame was received. The same server push can be associated with additional client requests using a PUSH_PROMISE frame with the same Push ID on multiple request streams. These associations do not affect the operation of the protocol, but -MAY be used by user agents when deciding how to use pushed resources. +MAY be considered by user agents when deciding how to use pushed resources. Ordering of a PUSH_PROMISE in relation to certain parts of the response is important. The server SHOULD send PUSH_PROMISE frames prior to sending HEADERS