jiebi/CodeConvo huggingface dataset:
Code change:
: We had trouble parsing this sentence. Is a word missing? If neither suggestion below is correct, please clarify what "any frame carrying ... SETTINGS" refers to. Original: A frame size error in a frame that could alter the state of the entire connection MUST be treated as a connection error (); this includes any frame carrying a field block () (that is, HEADERS, PUSHPROMISE, and CONTINUATION), SETTINGS, and any frame with a stream identifier of 0. Suggestion (... and a SETTINGS frame): A frame size error in a frame that could alter the state of the entire connection MUST be treated as a connection error (); this includes any frame carrying a field block () (that is, HEADERS, PUSHPROMISE, and CONTINUATION) and a SETTINGS frame, and any frame with a stream identifier of 0. Suggestion (... or a SETTINGS frame): A frame size error in a frame that could alter the state of the entire connection MUST be treated as a connection error (); this includes any frame carrying a field block () (that is, HEADERS, PUSH_PROMISE, and CONTINUATION) or a SETTINGS frame, and any frame with a stream identifier of 0.
Suggestion 1 is correct.
I think that the list structure is supposed to be... includes: any frame carrying a field block (...), a SETTINGS frame, and any frame with a stream identifier of 0. Which suggests option 3, in my PR.
LGTM.

Related discussion:
text: mandatory frame data.  A frame size error in a frame that could alter the state of the entire connection MUST be treated as a ConnectionErrorHandler; this includes any frame carrying a FieldBlock <del> (that is, HEADERS, PUSH_PROMISE, and CONTINUATION), SETTINGS, and any frame with a stream identifier of 0. </del> <ins> (that is, HEADERS, PUSH_PROMISE, and CONTINUATION), a SETTINGS frame, and any frame with a stream identifier of 0. </ins> Endpoints are not obligated to use all available space in a frame. Responsiveness can be improved by using frames that are smaller than
Code change:
This looks terrible, but it's the form that the RFC we cite uses (also, RFC 1323).
: We changed "Flow Control Performance" to "Flow-Control Performance" per the title of ("Flow-Control Principles"). Please let us know any concerns. Original: 5.2.3. Flow Control Performance Currently: 5.2.3. Flow-Control Performance
and 5.2.3: Should "bandwidth-delay product" be written as "bandwidth * delay product" per RFC 7323? Original: Note, however, that this can lead to suboptimal use of available network resources if flow control is enabled without knowledge of the bandwidth-delay product (see [RFC7323]). Even with full awareness of the current bandwidth-delay product, implementation of flow control can be difficult. ... If an endpoint cannot ensure that its peer always has available flow control window space that is greater than the peer's bandwidth-delay product on this connection, its receive throughput will be limited by HTTP/2 flow control.
I think "bandwidth-delay product" is the standard representation of the term. It's not a term specific to this document but a broader term of art. I recommend not taking this suggestion.
Thanks, I hate it.

Related discussion:
text: employ flow control to limit the amount of memory a peer can consume. Note, however, that this can lead to suboptimal use of available network resources if flow control is enabled without knowledge of the <del> bandwidth-delay product (see RFC7323). </del> <ins> bandwidth * delay product (see RFC7323). </ins> <del> Even with full awareness of the current bandwidth-delay product, </del> <ins> Even with full awareness of the current bandwidth * delay product, </ins> implementation of flow control can be difficult.  Endpoints MUST read and process HTTP/2 frames from the TCP receive buffer as soon as data is available.  Failure to read promptly could lead to a deadlock when
Code change:
This looks terrible, but it's the form that the RFC we cite uses (also, RFC 1323).
: We changed "Flow Control Performance" to "Flow-Control Performance" per the title of ("Flow-Control Principles"). Please let us know any concerns. Original: 5.2.3. Flow Control Performance Currently: 5.2.3. Flow-Control Performance
and 5.2.3: Should "bandwidth-delay product" be written as "bandwidth * delay product" per RFC 7323? Original: Note, however, that this can lead to suboptimal use of available network resources if flow control is enabled without knowledge of the bandwidth-delay product (see [RFC7323]). Even with full awareness of the current bandwidth-delay product, implementation of flow control can be difficult. ... If an endpoint cannot ensure that its peer always has available flow control window space that is greater than the peer's bandwidth-delay product on this connection, its receive throughput will be limited by HTTP/2 flow control.
I think "bandwidth-delay product" is the standard representation of the term. It's not a term specific to this document but a broader term of art. I recommend not taking this suggestion.
Thanks, I hate it.

Related discussion:
text: 5.2.3. If an endpoint cannot ensure that its peer always has available flow <del> control window space that is greater than the peer's bandwidth-delay product on this connection, its receive throughput will be limited by HTTP/2 flow control.  This will result in degraded performance. </del> <ins> control window space that is greater than the peer's bandwidth * delay product on this connection, its receive throughput will be limited by HTTP/2 flow control.  This will result in degraded performance. </ins> Sending timely WINDOW_UPDATE frames can improve performance. Endpoints will want to balance the need to improve receive throughput
Code change:
: As this sentence seemed to indicate that the sender itself was sent, we updated the text to clarify that the GOAWAY is sent. Please let us know if this update is incorrect. Original: Once sent, the sender will ignore frames sent on streams initiated by the receiver if the stream has an identifier higher than the included last stream identifier. Currently: Once the GOAWAY is sent, the sender will ignore frames sent on streams initiated by the receiver if the stream has an identifier higher than the included last stream identifier.

Related discussion:
text: GOAWAY frame, the identified stream is the highest-numbered stream initiated by the client. <del> Once sent, the sender will ignore frames sent on streams initiated by the receiver if the stream has an identifier higher than the included last stream identifier.  Receivers of a GOAWAY frame MUST NOT open additional streams on the connection, although a new connection can be established for new streams. </del> <ins> Once the GOAWAY is sent, the sender will ignore frames sent on streams initiated by the receiver if the stream has an identifier higher than the included last stream identifier.  Receivers of a GOAWAY frame MUST NOT open additional streams on the connection, although a new connection can be established for new streams. </ins> If the receiver of the GOAWAY has sent data on streams with a higher stream identifier than what is indicated in the GOAWAY frame, those
Code change:
: We had trouble parsing this sentence. If the suggested text is not correct, please clarify what prevents cookie-pairs from being sent on multiple field lines. Original: This header field contains multiple values, but does not use a COMMA (",") as a separator, which prevents cookie-pairs from being sent on multiple field lines (see Section 5.2 of [HTTP]). Suggested: This header field contains multiple values but does not use a COMMA (",") as a separator, thereby preventing cookie-pairs from being sent on multiple field lines (see Section 5.2 of [HTTP]).

Related discussion:
text: 8.2.3. The COOKIE uses a semicolon (";") to delimit cookie-pairs (or <del> "crumbs").  This header field contains multiple values, but does not use a COMMA (",") as a separator, which prevents cookie-pairs from being sent on multiple field lines (see HTTP).  This can </del> <ins> "crumbs").  This header field contains multiple values but does not use a COMMA (",") as a separator, thereby preventing cookie-pairs from being sent on multiple field lines (see HTTP).  This can </ins> significantly reduce compression efficiency as updates to individual cookie-pairs would invalidate any field lines that are stored in the HPACK table.
Code change:
I had to add to one use of :authority.
and subsequent: Please note that, per the rest of this cluster of documents, we have placed the terms beginning with a colon (":method", ":scheme", etc.) in double quotes where they appear in running text. Please review, and let us know any objections.

Related discussion:
text: The following pseudo-header fields are defined for HTTP/2 requests: <del> All HTTP/2 requests MUST include exactly one valid value for the </del> <ins> All HTTP/2 requests MUST include exactly one valid value for the " </ins> <del> , </del> <ins> ", " </ins> <del> , and </del> <ins> ", and " </ins> <del> pseudo-header fields, unless it is a CONNECT.  An HTTP request that </del> <ins> " pseudo-header fields, unless it is a CONNECT.  An HTTP request that </ins> omits mandatory pseudo-header fields is malformed. Individual HTTP/2 requests do not carry an explicit indicator of
Code change:
I had to add to one use of :authority.
and subsequent: Please note that, per the rest of this cluster of documents, we have placed the terms beginning with a colon (":method", ":scheme", etc.) in double quotes where they appear in running text. Please review, and let us know any objections.

Related discussion:
text: 8.3.2. <del> For HTTP/2 responses, a single </del> <ins> For HTTP/2 responses, a single " </ins> <del> pseudo-header field is defined that carries the HTTP status code </del> <ins> " pseudo-header field is defined that carries the HTTP status code </ins> field (see HTTP).  This pseudo-header field MUST be included in all responses, including interim responses; otherwise, the response is malformed.
Code change:
I had to add to one use of :authority.
and subsequent: Please note that, per the rest of this cluster of documents, we have placed the terms beginning with a colon (":method", ":scheme", etc.) in double quotes where they appear in running text. Please review, and let us know any objections.

Related discussion:
text: HTTP cache.  They MAY be made available to the application separately. <del> The server MUST include a value in the </del> <ins> The server MUST include a value in the " </ins> <del> pseudo-header field for which the server is authoritative (see </del> <ins> " pseudo-header field for which the server is authoritative (see </ins> authority).  A client MUST treat a PUSH_PROMISE for which the server is not authoritative as a StreamErrorHandler of type PROTOCOL_ERROR.
Code change:
I had to add to one use of :authority.
and subsequent: Please note that, per the rest of this cluster of documents, we have placed the terms beginning with a colon (":method", ":scheme", etc.) in double quotes where they appear in running text. Please review, and let us know any objections.

Related discussion:
text: The header fields in PUSH_PROMISE and any subsequent CONTINUATION frames MUST be a valid and complete set of HttpRequest.  The server <del> MUST include a method in the </del> <ins> MUST include a method in the " </ins> <del> pseudo-header field that is safe and cacheable.  If a client receives a PUSH_PROMISE that does not include a complete and valid set of header fields or the </del> <ins> " pseudo-header field that is safe and cacheable.  If a client receives a PUSH_PROMISE that does not include a complete and valid set of header fields or the " </ins> <del> pseudo-header field identifies a method that is not safe, it MUST </del> <ins> " pseudo-header field identifies a method that is not safe, it MUST </ins> respond on the promised stream with a StreamErrorHandler of type PROTOCOL_ERROR.
Code change:
I had to add to one use of :authority.
and subsequent: Please note that, per the rest of this cluster of documents, we have placed the terms beginning with a colon (":method", ":scheme", etc.) in double quotes where they appear in running text. Please review, and let us know any objections.

Related discussion:
text: malformed. A proxy that supports CONNECT establishes a TCP to the host and port <del> identified in the </del> <ins> identified in the " </ins> <del> pseudo-header field.  Once this connection is successfully </del> <ins> " pseudo-header field.  Once this connection is successfully </ins> established, the proxy sends a HEADERS frame containing a 2xx series status code to the client, as defined in HTTP.
Code change:
I had to add to one use of :authority.
and subsequent: Please note that, per the rest of this cluster of documents, we have placed the terms beginning with a colon (":method", ":scheme", etc.) in double quotes where they appear in running text. Please review, and let us know any objections.

Related discussion:
text: HttpHeaders does not include specific rules for validation of pseudo- header fields.  If the values of these fields are used, additional <del> validation is necessary.  This is particularly important where </del> <ins> validation is necessary.  This is particularly important where " </ins> <del> , </del> <ins> ", " </ins> <del> , and </del> <ins> ", and " </ins> <del> are combined to form a single URI string (RFC3986).  Similar problems might occur when that URI or just </del> <ins> " are combined to form a single URI string (RFC3986).  Similar problems might occur when that URI or just " </ins> <del> are combined with </del> <ins> " are combined with " </ins> <del> to construct a request line (as in HTTP11).  Simple concatenation is not secure unless the input values are fully validated. </del> <ins> " to construct a request line (as in HTTP11).  Simple concatenation is not secure unless the input values are fully validated. </ins> An intermediary can reject fields that contain invalid field names or values for other reasons, in particular those that do not conform to
Code change:
Also, use .
and 9.1.1: We quoted "https" where preceded by "resources". Please let us know if this is incorrect. Original: CONNECT is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with https resources. ... For https resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI. Currently (best viewed in the .html or .pdf output): CONNECT is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with "https" resources. ... For "https" resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI.
Folded into .
: We made quoting consistent around lowercase instances of "http" and "https" when describing URIs or schemed URIs, per quoted instances in , 3.2, and 10.1. Please let us know any objections. Original: http and https schemed URIs http or https schemed URIs http or https URIs Currently: "http" and "https" schemed URIs "http" or "https" schemed URIs "http" or "https" URIs

Related discussion:
text: For TCP connections without TLS, this depends on the host having resolved to the same IP address. <del> For </del> <ins> For " </ins> <del> resources, connection reuse additionally depends on having a </del> <ins> " resources, connection reuse additionally depends on having a </ins> certificate that is valid for the host in the URI.  The certificate presented by the server MUST satisfy any checks that the client would perform when forming a new TLS connection for the host in the URI.  A
Code change:
Also, use .
and 9.1.1: We quoted "https" where preceded by "resources". Please let us know if this is incorrect. Original: CONNECT is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with https resources. ... For https resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI. Currently (best viewed in the .html or .pdf output): CONNECT is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with "https" resources. ... For "https" resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI.
Folded into .
: We made quoting consistent around lowercase instances of "http" and "https" when describing URIs or schemed URIs, per quoted instances in , 3.2, and 10.1. Please let us know any objections. Original: http and https schemed URIs http or https schemed URIs http or https URIs Currently: "http" and "https" schemed URIs "http" or "https" schemed URIs "http" or "https" URIs

Related discussion:
text: HTTP/2 relies on the HTTP definition of authority for determining whether a server is authoritative in providing a given response (see <del> HTTP).  This relies on local name resolution for the "http" URI scheme and the authenticated server identity for the "https" scheme. </del> <ins> HTTP).  This relies on local name resolution for the " " URI scheme and the authenticated server identity for the " " scheme. </ins> 10.2.
Code change:
CLoses .
: Does "the same sequence of frames as defined in " mean "the same sequence of frames as that defined in " or "the same sequence of frames, as defined in "? It appears to us that it means "URL that defined in ", but please advise. Original: The server uses this stream to transmit an HTTP response, using the same sequence of frames as defined in
It means "as that defined in Section 8.1".

Related discussion:
text: the pushed response as a HttpResponse on a server-initiated stream that uses the promised stream identifier.  The server uses this stream to transmit an HTTP response, using the same sequence of <del> frames as defined in HttpFraming.  This stream becomes StreamStates after the initial HEADERS frame is sent. </del> <ins> frames as that defined in HttpFraming.  This stream becomes StreamStates after the initial HEADERS frame is sent. </ins> Once a client receives a PUSH_PROMISE frame and chooses to accept the pushed response, the client SHOULD NOT issue any requests for the
Code change:
: Does "as" mean "while" or "because" in this sentence? Original: Connections that remain idle can become broken as some middleboxes (for instance, network address translators or load balancers) silently discard connection bindings.
"As" means "because" in this sentence.

Related discussion:
text: In addition to these mechanisms, the PING frame provides a way for a client to easily test a connection.  Connections that remain idle can <del> become broken as some middleboxes (for instance, network address translators or load balancers) silently discard connection bindings. The PING frame allows a client to safely test whether a connection is still active without sending a request. </del> <ins> become broken, because some middleboxes (for instance, network address translators or load balancers) silently discard connection bindings.  The PING frame allows a client to safely test whether a connection is still active without sending a request. </ins> 8.8.
Code change:
This is awkward, but this is better.
and 8.8.4: Because "control data and a request header and message content" reads a bit oddly, we changed it to "control data and a request header with message content" per "control data and a request header with no message content" in Please let us know if this is incorrect. Original: An HTTP POST request that includes control data and a request header and message content is transmitted as one HEADERS frame, followed by zero or more CONTINUATION frames containing the request header, followed by one or more DATA frames, with the last CONTINUATION (or HEADERS) frame having the ENDHEADERS flag set and the final DATA frame having the ENDSTREAM flag set: ... A response that includes control data and a response header and message content is transmitted as a HEADERS frame, followed by zero or more CONTINUATION frames, followed by one or more DATA frames, with the last DATA frame in the sequence having the ENDSTREAM flag set: Currently: An HTTP POST request that includes control data and a request header with message content is transmitted as one HEADERS frame, followed by zero or more CONTINUATION frames containing the request header, followed by one or more DATA frames, with the last CONTINUATION (or HEADERS) frame having the ENDHEADERS flag set and the final DATA frame having the ENDSTREAM flag set: ... A response that includes control data and a response header with message content is transmitted as a HEADERS frame, followed by zero or more CONTINUATION frames, followed by one or more DATA frames, with the last DATA frame in the sequence having the ENDSTREAM flag set:

Related discussion:
text: 8.8.3. An HTTP POST request that includes control data and a request header <del> and message content is transmitted as one HEADERS frame, followed by </del> <ins> with message content is transmitted as one HEADERS frame, followed by </ins> zero or more CONTINUATION frames containing the request header, followed by one or more DATA frames, with the last CONTINUATION (or HEADERS) frame having the END_HEADERS flag set and the final DATA
Code change:
This is awkward, but this is better.
and 8.8.4: Because "control data and a request header and message content" reads a bit oddly, we changed it to "control data and a request header with message content" per "control data and a request header with no message content" in Please let us know if this is incorrect. Original: An HTTP POST request that includes control data and a request header and message content is transmitted as one HEADERS frame, followed by zero or more CONTINUATION frames containing the request header, followed by one or more DATA frames, with the last CONTINUATION (or HEADERS) frame having the ENDHEADERS flag set and the final DATA frame having the ENDSTREAM flag set: ... A response that includes control data and a response header and message content is transmitted as a HEADERS frame, followed by zero or more CONTINUATION frames, followed by one or more DATA frames, with the last DATA frame in the sequence having the ENDSTREAM flag set: Currently: An HTTP POST request that includes control data and a request header with message content is transmitted as one HEADERS frame, followed by zero or more CONTINUATION frames containing the request header, followed by one or more DATA frames, with the last CONTINUATION (or HEADERS) frame having the ENDHEADERS flag set and the final DATA frame having the ENDSTREAM flag set: ... A response that includes control data and a response header with message content is transmitted as a HEADERS frame, followed by zero or more CONTINUATION frames, followed by one or more DATA frames, with the last DATA frame in the sequence having the ENDSTREAM flag set:

Related discussion:
text: 8.8.4. <del> A response that includes control data and a response header and </del> <ins> A response that includes control data and a response header with </ins> message content is transmitted as a HEADERS frame, followed by zero or more CONTINUATION frames, followed by one or more DATA frames, with the last DATA frame in the sequence having the END_STREAM flag