From dc7f6041fbae53e06e1875a1df561388e44156b2 Mon Sep 17 00:00:00 2001 From: Kazuho Oku Date: Tue, 20 Aug 2019 09:47:31 +0900 Subject: [PATCH 1/6] explain that and endpoint cannot expect the delivery of the peer's settings --- draft-ietf-quic-http.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index e9ecee4a77..8b6c866cdb 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -2114,9 +2114,9 @@ equivalent HTTP/2 code points. See {{iana-frames}}. ## HTTP/2 SETTINGS Parameters {#h2-settings} -An important difference from HTTP/2 is that settings are sent once, at the -beginning of the connection, and thereafter cannot change. This eliminates -many corner cases around synchronization of changes. +An important difference from HTTP/2 is that settings are sent once, as the first +frame of the control stream, and thereafter cannot change. This eliminates many +corner cases around synchronization of changes. Some transport-level options that HTTP/2 specifies via the SETTINGS frame are superseded by QUIC transport parameters in HTTP/3. The HTTP-level options that @@ -2159,6 +2159,10 @@ the settings identifier space in HTTP/3 is substantially larger (62 bits versus 16 bits), so many HTTP/3 settings have no equivalent HTTP/2 code point. See {{iana-settings}}. +An endpoint cannot assume the peer's settings to arrive in a timely manner, as +the packet carrying the settings can be lost, or the peer might postpone the +transmission of the settings until it sees a use of the control stream. + ## HTTP/2 Error Codes From a907a06ba5e297b7a5baa524d77f3c48406d0349 Mon Sep 17 00:00:00 2001 From: Kazuho Oku Date: Fri, 23 Aug 2019 10:09:00 +0900 Subject: [PATCH 2/6] "SHOULD NOT", with a less extreme example used as clarification --- draft-ietf-quic-http.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 8b6c866cdb..ba36a59781 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -2159,9 +2159,11 @@ the settings identifier space in HTTP/3 is substantially larger (62 bits versus 16 bits), so many HTTP/3 settings have no equivalent HTTP/2 code point. See {{iana-settings}}. -An endpoint cannot assume the peer's settings to arrive in a timely manner, as -the packet carrying the settings can be lost, or the peer might postpone the -transmission of the settings until it sees a use of the control stream. +An endpoint SHOULD NOT wait for the peer's settings to arrive before responding +to other streams, as it cannot assume the peer's settings to arrive in a timely +manner. This is because the packet carrying the settings can be lost, or the +peer might prioritize the transmission of the control stream below other +streams. ## HTTP/2 Error Codes From 4664b5c90834fce8e0affffcf66d697ddee2d3f7 Mon Sep 17 00:00:00 2001 From: Kazuho Oku Date: Fri, 23 Aug 2019 12:10:38 +0900 Subject: [PATCH 3/6] MUST NOT wait for peer's SETTINGS before sending one's own --- draft-ietf-quic-http.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index ba36a59781..9673c28f54 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -1330,11 +1330,13 @@ If an endpoint receives a SETTINGS frame on a different stream, the endpoint MUST respond with a connection error of type HTTP_WRONG_STREAM. SETTINGS parameters are not negotiated; they describe characteristics of the -sending peer, which can be used by the receiving peer. However, a negotiation -can be implied by the use of SETTINGS - each peer uses SETTINGS to advertise a -set of supported values. The definition of the setting would describe how each -peer combines the two sets to conclude which choice will be used. SETTINGS does -not provide a mechanism to identify when the choice takes effect. +sending peer, which can be used by the receiving peer. An endpoint MUST NOT wait +for the peer's SETTINGS frame to arrive before sending it's own SETTINGS frame. +However, a negotiation can be implied by the use of SETTINGS - each peer uses +SETTINGS to advertise a set of supported values. The definition of the setting +would describe how each peer combines the two sets to conclude which choice will +be used. SETTINGS does not provide a mechanism to identify when the choice +takes effect. Different values for the same parameter can be advertised by each peer. For example, a client might be willing to consume a very large response header, From fd556c0dc334cd92d9200a84c457a187d94f7053 Mon Sep 17 00:00:00 2001 From: Kazuho Oku Date: Tue, 27 Aug 2019 06:17:08 +0900 Subject: [PATCH 4/6] Revert "MUST NOT wait for peer's SETTINGS before sending one's own", as it's stated elsewhere (pointed out by @MikeBishop) This reverts commit 4664b5c90834fce8e0affffcf66d697ddee2d3f7. --- draft-ietf-quic-http.md | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 9673c28f54..ba36a59781 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -1330,13 +1330,11 @@ If an endpoint receives a SETTINGS frame on a different stream, the endpoint MUST respond with a connection error of type HTTP_WRONG_STREAM. SETTINGS parameters are not negotiated; they describe characteristics of the -sending peer, which can be used by the receiving peer. An endpoint MUST NOT wait -for the peer's SETTINGS frame to arrive before sending it's own SETTINGS frame. -However, a negotiation can be implied by the use of SETTINGS - each peer uses -SETTINGS to advertise a set of supported values. The definition of the setting -would describe how each peer combines the two sets to conclude which choice will -be used. SETTINGS does not provide a mechanism to identify when the choice -takes effect. +sending peer, which can be used by the receiving peer. However, a negotiation +can be implied by the use of SETTINGS - each peer uses SETTINGS to advertise a +set of supported values. The definition of the setting would describe how each +peer combines the two sets to conclude which choice will be used. SETTINGS does +not provide a mechanism to identify when the choice takes effect. Different values for the same parameter can be advertised by each peer. For example, a client might be willing to consume a very large response header, From d71650f5bef557df54e2eff2844b9c06dfc91671 Mon Sep 17 00:00:00 2001 From: Kazuho Oku Date: Tue, 27 Aug 2019 06:29:58 +0900 Subject: [PATCH 5/6] MUST send SETTINGS, SHOULD NOT block, clarify why --- draft-ietf-quic-http.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index ba36a59781..ae1057962f 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -1386,18 +1386,20 @@ value the implementation selects. Additional settings can be defined by extensions to HTTP/3; see {{extensions}} for more details. -#### Initialization +#### Initialization {#settings-initialization} An HTTP implementation MUST NOT send frames or requests which would be invalid based on its current understanding of the peer's settings. -All settings begin at an initial value. Each endpoint MAY use these initial -values to send messages before the peer's SETTINGS frame has arrived. When -the SETTINGS frame arrives, any settings are changed to their new values. +All settings begin at an initial value. Each endpoint SHOULD use these initial +values to send messages before the peer's SETTINGS frame has arrived. This is +because packets carrying the settings can be lost, or the peers might prioritize +the transmission of the control stream below other streams. When the SETTINGS +frame arrives, any settings are changed to their new values. This removes the need to wait for the SETTINGS frame before sending messages. Endpoints MUST NOT require any data to be received from the peer prior to -sending the SETTINGS frame; settings SHOULD be sent as soon as the transport is +sending the SETTINGS frame; settings MUST be sent as soon as the transport is ready to send data. For servers, the initial value of each client setting is the default value. @@ -2159,11 +2161,9 @@ the settings identifier space in HTTP/3 is substantially larger (62 bits versus 16 bits), so many HTTP/3 settings have no equivalent HTTP/2 code point. See {{iana-settings}}. -An endpoint SHOULD NOT wait for the peer's settings to arrive before responding -to other streams, as it cannot assume the peer's settings to arrive in a timely -manner. This is because the packet carrying the settings can be lost, or the -peer might prioritize the transmission of the control stream below other -streams. +As QUIC streams might arrive out-of-order, endpoints are advised to not wait for +the peers' settings to arrive before responding to other streams. See +{{settings-initialization}}. ## HTTP/2 Error Codes From 29ce7d634cd16dbbaf9d9659c38b055f5448a38e Mon Sep 17 00:00:00 2001 From: Kazuho Oku Date: Tue, 27 Aug 2019 16:30:25 +0900 Subject: [PATCH 6/6] simplify to avoid endorsing such behavior --- draft-ietf-quic-http.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index ae1057962f..4b6f9e24bf 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -1392,10 +1392,9 @@ An HTTP implementation MUST NOT send frames or requests which would be invalid based on its current understanding of the peer's settings. All settings begin at an initial value. Each endpoint SHOULD use these initial -values to send messages before the peer's SETTINGS frame has arrived. This is -because packets carrying the settings can be lost, or the peers might prioritize -the transmission of the control stream below other streams. When the SETTINGS -frame arrives, any settings are changed to their new values. +values to send messages before the peer's SETTINGS frame has arrived, as packets +carrying the settings can be lost or delayed. When the SETTINGS frame arrives, +any settings are changed to their new values. This removes the need to wait for the SETTINGS frame before sending messages. Endpoints MUST NOT require any data to be received from the peer prior to