jiebi/CodeConvo huggingface dataset:
Servers are encouraged to maintain open connections for as long as possible, but are permitted to terminate idle connections if necessary.  When either endpoint chooses to close the transport-level <del> TCP connection, the terminating endpoint SHOULD first send a GTFO so that both endpoints can reliably determine whether previously sent frames have been processed and gracefully complete or terminate any necessary remaining tasks. </del> <ins> TCP connection, the terminating endpoint SHOULD first send a (GOAWAY) frame so that both endpoints can reliably determine whether previously sent frames have been processed and gracefully complete or terminate any necessary remaining tasks. </ins> 9.2.
Bit 2 is reserved for future use. <del> Bit 3 being set indicates that the Pad High field is present. This bit MUST NOT be set unless the PAD_LOW flag is also set. </del> <ins> Bit 3 being set indicates that the Pad Low field is present. </ins> <del> Bit 4 being set indicates that the Pad Low field is present. </del> <ins> Bit 4 being set indicates that the Pad High field is present. This bit MUST NOT be set unless the PAD_LOW flag is also set. </ins> DATA frames MUST be associated with a stream.  If a DATA frame is received whose stream identifier field is 0x0, the recipient MUST
The encoding and decoding of header fields relies on some components and concepts: <del> A name-value pair.  Both name and value are sequences of octets. </del> <ins> A name-value pair.  Both the name and value are treated as opaque sequences of octets. </ins> The header table (see header.table) is a component used to <del> associate stored header fields to index values.  The data stored in this table is in first-in, first-out order. </del> <ins> associate stored header fields to index values. </ins> The static table (see static.table) is a component used to associate static header fields to index values.  This data is
unordered set of references to entries in the header table.  This is used for the differential encoding of a new header set. <del> A header set is a potentially ordered group of header fields that are encoded jointly.  A complete set of key-value pairs contained in a HTTP request or response is a header set. </del> <ins> A header set is an unordered group of header fields that are encoded jointly.  A complete set of key-value pairs contained in a HTTP request or response is a header set. </ins> A header field can be represented in encoded form either as a literal or as an index (see header.representation).
a header table and a reference set.  Everything else is either immutable or conceptual. <del> Using HTTP, messages are exchanged between a client and a server in both direction.  To keep the encoding of header fields in each direction independent from the other direction, there is one encoding context for each direction. The header fields contained in a PUSH_PROMISE frame sent by a server to a client are encoded within the same context as the header fields contained in the HEADERS frame corresponding to a response sent from the server to the client. </del> <ins> HTTP messages are exchanged between a client and a server in both directions.  The encoding of header fields in each direction is independent from the other direction.  There is a single encoding context for each direction used to encode all header fields sent in that direction. </ins> 3.1.2.
The encoder decides how to update the header table and as such can control how much memory is used by the header table.  To limit the <del> memory requirements on the decoder side, the header table size is strictly bounded (see maximum.table.size). </del> <ins> memory requirements of the decoder, the header table size is strictly bounded (see maximum.table.size). </ins> The header table is updated during the processing of a set of header field representations (see header.representation.processing).
endpoint will send for the identified stream.  Setting this flag causes the stream to enter one of StreamStates. <del> Bit 2 is reserved for future use. </del> <ins> Bit 2 being set indicates that this frame is the last for the current segment.  Intermediaries MUST NOT coalesce frames across a segment boundary and MUST preserve segment boundaries when forwarding frames. </ins> Bit 3 being set indicates that the Pad Low field is present.
Implementations MUST support all of the settings defined by this specification and MAY support additional settings defined by <del> extensions.  Unsupported or unrecognized settings MUST be ignored. New settings MUST NOT be defined or implemented in a way that requires endpoints to understand them in order to communicate successfully. </del> <ins> extensions to this protocol.  Unsupported or unrecognized settings MUST be ignored.  New settings MUST NOT be defined or implemented in a way that requires endpoints to understand them in order to communicate successfully. </ins> Each setting in a SETTINGS frame replaces the existing value for that setting.  Settings are processed in the order in which they appear,
conveyed by other means.  As such, a HTTP/2 message containing Connection MUST be treated as malformed. <del> This means that an intermediary transforming a HTTP/1.x message to </del> <ins> This means that an intermediary transforming an HTTP/1.x message to </ins> HTTP/2 will need to remove any header fields nominated by the Connection header field, along with the Connection header field itself.  Such intermediaries SHOULD also remove other connection-
The PUSH_PROMISE frame defines the following flags: PUSH_PROMISE frames MUST be associated with an existing, peer- <del> initiated stream.  If the stream identifier field specifies the value 0x0, a recipient MUST respond with a ConnectionErrorHandler of type </del> <ins> initiated stream.  The stream identifier of a PUSH_PROMISE frame indicates the stream it is associated with.  If the stream identifier field specifies the value 0x0, a recipient MUST respond with a ConnectionErrorHandler of type </ins> .
segment boundary and MUST preserve segment boundaries when forwarding frames. <del> Bit 5 being set indicates that the Pad Low field is present. </del> <ins> Bit 4 being set indicates that the Pad Low field is present. </ins> <del> Bit 6 being set indicates that the Pad High field is present. </del> <ins> Bit 5 being set indicates that the Pad High field is present. </ins> This bit MUST NOT be set unless the PAD_LOW flag is also set. Endpoints that receive a frame with PAD_HIGH set and PAD_LOW cleared MUST treat this as a ConnectionErrorHandler of type
The CONTINUATION frame includes optional padding.  Padding fields and flags are identical to those defined for DATA. <ins> 6.11. The ALTSVC frame (type=0xa) advertises the availability of an alternative service to the client.  It can be sent at any time for an existing client-initiated stream or stream 0, and is intended to allow servers to load balance or otherwise segment traffic; see AltSvc for details (in particular, Section 2.4, which outlines client handling of alternative services). An ALTSVC frame on a client-initiated stream indicates that the conveyed alternative service is associated with the origin of that stream. An ALTSVC frame on stream 0 indicates that the conveyed alternative service is associated with the origin contained in the Origin field of the frame.  An association with an origin that the client does not consider authoritative for the current connection MUST be ignored. The ALTSVC frame is intended for receipt by clients; a server that receives an ALTSVC frame MUST treat it as a connection error of type PROTOCOL_ERROR. The ALTSVC frame contains the following fields: PID_LEN: An unsigned, 8-bit integer indicating the length, in bytes, of the PROTOCOL-ID field. Reserved: for future use. Port: An unsigned, 16-bit integer indicating the port that the alternative service is available upon. Max-Age: An unsigned, 32-bit integer indicating the freshness lifetime of the alternative service association, as per AltSvc, Section 2.2. Protocol-ID: A sequence of bytes (length determined by PID_LEN) containing the ALPN protocol identifier of the alternative service. HOST_LEN: An unsigned, 8-bit integer indicating the length, in 8-bit characters, of the Host field. Host: A sequence of characters (length determined by HOST_LEN) containing an ASCII string indicating the host that the alternative service is available upon. Origin: An optional sequence of characters (length determined by ORGN_LEN) containing ASCII serialisation of an origin (RFC6454, Section 6.2) that the alternate service is applicable to. The ALTSVC frame does not define any flags. </ins> 7. Error codes are 32-bit fields that are used in
streams.  Most importantly, priority can be used to select streams for transmitting frames when there is limited capacity for sending. <del> Each stream is prioritized into a group.  Each group is identified using an identifier that is selected by the client.  Each group is </del> <ins> Stream can be prioritized by marking them as dependent on the completion of other streams (pri-depend).  Each dependency is </ins> assigned a relative weight, a number that is used to determine the relative proportion of available resources that are assigned to that <del> group. Within a priority group, streams can also be marked as being dependent on the completion of other streams. </del> <ins> dependency. </ins> Explicitly setting the priority for a stream is input to a prioritization process.  It does not guarantee any particular
frame.  Providing prioritization information is optional, so default values are used if no explicit indicator is provided (pri-default). <del> Explicit prioritization information can be provided for a stream to either allocate the stream to a priority group (pri-group), or to create a dependency on another stream (pri-depend). </del> 5.3.1. <del> All streams are assigned a priority group.  Each priority group is allocated a 31-bit identifier and an integer weight between 1 to 256 (inclusive). Specifying a priority group and weight for a stream causes the stream to be assigned to the identified priority group and for the weight for the group to be changed to the new value. Resources are divided proportionally between priority groups based on their weight.  For example, a priority group with weight 4 ideally receives one third of the resources allocated to a stream with weight 12. 5.3.2. </del> Each stream can be given an explicit dependency on another stream. Including a dependency expresses a preference to allocate resources <del> to the identified stream rather than to the dependent stream. A stream that is dependent on another stream becomes part of the priority group of the stream it depends on.  It belongs to the same dependency tree as the stream it depends on. </del> <ins> to the identified stream rather than to the dependent stream.  Each dependency is allocated an integer weight between 1 to 256 (inclusive). </ins> <del> A stream that is assigned directly to a priority group is not dependent on any other stream.  It is the root of a dependency tree inside its priority group. </del> <ins> The connection is the root of the dependency tree.  A stream that is not dependent on any other stream is given a stream dependency of 0x0 to signify the connection. </ins> When assigning a dependency on another stream, by default, the stream is added as a new dependency of the stream it depends on.  For
stream A, this results in a dependency order of A followed by D followed by B and C. <del> Streams are ordered into several dependency trees within their priority group.  Each dependency tree within a priority group SHOULD be allocated the same amount of resources. Inside a dependency tree, a dependent stream SHOULD only be allocated resources if the streams that it depends on are either closed, or it is not possible to make progress on them. </del> <ins> Inside the dependency tree, a dependent stream SHOULD only be allocated resources if the streams that it depends on are either closed, or it is not possible to make progress on them. </ins> <del> Streams with the same dependencies SHOULD be allocated the same amount of resources.  Thus, if streams B and C depend on stream A, and if no progress can be made on A, streams B and C are given an equal share of resources. </del> <ins> Streams with the same dependencies SHOULD be allocated resources proportionally based on their weight.  Thus, if stream B depends on stream A with weight 4, and C depends on stream A with weight 12, and if no progress can be made on A, stream B ideally receives one third of the resources allocated to stream C. </ins> A stream MUST NOT depend on itself.  An endpoint MAY either treat this as a StreamErrorHandler of type , or assign pri-default to the stream. <del> 5.3.3. </del> <ins> 5.3.2. </ins> Stream priorities are changed using the <del> frame.  Setting a priority group and weight causes a stream to become part of the identified group, and not dependent on any other stream. Setting a dependency causes a stream to become dependent on the identified stream, which can cause the reprioritized stream to move to a new priority group. All streams that are dependent on a reprioritized stream move with it.  Setting a dependency with the exclusive flag for a reprioritized stream moves all the dependencies of the stream it depends on to become dependencies of the reprioritized stream. </del> <ins> frame.  Setting a dependency causes a stream to become dependent on the identified stream.  All streams that are dependent on a reprioritized stream move with it.  Setting a dependency with the exclusive flag for a reprioritized stream moves all the dependencies of the stream it depends on to become dependencies of the reprioritized stream. </ins> <del> 5.3.4. </del> <ins> 5.3.3. </ins> When a stream is closed, its dependencies can be moved to become dependent on the stream the closed stream depends on, if any, or to <del> become new dependency tree roots otherwise. </del> <ins> become dependent on the connection otherwise.  The weights of new dependencies SHOULD be assigned by distributing the weight of the dependency of the closed stream proportionally based on the weights of its dependencies. </ins> It is possible for a stream to become closed while prioritization information that creates a dependency on that stream is in transit.
An endpoint receiving a frame that changes the priority of a closed stream SHOULD alter the <del> weight of the priority group, or the dependencies of the streams that depend on it, if it has retained enough state to do so. Priority group information is part of the priority state of a stream. Priority groups that contain only closed streams can be assigned a weight of zero. </del> <ins> dependencies of the streams that depend on it, if it has retained enough state to do so. </ins> <del> The number of priority groups cannot exceed the number of non-closed streams.  This includes streams in the "reserved" state.  Priority state size for peer-initiated streams is limited by the value of .  Reserved streams do not count toward the concurrent stream limit of either peer, but only the endpoint that creates the reservation needs to maintain priority information.  Thus, the total amount of priority state for non-closed streams can be limited by an endpoint. 5.3.5. </del> <ins> 5.3.4. </ins> <del> Providing priority information is optional.  Streams are assigned to a priority group with an identifier equal to the stream identifier and a weight of 16. </del> <ins> Providing priority information is optional.  Streams are assigned a dependency on the connection with a weight of 16. </ins> <del> PushResources initially depend on their associated stream. </del> <ins> PushResources initially depend on their associated stream with a weight of 16. </ins> 5.4.
Padding size low bits.  This field is only present if the PAD_LOW flag is set. <del> A single reserved bit.  This field is optional and is only present if the PRIORITY_GROUP flag is set. A 31-bit identifier for a priority group, see StreamPriority. This field is optional and is only present if the PRIORITY_GROUP flag is set. An 8-bit weight for the identified priority group, see StreamPriority.  Add one to the value to obtain a weight between 1 and 256.  This field is optional and is only present if the PRIORITY_GROUP flag is set. </del> A single bit flag indicates that the stream dependency is exclusive, see StreamPriority.  This field is optional and is only <del> present if the PRIORITY_DEPENDENCY flag is set. </del> <ins> present if the PRIORITY flag is set. </ins> A 31-bit stream identifier for the stream that this stream depends on, see StreamPriority.  This field is optional and is only <del> present if the PRIORITY_DEPENDENCY flag is set. </del> <ins> present if the PRIORITY flag is set. An 8-bit weight for the identified stream dependency, see StreamPriority.  Add one to the value to obtain a weight between 1 and 256.  This field is optional and is only present if the PRIORITY flag is set. </ins> A HeaderBlock.
The PRIORITY frame (type=0x2) specifies the StreamPriority.  It can be sent at any time for an existing stream.  This enables <del> reprioritisation of existing streams. </del> <ins> reprioritization of existing streams. </ins> The payload of a PRIORITY frame contains the following fields: <del> A single reserved bit.  This field is optional and is only present if the PRIORITY_GROUP flag is set. A 31-bit identifier for a priority group, see StreamPriority. This field is optional and is only present if the PRIORITY_GROUP flag is set. An 8-bit weight for the identified priority group, see StreamPriority.  Add one to the value to obtain a weight between 1 and 256.  This field is optional and is only present if the PRIORITY_GROUP flag is set. </del> A single bit flag indicates that the stream dependency is <del> exclusive, see StreamPriority.  This field is optional and is only present if the PRIORITY_DEPENDENCY flag is set. </del> <ins> exclusive, see StreamPriority. </ins> A 31-bit stream identifier for the stream that this stream depends <del> on, see StreamPriority.  This field is optional and is only present if the PRIORITY_DEPENDENCY flag is set. The PRIORITY frame defines the following flags: </del> <ins> on, see StreamPriority. </ins> <del> A PRIORITY frame MUST have exactly one of the PRIORITY_GROUP and PRIORITY_DEPENDENCY flags set.  Receipt of a PRIORITY frame with either none or both these flags set MUST be treated as a StreamErrorHandler of type </del> <ins> An 8-bit weight for the identified stream dependency, see StreamPriority.  Add one to the value to obtain a weight between 1 and 256. </ins> <del> . </del> <ins> The PRIORITY frame does not define any flags. </ins> The PRIORITY frame is associated with an existing stream.  If a PRIORITY frame is received with a stream identifier of 0x0, the
. <ins> Bit 6 being set indicates that the data in the frame has been compressed with GZIP compression (RFC1952).  The compression only applies to the frame in which it is signalled, and no compression state is carried over from frame to frame.  An endpoint MUST NOT send a DATA frame with the COMPRESSED flag set unless it receives a parameter set to a value of 1.  An endpoint that has not both set this parameter to 1 and had it acknowledged MUST treat the receipt of a DATA frame with the COMPRESSED flag set as a ConnectionErrorHandler of type . </ins> DATA frames MUST be associated with a stream.  If a DATA frame is received whose stream identifier field is 0x0, the recipient MUST respond with a ConnectionErrorHandler of type
clients to abandon automatic retry of requests if a GOAWAY frame is lost. <ins> A client that is unable to retry requests loses all requests that are in flight when the server closes the connection.  This is especially true for intermediaries that might not be serving clients using HTTP/2.  A server that is attempting to gracefully shut down a connection SHOULD send an initial GOAWAY frame with the last stream identifier set to 2 -1 and a code.  This signals to the client that a shutdown is imminent and that no further requests can be initiated.  After waiting at least one round trip time, the server can send another GOAWAY frame with an updated last stream identifier.  This ensures that a connection can be cleanly shut down without losing requests. </ins> After sending a GOAWAY frame, the sender can discard frames for streams with identifiers higher than the identified last stream. However, any frames that alter connection state cannot be completely
. <ins> 10.5.1. A large HeaderBlock can cause an implementation to commit a large amount of state.  In servers and intermediaries, header fields that are critical to routing, such as ":authority", ":path", and ":scheme" are not guaranteed to be present early in the header block.  In particular, values that are in the reference set cannot be emitted until the header block ends. This can prevent streaming of the header fields to their ultimate destination, and forces the endpoint to buffer the entire header block.  Since there is no hard limit to the size of a header block, an endpoint could be forced to exhaust available memory. A server that receives a larger header block than it is willing to handle can send an HTTP 431 (Request Header Fields Too Large) status code RFC6585.  A client can discard responses that it cannot process. The header block MUST be processed to ensure a consistent connection state, unless the connection is closed. </ins> 10.6. HTTP/2 enables greater use of compression for both header fields
. The PRIORITY frame can be sent on a stream in any of the "reserved <del> (remote)", "open", "half closed (local)", or "half closed (remote)" states, though it cannot be sent between consecutive frames that comprise a single HeaderBlock.  Note that this frame could arrive after processing or frame sending has completed, which would cause it to have no effect.  For a stream that is in the "half closed (remote)" state, this frame can only affect processing of the stream and not frame transmission. </del> <ins> (remote)", "open", "half closed (local)", "half closed (remote)", or "closed" states, though it cannot be sent between consecutive frames that comprise a single HeaderBlock.  Note that this frame could arrive after processing or frame sending has completed, which would cause it to have no effect on the current stream.  For a stream that is in the "half closed (remote)" or "closed" - state, this frame can only affect processing of the current stream and not frame transmission. The PRIORITY frame is the only frame that can be sent for a closed stream.  This allows for the reprioritization of a group of dependent streams by altering the priority of the parent stream.  However, a PRIORITY frame sent on a closed stream risks being ignored due to the peer having discarded priority state information for that stream. </ins> 6.4.