jiebi/CodeConvo huggingface dataset:
MUST terminate the connection with a ConnectionErrorHandler of type COMPRESSION_ERROR if it does not decompress a field block. <ins> A decoding error in a field block MUST be treated as a ConnectionErrorHandler of type COMPRESSION_ERROR. 4.3.1. Field compression is stateful.  Each endpoint has an HPACK encoder context and an HPACK decoder context that are used for encoding and decoding all field blocks.  COMPRESSION defines the dynamic table, which is the primary state for each context. The dynamic table has a maximum size that is set by an HPACK decoder. An endpoint communicates the size chosen by its HPACK decoder context using the SETTINGS_HEADER_TABLE_SIZE setting; see SettingValues. When a connection is established, the dynamic table size for the HPACK decoder and encoder at both endpoints starts at 4,096 bytes, the initial value of the SETTINGS_HEADER_TABLE_SIZE setting. Any change to the maximum value set using SETTINGS_HEADER_TABLE_SIZE takes effect when the endpoint SettingsSync.  The HPACK encoder at that endpoint can set the dynamic table to any size up to the maximum value set by the decoder.  An HPACK encoder declares the size of the dynamic table with a Dynamic Table Size Update instruction (COMPRESSION). Once an endpoint acknowledges a change to SETTINGS_HEADER_TABLE_SIZE that reduces the maximum below the current size of the dynamic table, its HPACK encoder MUST start the next field block with a Dynamic Table Size Update instruction that sets the dynamic table to a size that is less than or equal to the reduced maximum; see COMPRESSION. An endpoint MUST treat a field block that follows an acknowledgment of the reduction to the maximum dynamic table size as a ConnectionErrorHandler of type COMPRESSION_ERROR if it does not start with an conformant Dynamic Table Size Update instruction. </ins> 5. A "stream" is an independent, bidirectional sequence of frames
delimiters could be used to cause recipients to incorrectly interpret a message, which could be exploited by an attacker. <ins> HttpHeaders does not include specific rules for validation of pseudo- header fields.  If the values of these fields are used, additional validation is necessary.  This is particularly important where , , and are combined to form a single URI string (RFC3986).  Similar problems might occur when that URI or just are combined with 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 the HTTP ABNF grammar from HTTP.  Intermediaries that do not perform
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
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
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
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
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.
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
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.
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.
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.
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
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
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
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.
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
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.
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
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.
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
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
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
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
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
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.
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.
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.
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.
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
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:
An 8-bit field reserved for frame-type specific boolean flags. <del> 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. The remaining flags can be assigned semantics specific to the indicated frame type.  Flags that have no defined semantics for a particular frame type MUST be ignored, and MUST be left unset (0) when sending. </del> <ins> Flags are assigned semantics specific to the indicated frame type. Flags that have no defined semantics for a particular frame type MUST be ignored, and MUST be left unset (0) when sending. </ins> A reserved 1-bit field.  The semantics of this bit are undefined and the bit MUST remain unset (0) when sending and MUST be ignored