From a48d8c22ab62ef630f5badbd772dea481969c76a Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Fri, 9 Dec 2016 13:16:50 -0800 Subject: [PATCH 1/7] Replace SETTINGS with EXTENDED_SETTINGS --- draft-ietf-quic-http.md | 183 ++++++++++++++++++++++++++++++++-------- 1 file changed, 146 insertions(+), 37 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 8fe071fadc..c541659537 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -429,16 +429,66 @@ Frame type 0x3 is reserved. ### SETTINGS {#frame-settings} -The SETTINGS frame (type=0x04) is unmodified from {{!RFC7540}} (so far). It MUST -only be sent on the connection control stream (Stream 3). - -As in HTTP/2, additional SETTINGS frames may be sent mid-connection by either -endpoint. - -TODO: -: Decide whether to acknowledge receipt of SETTINGS through empty SETTINGS - frames with ACK bit set, as in HTTP/2, or rely on transport- level - acknowledgment. +The SETTINGS frame (type=0x4) conveys configuration parameters that affect how +endpoints communicate, such as preferences and constraints on peer behavior, and +is substantially different from {{!RFC7540}}. Individually, a SETTINGS parameter +can also be referred to as a "setting". + +SETTINGS parameters are not negotiated; they describe characteristics of the +sending peer, which are used by the receiving peer. However, a negotiation can +be implied by the use of SETTINGS -- a peer uses SETTINGS to advertise a set of +supported values. The recipient can then choose which entries from this list are +also acceptable and proceed with the value it has chosen. (This choice could be +announced in a field of an extension frame, or in a value in SETTINGS.) + +Different values for the same parameter can be advertised by each peer. For +example, a server might support many different signing algorithms, while a +resource constrained client has only one or two that it can validate. + +A SETTINGS frame MAY be sent at any time by either endpoint over the lifetime +of the connection. + +Each parameter in a SETTINGS frame replaces any existing value for that +parameter. Parameters are processed in the order in which they appear, and a +receiver of a SETTINGS frame does not need to maintain any state other than the +current value of its parameters. Therefore, the value of a SETTINGS parameter is +the last value that is seen by a receiver. + +The SETTINGS frame defines the following flag: + + REQUEST_ACK (0x1): + : When set, bit 0 indicates that this frame contains values which the sender + wants to know were understood and applied. For more information, see + {{settings-synchronization}}. + +The payload of a SETTINGS frame consists of zero or more parameters, each +consisting of an unsigned 16-bit setting identifier and a length-prefixed binary +value. + +~~~~~~~~~~~~~~~ ++-------------------------------+-+-------------+---------------+ +| Identifier (16) |B| Length (15) | ++-------------------------------+-+-------------+---------------+ +| Contents (?) ... ++---------------------------------------------------------------+ +~~~~~~~~~~~~~~~ +{: #fig-ext-settings title="SETTINGS value format"} + +A zero-length content indicates that the setting value is a Boolean given by the +B bit. If Length is not zero, the B bit MUST be zero, and MUST be ignored by +receivers. The initial value of each setting is "false." + +An implementation MUST ignore the contents for any EXTENDED_SETTINGS identifier +it does not understand. + +SETTINGS frames always apply to a connection, never a single stream, and MUST +only be sent on the connection control stream (Stream 3). If an endpoint +receives an SETTINGS frame whose stream identifier field is anything other than +0x0, the endpoint MUST respond with a connection error. + +The SETTINGS frame affects connection state. A badly formed or incomplete +SETTINGS frame MUST be treated as a connection error (Section 5.4.1) of type +PROTOCOL_ERROR. #### Defined SETTINGS Parameters @@ -447,13 +497,12 @@ superseded by QUIC transport parameters in HTTP-over-QUIC. Below is a listing of how each HTTP/2 SETTINGS parameter is mapped: SETTINGS_HEADER_TABLE_SIZE: - : Sent in SETTINGS frame. + : An integer with a maximum value of 2^32 - 1. SETTINGS_ENABLE_PUSH: - : Sent in SETTINGS frame (TBD, currently set using QUIC "SPSH" connection - option) + : A Boolean - SETTINGS_MAX_CONCURRENT_STREAMS + SETTINGS_MAX_CONCURRENT_STREAMS: : QUIC requires the maximum number of incoming streams per connection to be specified in the initial crypto handshake, using the "MSPC" tag. Specifying SETTINGS_MAX_CONCURRENT_STREAMS in the SETTINGS frame is an error. @@ -468,14 +517,34 @@ how each HTTP/2 SETTINGS parameter is mapped: : This setting has no equivalent in QUIC. Specifying it in the SETTINGS frame is an error. - SETTINGS_MAX_HEADER_LIST_SIZE - : Sent in SETTINGS frame. + SETTINGS_MAX_HEADER_LIST_SIZE: + : An integer with a maximium value of 2^32 - 1. + +#### Settings Synchronization {#settings-synchronization} + +Some values in SETTINGS benefit from or require an understanding of when the +peer has received and applied the changed parameter values. In order to provide +such synchronization timepoints, the recipient of a SETTINGS frame MUST apply +the updated parameters as soon as possible upon receipt. The values in the +SETTINGS frame MUST be processed in the order they appear, with no other frame +processing between values. Unsupported parameters MUST be ignored. -As with HTTP/2, unknown SETTINGS parameters are tolerated but ignored. SETTINGS -parameters are acknowledged by the receiving peer, by sending an empty SETTINGS -frame in response with the ACK bit set. +Once all values have been processed, if the REQUEST_ACK flag was set, the +recipient MUST immediately emit a SETTINGS_ACK frame listing the identifiers +whose values were understood and applied. (If none of the values were +understood, the SETTINGS_ACK frame will be empty, but MUST still be sent.) Upon +receiving an SETTINGS_ACK frame, the sender of the altered parameters can rely +on the setting having been applied. +TODO: +: The above text was written for HTTP/2 -- QUIC has cross-stream timing issues +here that need to be solved. +If the sender of a SETTINGS frame with the REQUEST_ACK flag set does not +receive an acknowledgement within a reasonable amount of time, it MAY issue a +connection error ([RFC7540] Section 5.4.1) of type SETTINGS_TIMEOUT. + + ### PUSH_PROMISE {#frame-push-promise} The PUSH_PROMISE frame (type=0x05) is used to carry a request header set from @@ -533,6 +602,17 @@ CONTINUATION frames do not exist, since larger supported HEADERS/PUSH_PROMISE frames provide equivalent functionality. Frame type 0x9 is reserved. +### SETTINGS_ACK Frame {#frame-settings-ack} + +The SETTINGS_ACK frame (id = 0x0b) acknowledges receipt and application +of specific values in the peer's SETTINGS frame. It contains a list of +SETTINGS identifiers which the sender has understood and applied. This +list MAY be empty. + +Any SETTINGS_ACK frame whose length is not a multiple of two bytes MUST +be treated as a connection error ({{errors}}) of type +`FRAME_SIZE_ERROR`. + # Error Handling {#errors} The HTTP/2 error codes defined in Section 7 of {{!RFC7540}} map to QUIC error @@ -592,13 +672,18 @@ HTTP/2. # IANA Considerations -## Frame Types +## Existing Frame Types This document adds two new columns to the "HTTP/2 Frame Type" registry defined in {{!RFC7540}}: - Supported in HTTP/QUIC: - : Indicates whether the frame is also supported in this HTTP/QUIC mapping + Supported Protocols: + : Indicates which associated protocols use the frame type. Values MUST be one + of: + + - "HTTP/2 only" + - "HTTP/QUIC only" + - "Both" HTTP/QUIC Specification: : Indicates where this frame's behavior over QUIC is defined; required @@ -606,21 +691,45 @@ This document adds two new columns to the "HTTP/2 Frame Type" registry defined i Values for existing registrations are assigned by this document: - +---------------|------------------------|-------------------------+ - | Frame Type | Supported in HTTP/QUIC | HTTP/QUIC Specification | - |---------------|:----------------------:|-------------------------| - | DATA | No | N/A | - | HEADERS | Yes | {{frame-headers}} | - | PRIORITY | Yes | {{frame-priority}} | - | RST_STREAM | No | N/A | - | SETTINGS | Yes | {{frame-settings}} | - | PUSH_PROMISE | Yes | {{frame-push-promise}} | - | PING | No | N/A | - | GOAWAY | No | N/A | - | WINDOW_UPDATE | No | N/A | - | CONTINUATION | No | N/A | - +---------------|------------------------|-------------------------+ - + +---------------|---------------------|-------------------------+ + | Frame Type | Supported Protocols | HTTP/QUIC Specification | + |---------------|:-------------------:|-------------------------| + | DATA | HTTP/2 only | N/A | + | HEADERS | Both | {{frame-headers}} | + | PRIORITY | Both | {{frame-priority}} | + | RST_STREAM | HTTP/2 only | N/A | + | SETTINGS | Both | {{frame-settings}} | + | PUSH_PROMISE | Both | {{frame-push-promise}} | + | PING | HTTP/2 only | N/A | + | GOAWAY | HTTP/2 only | N/A | + | WINDOW_UPDATE | HTTP/2 only | N/A | + | CONTINUATION | HTTP/2 only | N/A | + +---------------|---------------------|-------------------------+ + +The "Specification" column is renamed to "HTTP/2 specification" and is only +required if the frame is supported over HTTP/2. + + +## New Frame Types + +This document adds one new entry to the "HTTP/2 Frame Type" registry defined in +{{!RFC7540}}: + + Frame Type: + : SETTINGS_ACK + + Code: + : 0x0b + + HTTP/2 Specification: + : N/A + + Supported Protocols: + : HTTP/QUIC only + + HTTP/QUIC Specification: + : {{frame-settings-ack}} + --- back # Contributors From 6915f0e463202608728fa6a72647143ea95d4e91 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Fri, 9 Dec 2016 15:10:13 -0800 Subject: [PATCH 2/7] Use a different example --- 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 c541659537..7dce2d3105 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -442,8 +442,8 @@ also acceptable and proceed with the value it has chosen. (This choice could be announced in a field of an extension frame, or in a value in SETTINGS.) Different values for the same parameter can be advertised by each peer. For -example, a server might support many different signing algorithms, while a -resource constrained client has only one or two that it can validate. +example, a client might permit a very large HPACK state table while a server +chooses to use a small one to conserve memory. A SETTINGS frame MAY be sent at any time by either endpoint over the lifetime of the connection. From b5ec771730359cc59a36e504bdff7777270cd458 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Fri, 9 Dec 2016 15:32:17 -0800 Subject: [PATCH 3/7] Martin's other feedback --- draft-ietf-quic-http.md | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 7dce2d3105..87f811d8d7 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -476,7 +476,8 @@ value. A zero-length content indicates that the setting value is a Boolean given by the B bit. If Length is not zero, the B bit MUST be zero, and MUST be ignored by -receivers. The initial value of each setting is "false." +receivers. The initial value of each setting is "false" unless otherwise +specified by the definition of the setting. An implementation MUST ignore the contents for any EXTENDED_SETTINGS identifier it does not understand. @@ -488,7 +489,13 @@ receives an SETTINGS frame whose stream identifier field is anything other than The SETTINGS frame affects connection state. A badly formed or incomplete SETTINGS frame MUST be treated as a connection error (Section 5.4.1) of type -PROTOCOL_ERROR. +PROTOCOL_ERROR. + +#### Integer encoding + +Settings which are integers are transmitted in network byte order. Leading +zero octets are permitted, but implementations SHOULD use only as many bytes as +are needed to represent the value. #### Defined SETTINGS Parameters @@ -500,7 +507,8 @@ how each HTTP/2 SETTINGS parameter is mapped: : An integer with a maximum value of 2^32 - 1. SETTINGS_ENABLE_PUSH: - : A Boolean + : Transmitted as a Boolean. The default remains "true" as specified in + {{!RFC7540}}. SETTINGS_MAX_CONCURRENT_STREAMS: : QUIC requires the maximum number of incoming streams per connection to be From 9d08e3d465204a29305327b936d9041503336c6c Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Mon, 12 Dec 2016 14:07:50 -0800 Subject: [PATCH 4/7] Diagram format for #54 again. --- draft-ietf-quic-http.md | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 35e2aa276a..c0b251886c 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -474,11 +474,13 @@ consisting of an unsigned 16-bit setting identifier and a length-prefixed binary value. ~~~~~~~~~~~~~~~ -+-------------------------------+-+-------------+---------------+ -| Identifier (16) |B| Length (15) | -+-------------------------------+-+-------------+---------------+ -| Contents (?) ... -+---------------------------------------------------------------+ + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Identifier (16) |B| Length (15) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Contents (?) ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~~~~~~~~~~~~~ {: #fig-ext-settings title="SETTINGS value format"} @@ -503,7 +505,8 @@ PROTOCOL_ERROR. Settings which are integers are transmitted in network byte order. Leading zero octets are permitted, but implementations SHOULD use only as many bytes as -are needed to represent the value. +are needed to represent the value. An integer MUST NOT be represented in more +bytes than would be used to transfer the maximum permitted value. #### Defined SETTINGS Parameters From 334bca26acf447258e33fc35d8a937ea00b16599 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Thu, 15 Dec 2016 14:17:17 -0800 Subject: [PATCH 5/7] Wording changes for Patrick --- 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 c0b251886c..b501b203c6 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -443,11 +443,11 @@ is substantially different from {{!RFC7540}}. Individually, a SETTINGS parameter can also be referred to as a "setting". SETTINGS parameters are not negotiated; they describe characteristics of the -sending peer, which are used by the receiving peer. However, a negotiation can -be implied by the use of SETTINGS -- a peer uses SETTINGS to advertise a set of -supported values. The recipient can then choose which entries from this list are -also acceptable and proceed with the value it has chosen. (This choice could be -announced in a field of an extension frame, or in a value in SETTINGS.) +sending peer, which can be used by the receiving peer. However, a negotiation +can be implied by the use of SETTINGS -- a peer uses SETTINGS to advertise a set +of supported values. The recipient can then choose which entries from this list +are also acceptable and proceed with the value it has chosen. (This choice could +be announced in a field of an extension frame, or in its own value in SETTINGS.) Different values for the same parameter can be advertised by each peer. For example, a client might permit a very large HPACK state table while a server From a5b2ff055b6e11dce2c9ed2c34117cd9b366bcea Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Thu, 15 Dec 2016 14:18:06 -0800 Subject: [PATCH 6/7] Possible SETTINGS_ACK proposal (#84) SETTING_ACK across all streams -- for #75 --- draft-ietf-quic-http.md | 100 ++++++++++++++++++++++++++++++---------- 1 file changed, 75 insertions(+), 25 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index b501b203c6..26275bae8e 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -157,6 +157,11 @@ additional framing. Note that a request or response without a body will cause this stream to be half-closed in the corresponding direction without transferring data. +Pairs of streams must be utilized sequentially, with no gaps. The data stream +MUST be reserved with the QUIC implementation when the message control stream +is opened or reserved, and MUST be closed after transferring the body, or else +closed immediately after sending the request headers if there is no body. + HTTP does not need to do any separate multiplexing when using QUIC - data sent over a QUIC stream always maps to a particular HTTP transaction. Requests and responses are considered complete when the corresponding QUIC streams are closed @@ -177,18 +182,19 @@ HTTP response on the same streams as the request. An HTTP message (request or response) consists of: 1. for a response only, zero or more header blocks (a sequence of HEADERS frames -with End Header Block set on the last) on the control stream containing the -message headers of informational (1xx) HTTP responses (see {{!RFC7230}}, Section -3.2 and {{!RFC7231}}, Section 6.2), + with End Header Block set on the last) on the control stream containing the + message headers of informational (1xx) HTTP responses (see {{!RFC7230}}, + Section 3.2 and {{!RFC7231}}, Section 6.2), 2. one header block on the control stream containing the message headers (see -{{!RFC7230}}, Section 3.2), + {{!RFC7230}}, Section 3.2), -3. the payload body (see {{!RFC7230}}, Section 3.3), sent on the data stream +3. the payload body (see {{!RFC7230}}, Section 3.3), sent on the data stream, 4. optionally, one header block on the control stream containing the -trailer-part, if present (see {{!RFC7230}}, Section 4.1.2). + trailer-part, if present (see {{!RFC7230}}, Section 4.1.2). +The data stream MUST be half-closed immediately after the transfer of the body. If the message does not contain a body, the corresponding data stream MUST still be half-closed without transferring any data. The "chunked" transfer encoding defined in Section 4.1 of {{!RFC7230}} MUST NOT be used. @@ -549,20 +555,38 @@ SETTINGS frame MUST be processed in the order they appear, with no other frame processing between values. Unsupported parameters MUST be ignored. Once all values have been processed, if the REQUEST_ACK flag was set, the -recipient MUST immediately emit a SETTINGS_ACK frame listing the identifiers -whose values were understood and applied. (If none of the values were -understood, the SETTINGS_ACK frame will be empty, but MUST still be sent.) Upon -receiving an SETTINGS_ACK frame, the sender of the altered parameters can rely -on the setting having been applied. - -TODO: -: The above text was written for HTTP/2 -- QUIC has cross-stream timing issues -here that need to be solved. - +recipient MUST immediately emit the following: + + - On the connection control stream, a SETTINGS_ACK frame listing the + identifiers whose values were understood and applied. (If none of the values + were understood, the SETTINGS_ACK frame will be empty, but MUST still be + sent.) + + - On each request control stream which is not in the "half-closed (local)" or + "closed" state, an empty SETTINGS_ACK frame. + +The SETTINGS_ACK frame on the connection control stream contains the highest +stream number which was open at the time the SETTINGS frame was received. All +streams with higher numbers can safely be assumed to have the new settings in +effect when they open. + +For already-open streams, the empty SETTINGS_ACK frame indicates the point at +which the new settings took effect, if they did so before the peer half-closed +the stream. If the peer closed the stream before receiving the SETTINGS frame, +the previous settings were in effect for the full lifetime of that stream. + +In certain conditions, the SETTINGS_ACK frame can be the first frame on a given +stream -- this simply indicates that the new settings apply from the beginning +of that stream. + If the sender of a SETTINGS frame with the REQUEST_ACK flag set does not -receive an acknowledgement within a reasonable amount of time, it MAY issue a -connection error ([RFC7540] Section 5.4.1) of type SETTINGS_TIMEOUT. - +receive full acknowledgement within a reasonable amount of time, it MAY issue a +connection error ([RFC7540] Section 5.4.1) of type SETTINGS_TIMEOUT. A full +acknowledgement has occurred when a SETTINGS_ACK frame has been received on the +connection control stream, and all message control streams with a Stream ID +through those given in the SETTINGS_ACK frame have either closed or had a +SETTINGS_ACK frame sent. + ### PUSH_PROMISE {#frame-push-promise} @@ -626,13 +650,39 @@ frames provide equivalent functionality. Frame type 0x9 is reserved. ### SETTINGS_ACK Frame {#frame-settings-ack} The SETTINGS_ACK frame (id = 0x0b) acknowledges receipt and application -of specific values in the peer's SETTINGS frame. It contains a list of -SETTINGS identifiers which the sender has understood and applied. This -list MAY be empty. +of specific values in the peer's SETTINGS frame. Depending on the stream where +it is sent, it takes two different forms. + +On the connection control stream, it contains information about how and when the +sender has processed the most recently-received SETTINGS frame, and has the +following payload: + +~~~~~~~~~~~~~~~ + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Highest Local Stream (32) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Highest Remote Stream (32) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Unrecognized Identifiers (*) ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +~~~~~~~~~~~~~~~ +{: #fig-settings-ack title="SETTINGS_ACK connection control stream format"} + + Highest Local Stream (32 bits): + : The highest locally-initiated Stream ID which is not in the "idle" state + + Highest Remote Stream (32 bits): + : The highest peer-initiated Stream ID which is not in the "idle" state + + Unrecognized Identifiers: + : A list of 16-bit SETTINGS identifiers which the sender has not understood + and therefore ignored. This list MAY be empty. -Any SETTINGS_ACK frame whose length is not a multiple of two bytes MUST -be treated as a connection error ({{errors}}) of type -`FRAME_SIZE_ERROR`. +On message control streams, the SETTINGS_ACK frame carries no payload, and is +strictly a synchronization marker for settings application. See +{{settings-synchronization}} for more detail. # Error Handling {#errors} From 10851ab18092eefe01c5d23d43ed87f126d4aefc Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Thu, 15 Dec 2016 14:32:51 -0800 Subject: [PATCH 7/7] More of Patrick's and Martin's feedback. --- draft-ietf-quic-http.md | 30 +++++++++++++++++------------- 1 file changed, 17 insertions(+), 13 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 26275bae8e..9e8d0046f4 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -555,12 +555,11 @@ SETTINGS frame MUST be processed in the order they appear, with no other frame processing between values. Unsupported parameters MUST be ignored. Once all values have been processed, if the REQUEST_ACK flag was set, the -recipient MUST immediately emit the following: +recipient MUST emit the following frames: - - On the connection control stream, a SETTINGS_ACK frame listing the - identifiers whose values were understood and applied. (If none of the values - were understood, the SETTINGS_ACK frame will be empty, but MUST still be - sent.) + - On the connection control stream, a SETTINGS_ACK frame + ({{frame-settings-ack}}) listing the identifiers whose values were not + understood. - On each request control stream which is not in the "half-closed (local)" or "closed" state, an empty SETTINGS_ACK frame. @@ -570,10 +569,11 @@ stream number which was open at the time the SETTINGS frame was received. All streams with higher numbers can safely be assumed to have the new settings in effect when they open. -For already-open streams, the empty SETTINGS_ACK frame indicates the point at -which the new settings took effect, if they did so before the peer half-closed -the stream. If the peer closed the stream before receiving the SETTINGS frame, -the previous settings were in effect for the full lifetime of that stream. +For already-open streams including the connection control stream, the +SETTINGS_ACK frame indicates the point at which the new settings took effect, if +they did so before the peer half-closed the stream. If the peer closed the +stream before receiving the SETTINGS frame, the previous settings were in effect +for the full lifetime of that stream. In certain conditions, the SETTINGS_ACK frame can be the first frame on a given stream -- this simply indicates that the new settings apply from the beginning @@ -582,10 +582,14 @@ of that stream. If the sender of a SETTINGS frame with the REQUEST_ACK flag set does not receive full acknowledgement within a reasonable amount of time, it MAY issue a connection error ([RFC7540] Section 5.4.1) of type SETTINGS_TIMEOUT. A full -acknowledgement has occurred when a SETTINGS_ACK frame has been received on the -connection control stream, and all message control streams with a Stream ID -through those given in the SETTINGS_ACK frame have either closed or had a -SETTINGS_ACK frame sent. +acknowledgement has occurred when: + + - All previous SETTINGS frames have been fully acknowledged, + + - A SETTINGS_ACK frame has been received on the connection control stream, + + - All message control streams with a Stream ID through those given in the + SETTINGS_ACK frame have either closed or received a SETTINGS_ACK frame. ### PUSH_PROMISE {#frame-push-promise}