jiebi/CodeConvo huggingface dataset:
Code change:
: This sentence reads oddly. As it appears that the problem in question causes TLS handshake failures, we updated accordingly. Please let us know if this is incorrect. Original: To avoid this problem causing TLS handshake failures, deployments of HTTP/2 that use TLS 1.2 MUST support TLSECDHERSAWITHAES128GCMSHA256 [TLS-ECDHE] with the P-256 elliptic curve [RFC8422]. Currently: To avoid this problem, which causes TLS handshake failures, deployments of HTTP/2 that use TLS 1.2 MUST support TLSECDHERSAWITHAES128GCMSHA256 [TLS-ECDHE] with the P-256 elliptic curve [RFC8422].

Related discussion:
text: The list of prohibited cipher suites includes the cipher suite that TLS 1.2 makes mandatory, which means that TLS 1.2 deployments could have non-intersecting sets of permitted cipher suites.  To avoid this <del> problem causing TLS handshake failures, deployments of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS- ECDHE with the P-256 elliptic curve RFC8422. </del> <ins> problem, which causes TLS handshake failures, deployments of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS-ECDHE with the P-256 elliptic curve RFC8422. </ins> Note that clients might advertise support of cipher suites that are prohibited in order to allow for connection to servers that do not
Code change:
: Should "Content-Length" be enclosed in "" elements in the XML file? We ask because we see three instances of " header field" in the XML for Original:
Probably, yes.

Related discussion:
text: An intermediary that receives any field that requires removal before forwarding (see HTTP) MUST remove or replace those header fields when forwarding messages.  Additionally, intermediaries should take care <del> when forwarding messages containing Content-Length fields to ensure that the message is malformed.  This ensures that if the message is translated into HTTP/1.1 at any point the framing will be correct. </del> <ins> when forwarding messages containing fields to ensure that the message is malformed.  This ensures that if the message is translated into HTTP/1.1 at any point the framing will be correct. </ins> 10.4.
Code change:
: We had trouble parsing this sentence. Does "The use of field section compression and flow control depend" mean "The use of (1) field section compression and (2) flow control depends", or does it mean "Flow control and the use of field section compression depend"? Original: The use of field section compression and flow control depend on a commitment of resources for storing a greater amount of state. Possibly ("Using ... depends"): Using field section compression and flow control depends on a commitment of resources for storing a greater amount of state.
The former is the correct variant, I think.
Suggesting instead:

Related discussion:
text: 10.5. An HTTP/2 connection can demand a greater commitment of resources to <del> operate than an HTTP/1.1 connection.  The use of field section compression and flow control depend on a commitment of resources for storing a greater amount of state.  Settings for these features ensure that memory commitments for these features are strictly bounded. </del> <ins> operate than an HTTP/1.1 connection.  Both field section compression and flow control depend on a commitment of a greater amount of state. Settings for these features ensure that memory commitments for these features are strictly bounded. </ins> The number of PUSH_PROMISE frames is not constrained in the same fashion.  A client that accepts server push SHOULD limit the number
Code change:
: Please confirm that "i.e.," is correct here (in which case "SETTINGS changes, small frames, field section compression" should be "SETTINGS changes, small frames, and field section compression") instead of "e.g.,". Original: Most of the features that might be exploited for denial of service - i.e., SETTINGS changes, small frames, field section compression - have legitimate uses.
I think that this should probably e.g., not i.e.

Related discussion:
text: implementations might be subject to denial of service attack: Most of the features that might be exploited for denial of service -- <del> i.e., SETTINGS changes, small frames, field section compression -- </del> <ins> such as SETTINGS changes, small frames, field section compression -- </ins> have legitimate uses.  These features become a burden only when they are used unnecessarily or to excess.
Code change:
Values is correct in the first case, but the second should be "a value" by which it means "any value".
and 10.9: Please confirm that these instances of "value" should not be "values". Original: These include the value of settings, the manner in which flow-control windows are managed, the way priorities are allocated to streams, the timing of reactions to stimulus, and the handling of any features that are controlled by settings. ... Ensuring that processing time is not dependent on the value of secrets is the best defense against any form of timing attack. Possibly: These include the values of settings, the manner in which flow-control windows are managed, the way priorities are allocated to streams, the timing of reactions to stimulus, and the handling of any features that are controlled by settings. ... Ensuring that processing time is not dependent on secret values is the best defense against any form of timing attack.
These should both be "values".
Values is correct in the first case, but the second should be "a value" by which it means "any value".

Related discussion:
text: Several characteristics of HTTP/2 provide an observer an opportunity to correlate actions of a single client or server over time.  These <del> include the value of settings, the manner in which flow-control </del> <ins> include the values of settings, the manner in which flow-control </ins> windows are managed, the way priorities are allocated to streams, the timing of reactions to stimulus, and the handling of any features that are controlled by settings.
Code change:
Values is correct in the first case, but the second should be "a value" by which it means "any value".
and 10.9: Please confirm that these instances of "value" should not be "values". Original: These include the value of settings, the manner in which flow-control windows are managed, the way priorities are allocated to streams, the timing of reactions to stimulus, and the handling of any features that are controlled by settings. ... Ensuring that processing time is not dependent on the value of secrets is the best defense against any form of timing attack. Possibly: These include the values of settings, the manner in which flow-control windows are managed, the way priorities are allocated to streams, the timing of reactions to stimulus, and the handling of any features that are controlled by settings. ... Ensuring that processing time is not dependent on secret values is the best defense against any form of timing attack.
These should both be "values".
Values is correct in the first case, but the second should be "a value" by which it means "any value".

Related discussion:
text: delivery, leaving only request order and the delivery of responses as sources of timing variability. <del> Ensuring that processing time is not dependent on the value of secrets is the best defense against any form of timing attack. </del> <ins> Ensuring that processing time is not dependent on the value of a secret is the best defense against any form of timing attack. </ins> 11.
Code change:
Error when stream identifier field is 0x0 is not stream error but connection error because it is impossible to send RST_STREAM of 0x0.

Related discussion:
text: The PRIORITY frame is associated with an existing stream.  If a PRIORITY frame is received with a stream identifier of 0x0, the <del> recipient MUST respond with a StreamErrorHandler of type </del> <ins> recipient MUST respond with a ConnectionErrorHandler of type </ins> PROTOCOL_ERROR. 3.8.4.
Code change:
Error when stream identifier field is 0x0 is not stream error but connection error because it is impossible to send RST_STREAM of 0x0.

Related discussion:
text: The HEADERS frame is associated with an existing stream.  If a HEADERS frame is received with a stream identifier of 0x0, the <del> recipient MUST respond with a StreamErrorHandler of type </del> <ins> recipient MUST respond with a ConnectionErrorHandler of type </ins> PROTOCOL_ERROR. The HEADERS frame changes the connection state as defined in
Code change:
It is no longer used after d5a8faeaa605bdff7b96287d72913b4b742104cf
I've avoided renumbering of codes when removing things. We probably need to have a big renumber event at some point, but there is no harm in having gaps for now.
Thanks Martin. It makes it easier for us on the SPDY side :) On Wed Jun 12 2013 at 9:37:50 AM, martinthomson EMAIL wrote:
NAME I've updated the commit just to remove only the unused error code. Please don't forget to renumber others in the future.

Related discussion:
text: The endpoint detected that its peer violated the flow control protocol. <del> The endpoint received a frame for an inactive stream. </del> The endpoint received a frame after a stream was half-closed. The endpoint received a frame that was larger than the maximum
Code change:
As discussed in the interim, 8-byte PING frame, opaque octets that MUST be included regardless of whether they are used.

Related discussion:
text: idle connection is still functional.  PING frames can be sent from any endpoint. <del> PING frames consist of an arbitrary, variable-length sequence of octets.  Receivers of a PING send a response PING frame with the PONG </del> <ins> In addition to the frame header, PING frames MUST contain 8 additional octets of opaque data.  A sender can utilize this payload in any manner it wishes but MUST include the octets even if they are unused.  Receivers of a PING send a response PING frame with the PONG </ins> flag set and precisely the same sequence of octets back to the sender as soon as possible.
Code change:
Curious why the connection flow control window initial size is 64K (65536 bytes) but the stream flow control window initial size is 65535 bytes. The negative flow control example (taken from the SPDY spec) states that the initial stream flow control window is 64K (the SPDY/3 value).
I have to stop trusting Will's edits. He, rightfully, challenged the use of SETTINGS to end connection-level flow control because WINDOW_UPDATE provided another way to do the same, and two ways to do the same thing is bad. I'll fix that up.

Related discussion:
text: part of the connection header. Prior to receiving a SETTINGS frame that sets a value for <del> SETTINGS_INITIAL_WINDOW_SIZE, a client can only use the default </del> <ins> SETTINGS_INITIAL_WINDOW_SIZE, an endpoint can only use the default </ins> initial window size when sending flow controlled frames.  Similarly, the connection flow control window is set to the default initial window size until a WINDOW_UPDATE frame is received. A SETTINGS frame can alter the initial flow control window size for all current streams.  When the value of SETTINGS_INITIAL_WINDOW_SIZE <del> changes, a receiver MUST adjust the size of all flow control windows that it maintains by the difference between the new value and the old value. </del> <ins> changes, a receiver MUST adjust the size of all stream flow control windows that it maintains by the difference between the new value and the old value.  A SETTINGS frame cannot alter the connection flow control window. </ins> A change to SETTINGS_INITIAL_WINDOW_SIZE could cause the available space in a flow control window to become negative.  A sender MUST
Code change:
Curious why the connection flow control window initial size is 64K (65536 bytes) but the stream flow control window initial size is 65535 bytes. The negative flow control example (taken from the SPDY spec) states that the initial stream flow control window is 64K (the SPDY/3 value).
I have to stop trusting Will's edits. He, rightfully, challenged the use of SETTINGS to end connection-level flow control because WINDOW_UPDATE provided another way to do the same, and two ways to do the same thing is bad. I'll fix that up.

Related discussion:
text: not obligated to maintain the available flow control window for streams that it is no longer sending on. <del> Flow control can be disabled for all streams or the connection using </del> <ins> Flow control can be disabled for all streams on the connection using </ins> the SETTINGS_FLOW_CONTROL_OPTIONS setting.  An implementation that <del> does not wish to perform flow control can use this in the initial SETTINGS exchange. </del> <ins> does not wish to perform stream flow control can use this in the initial SETTINGS exchange. </ins> Flow control can be disabled for an individual stream or the overall connection by sending a WINDOW_UPDATE with the END_FLOW_CONTROL flag
Code change:
All other frame descriptions specify explicitly if the frame type does not have any type-specific flags. The PRIORITY frame description should do the same if there are no flags.

Related discussion:
text: The payload of a PRIORITY frame contains a single reserved bit and a 31-bit priority. <ins> The PRIORITY frame does not define any type-specific flags. </ins> The PRIORITY frame is associated with an existing stream.  If a PRIORITY frame is received with a stream identifier of 0x0, the recipient MUST respond with a ConnectionErrorHandler of type
Code change:
This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.

Related discussion:
text: An 8-bit field reserved for frame-type specific boolean flags. <del> The least significant bit (0x1) - the FINAL bit - is defined for all frame types as an indication that this frame is the last the endpoint will send for the identified stream.  Setting this flag causes the stream to enter the StreamHalfClose.  Implementations MUST process the FINAL bit for all frames whose stream identifier field is not 0x0.  The FINAL bit MUST NOT be set on frames that use a stream identifier of 0. </del> <ins> The least significant bit (0x1) - the END_STREAM bit - is defined for all frame types as an indication that this frame is the last the endpoint will send for the identified stream.  Setting this flag causes the stream to enter the StreamHalfClose. Implementations MUST process the END_STREAM bit for all frames whose stream identifier field is not 0x0.  The END_STREAM bit MUST NOT be set on frames that use a stream identifier of 0. </ins> The remaining flags can be assigned semantics specific to the indicated frame type.  Flags that have no defined semantics for a
Code change:
This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.

Related discussion:
text: 3.4.3. <del> When an endpoint sends a frame for a stream with the FINAL flag set, the stream is considered to be half-closed for that endpoint. </del> <ins> When an endpoint sends a frame for a stream with the END_STREAM flag set, the stream is considered to be half-closed for that endpoint. </ins> Subsequent frames MUST NOT be sent by that endpoint for the half closed stream for the remaining duration of the HTTP/2.0 connection. <del> When both endpoints have sent frames with the FINAL flag set, the stream is considered to be fully closed. </del> <ins> When both endpoints have sent frames with the END_STREAM flag set, the stream is considered to be fully closed. </ins> If an endpoint receives additional frames for a stream that was previously half-closed by the sending peer, the recipient MUST respond with a StreamErrorHandler of type STREAM_CLOSED. An endpoint that has not yet half-closed a stream by sending the <del> FINAL flag can continue sending frames on the stream. </del> <ins> END_STREAM flag can continue sending frames on the stream. </ins> It is not necessary for an endpoint to half-close a stream for which it has not sent any frames.  This allows endpoints to use fully
Code change:
This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.

Related discussion:
text: A stream that only has frames sent in one direction can be tentatively considered to be closed once a frame containing a <del> FINAL flag is sent.  The active sender on the stream MUST be </del> <ins> END_STREAM flag is sent.  The active sender on the stream MUST be </ins> prepared to receive frames after closing the stream. Either peer can send a RST_STREAM control frame at any time to
Code change:
This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.

Related discussion:
text: single reserved bit and a 31-bit priority; see StreamPriority. HEADERS+PRIORITY uses the same flags as the HEADERS frame, except <del> that a HEADERS+PRIORITY frame with a CONTINUES bit MUST be followed by another HEADERS+PRIORITY frame.  See HEADERS for any flags. </del> <ins> that a HEADERS+PRIORITY frame without the END_HEADERS flag set MUST be followed by another HEADERS+PRIORITY frame.  See HEADERS for any flags. </ins> HEADERS+PRIORITY frames MUST be associated with a stream.  If a HEADERS+PRIORITY frame is received whose stream identifier field is
Code change:
This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.

Related discussion:
text: promised streams fully close as well. PUSH_PROMISE uses the same flags as the HEADERS frame, except that a <del> PUSH_PROMISE frame with a CONTINUES bit MUST be followed by another PUSH_PROMISE frame.  See HEADERS for any flags. </del> <ins> PUSH_PROMISE frame without the END_HEADERS flag set MUST be followed by another PUSH_PROMISE frame.  See HEADERS for any flags. </ins> Promised streams are not required to be used in order promised.  The PUSH_PROMISE only reserves stream identifiers for later use.
Code change:
This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.

Related discussion:
text: Additional type-specific flags for the HEADERS frame are: <del> The CONTINUES bit indicates that this frame does not contain the entire payload necessary to provide a complete set of headers. </del> <ins> The END_HEADERS bit indicates that this frame contains the entire payload necessary to provide a complete set of headers. </ins> The payload for a complete set of headers is provided by a <del> sequence of HEADERS frames, terminated by a HEADERS frame without the CONTINUES bit.  Once the sequence terminates, the payload of all HEADERS frames are concatenated and interpreted as a single </del> <ins> sequence of HEADERS frames, terminated by a HEADERS frame with the END_HEADERS flag set.  Once the sequence terminates, the payload of all HEADERS frames are concatenated and interpreted as a single </ins> block. <del> A HEADERS frame that includes a CONTINUES bit MUST be followed by a HEADERS frame for the same stream.  A receiver MUST treat the </del> <ins> A HEADERS frame without the END_HEADERS flag set MUST be followed by a HEADERS frame for the same stream.  A receiver MUST treat the </ins> receipt of any other type of frame or a frame on a different stream as a ConnectionErrorHandler of type PROTOCOL_ERROR.
Code change:
This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.

Related discussion:
text: window and the connection flow control window.  The sender MUST NOT send a flow controlled frame with a length that exceeds the space available in either of the flow control windows advertised by the <del> receiver.  Frames with zero length with the FINAL flag set (for </del> <ins> receiver.  Frames with zero length with the END_STREAM flag set (for </ins> example, an empty data frame) MAY be sent if there is no available space in either flow control window.
Code change:
This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.

Related discussion:
text: 3.8.10.4. After a receiver reads in a frame that marks the end of a stream (for <del> example, a data stream with a FINAL flag set), it MUST cease </del> <ins> example, a data stream with a END_STREAM flag set), it MUST cease </ins> transmission of WINDOW_UPDATE frames for that stream.  A sender is not obligated to maintain the available flow control window for streams that it is no longer sending on.
Code change:
This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.

Related discussion:
text: 4.2.2. The client initiates a request by sending a HEADERS+PRIORITY frame. <del> Requests that do not contain a body MUST set the FINAL flag, </del> <ins> Requests that do not contain a body MUST set the END_STREAM flag, </ins> indicating that the client intends to send no further data on this stream, unless the server intends to push resources (see <del> PushResources).  HEADERS+PRIORITY frame does not contain the FINAL flag for requests that contain a body.  The body of a request follows as a series of DATA frames.  The last DATA frame sets the FINAL flag to indicate the end of the body. </del> <ins> PushResources).  HEADERS+PRIORITY frame does not contain the END_STREAM flag for requests that contain a body.  The body of a request follows as a series of DATA frames.  The last DATA frame sets the END_STREAM flag to indicate the end of the body. </ins> The header fields included in the HEADERS+PRIORITY frame contain all of the HTTP header fields associated with an HTTP request.  The
Code change:
This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.

Related discussion:
text: The server responds to a client request using the same stream identifier that was used by the request.  An HTTP response begins with a HEADERS frame.  An HTTP response body consists of a series of <del> DATA frames.  The last data frame contains a FINAL flag to indicate the end of the response.  A response that contains no body (such as a 204 or 304 response) consists only of a HEADERS frame that contains the FINAL flag to indicate no further data will be sent on the stream. </del> <ins> DATA frames.  The last data frame contains a END_STREAM flag to indicate the end of the response.  A response that contains no body (such as a 204 or 304 response) consists only of a HEADERS frame that contains the END_STREAM flag to indicate no further data will be sent on the stream. </ins> The response status line is unfolded into name-value pairs like other HTTP header fields and must be present: