jiebi/CodeConvo huggingface dataset:
octets associated with a stream.  One or more DATA frames are used, for instance, to carry HTTP request or response payloads. <del> The DATA frame does not define any type-specific flags. </del> <ins> The DATA frame defines the following flags: Bit 1 being set indicates that this frame is the last that the endpoint will send for the identified stream.  Setting this flag causes the stream to enter the StreamHalfClose. Bit 2 is reserved for future use. </ins> DATA frames MUST be associated with a stream.  If a DATA frame is received whose stream identifier field is 0x0, the recipient MUST
payload.  PING responses SHOULD given higher priority than any other frame. <del> The PING frame defines one type-specific flag: </del> <ins> The PING frame defines the following flags: </ins> <del> Bit 2 being set indicates that this PING frame is a PING response. </del> <ins> Bit 1 being set indicates that this PING frame is a PING response. </ins> An endpoint MUST set this flag in PING responses.  An endpoint MUST NOT respond to PING frames containing this flag.
Any number of HEADERS frames can may be sent on an existing stream at any time. <del> Additional type-specific flags for the HEADERS frame are: </del> <ins> The HEADERS frame defines the following flags: Bit 1 being set indicates that this frame is the last that the endpoint will send for the identified stream.  Setting this flag causes the stream to enter the StreamHalfClose. Bit 2 is reserved for future use. </ins> The END_HEADERS bit indicates that this frame contains the entire payload necessary to provide a complete set of headers.
respond with a StreamErrorHandler or ConnectionErrorHandler of type FLOW_CONTROL_ERROR if it is unable accept a frame. <del> The following additional flags are defined for the WINDOW_UPDATE frame: </del> <ins> The WINDOW_UPDATE frame defines the following flags: </ins> <del> Bit 2 being set indicates that flow control for the identified </del> <ins> Bit 1 being set indicates that flow control for the identified </ins> stream or connection has been ended; subsequent frames do not need to be flow controlled.
3.3. <del> Once the HTTP/2.0 connection is established, clients and servers can begin exchanging frames. </del> <ins> Once the HTTP/2.0 connection is established, endpoints can begin exchanging frames. </ins> 3.3.1. <del> HTTP/2.0 frames share a common base format consisting of an 8-byte header followed by 0 to 65535 bytes of data. </del> <ins> All frames share a common base format consisting of an 8-byte header followed by 0 to 65,535 octets of payload data. </ins> The fields of the frame header are defined as:
3.3.2. <del> Implementations with limited resources might not be capable of processing large frame sizes.  Such implementations MAY choose to place additional limits on the maximum frame size.  However, all implementations MUST be capable of receiving and processing frames containing at least 8192 octets of data. An implementation MUST terminate a stream immediately if it is unable to process a frame due it's size.  This is done by sending an RST_STREAM containing the FRAME_TOO_LARGE error code. </del> <ins> The maximum amount of payload data any frame can contain varies by frame type and use.  The absolute maximum amount of payload data any individual frame can contain is 65,535 octets.  All implementations SHOULD be capable of receiving and minimally processing frames up to this size. Certain frame types, such as PING (see PING), impose strict limits on the amount of payload data allowed.  Likewise, additional size limits can be set by specific application uses.  For instance, individual DATA and HEADERS frames used to express HTTP request and response messages (see HTTPLayer) are not permitted to exceed 16,383 octets of payload.  Sending endpoints MUST NOT exceed such limits. If an endpoint is unable to process a frame due to the payload size, or if the size exceeds a strictly defined limit, the endpoint MUST send a FRAME_TOO_LARGE error.  If the frame stream identifier is 0x0, this code MUST be sent as a connection error.  If the stream identifier is anything other than 0x0, it is sent as a stream error. </ins> 3.4.
(HTTP-p1).  The client makes an HTTP/1.1 request that includes an Upgrade header field identifying HTTP/2.0. <ins> Additional to the Upgrade request, anticipating that the server will likely respond with some HTTP/2.0 frames, the client MUST send the payload of its SETTINGS frame within the HTTP/1.1 header.  In particular, if the server does not know the client's initial preferences (as expressed in a SETTINGS frame), it could send too much data in its response, or reserve multiple streams via PUSH_PROMISE despite the client's preference to the contrary.  To avoid this situation, these SETTINGS MUST be communicated by the client to the server in advance of the first HTTP/2.0 message from the server: SETTINGS_MAX_CONCURRENT_STREAMS, SETTINGS_INITIAL_WINDOW_SIZE (SettingFormat). NOTE: There may be additional SETTINGS added later on, e.g., due to header compression (TBD). The SETTINGS are conveyed in the following hop-by-hop HTTP/1.1 header: HTTP2-Settings = "HTTP2-Settings" ":" token68 token68 is defined in HTTP-p7.  The value of HTTP2-Settings is set to the base64url encoding of the payload of the SETTINGS frame as defined in SettingFormat.  Other than the fact that these SETTINGS are communicated by the client via an HTTP/1.1 header, they are otherwise indistinguishable from SETTINGS and their handling as detailed in SettingFormat. </ins> For example: Requests that contain a request entity body MUST be sent in their <del> entirely before the client can send HTTP/2.0 frames.  This means that </del> <ins> entirety before the client can send HTTP/2.0 frames.  This means that </ins> a large request entity can block the use of the connection until it is completely sent.
An initial set of settings registrations can be found in SettingValues. <ins> 8.4. 8.4.1. This section describes a header field for registration in the Permanent Message Header Field Registry.  RFC3864 HTTP2-Settings http standard IETF RFC XXXX (this document) This header field is only used by the client in the Upgrade-based negotiation. The HTTP2-Settings header field is used in the Upgrade-based negotiation by the client.  It is sent from the client to the server to provide the payload for its SETTINGS frame in anticipation of the server responding with HTTP/2.0 frames. The HTTP2-Settings header field MUST NOT appear more than once in an HTTP request and MUST NOT appear at all in an HTTP response. </ins>
From this state either peer can send a frame with a END_STREAM flag set, which causes the stream to transition into one of the <del> "half closed" states: a client sending a END_STREAM flag causes the stream state to become "half closed (client)"; a server sending a END_STREAM flag causes the stream state to become "half closed (server)". </del> <ins> "half closed" states: an endpoint sending a END_STREAM flag causes the stream state to become "half closed (local)"; an endpoind receiving a END_STREAM flag causes the stream state to become "half closed (remote)". </ins> An endpoint can send RST_STREAM from this state, causing it to transition immediately to "closed".
knowledge about support for HTTP/2.0 uses the HTTP Upgrade mechanism (HTTP-p1).  The client makes an HTTP/1.1 request that includes an Upgrade header field identifying HTTP/2.0.  The HTTP/1.1 request MUST <del> include an Http2SettingsHeader header field. </del> <ins> include exactly one Http2SettingsHeader header field. </ins> Requests that contain a request entity body MUST be sent in their entirety before the client can send HTTP/2.0 frames.  This means that
3.2.1. <del> A client that upgrades from HTTP/1.1 to HTTP/2.0 MUST include an "HTTP2-Settings" header field.  The "HTTP2-Settings" header field is a hop-by-hop header field that includes settings that govern the </del> <ins> A client that upgrades from HTTP/1.1 to HTTP/2.0 MUST include exactly one "HTTP2-Settings" header field.  The "HTTP2-Settings" header field is a hop-by-hop header field that includes settings that govern the </ins> HTTP/2.0 connection, provided in anticipation of the server accepting the request to upgrade.  A server MUST reject an attempt to upgrade if this header is not present.
3.2.1. <del> A client that upgrades from HTTP/1.1 to HTTP/2.0 MUST include exactly one "HTTP2-Settings" header field.  The "HTTP2-Settings" header field is a hop-by-hop header field that includes settings that govern the HTTP/2.0 connection, provided in anticipation of the server accepting the request to upgrade.  A server MUST reject an attempt to upgrade if this header is not present. </del> <ins> A request that upgrades from HTTP/1.1 to HTTP/2.0 MUST include exactly one "HTTP2-Settings" header field.  The "HTTP2-Settings" header field is a hop-by-hop header field that includes settings that govern the HTTP/2.0 connection, provided in anticipation of the server accepting the request to upgrade.  A server MUST reject an attempt to upgrade if this header is not present. </ins> The content of the "HTTP2-Settings" header field is the payload of a
represented either literally or as a reference to an entry of the header table.  The header value is represented literally. <del> Three different literal representations are provided: </del> <ins> Two different literal representations are provided: </ins> A literal representation that does not add the header to the header table (see literal.header.without.indexing). <del> A literal representation that adds the header at the end of the header table (see literal.header.with.incremental.indexing). A literal representation that uses the header to replace an existing entry of the header table (see literal.header.with.substitution.indexing). </del> <ins> A literal representation that adds the header at the beginning of the header table (see literal.header.with.incremental.indexing). </ins> The indexed representation defines a header as a reference in the header table (see indexed.header.representation).
or by replacing an existing one.  Before doing such a modification, it has to be ensured that the header table size will stay lower than or equal to the SETTINGS_HEADER_TABLE_SIZE limit (see <del> parameter.negotiation).  To achieve this, repeatedly, the first entry </del> <ins> parameter.negotiation).  To achieve this, repeatedly, the last entry </ins> of the header table is removed, until enough space is available for the modification.
header table is that the remaining entries are renumbered.  The first entry of the header table is always associated to the index 0. <del> When the modification of the header table is the replacement of an existing entry, the replaced entry is the one indicated in the literal representation before any entry is removed from the header table.  If the entry to be replaced is removed from the header table when performing the size adjustment, the replacement entry is inserted at the beginning of the header table. </del> The addition of a new entry with a size greater than the SETTINGS_HEADER_TABLE_SIZE limit causes all the entries from the header table to be dropped and the new entry not to be added to the <del> header table.  The replacement of an existing entry with a new entry with a size greater than the SETTINGS_HEADER_TABLE_SIZE has the same consequences. </del> <ins> header table. </ins> 4.
A literal header without indexing causes the emission of a header without altering the header table. <del> This representation starts with the '011' 3-bit pattern. </del> <ins> This representation starts with the '01' 2-bit pattern. </ins> If the header name matches the header name of a (name, value) pair stored in the Header Table, the index of the pair increased by one <del> (index + 1) is represented as an integer with a 5-bit prefix.  Note that if the index is strictly below 31, one byte is used. </del> <ins> (index + 1) is represented as an integer with a 6-bit prefix.  Note that if the index is strictly below 63, one byte is used. </ins> If the header name does not match a header name entry, the value 0 is <del> represented on 5 bits followed by the header name </del> <ins> represented on 6 bits followed by the header name </ins> (header.name.representation). Header name representation is followed by the header value
A literal header with incremental indexing adds a new entry to the header table. <del> This representation starts with the '010' 3-bit pattern. If the header name matches the header name of a (name, value) pair stored in the Header Table, the index of the pair increased by one (index + 1) is represented as an integer with a 5-bit prefix.  Note that if the index is strictly below 31, one byte is used. If the header name does not match a header name entry, the value 0 is represented on 5 bits followed by the header name (header.name.representation). Header name representation is followed by the header value represented as a literal string as described in string.literal.representation. 4.3.3. A literal header with substitution indexing replaces an existing header table entry. </del> This representation starts with the '00' 2-bit pattern. If the header name matches the header name of a (name, value) pair
represented on 6 bits followed by the header name (header.name.representation). <del> The index of the substituted (name, value) pair is inserted after the header name representation as a 0-bit prefix integer. The index of the substituted pair MUST correspond to a position in the header table containing a non-void entry.  An index for the substituted pair that corresponds to empty position in the header table MUST be treated as an error. This index is followed by the header value represented as a literal string as described in string.literal.representation. </del> <ins> Header name representation is followed by the header value represented as a literal string as described in string.literal.representation. </ins> 5.
The algorithm to represent an integer I is as follows: <ins> This integer representation allows for values of indefinite size.  It is also possible for an encoder to send a large number of zero values, which can waste bytes and could be used to overflow integer values.  Excessively large integer encodings - in value or octet length - MUST be treated as a decoding error.  Different limits can be set for each of the different uses of integers, based on implementation constraints. </ins> 4.1.1.1. The value 10 is to be encoded with a 5-bit prefix.
string comparisons is always a function of the total length of the strings, and not a function of the number of matched characters. <ins> A decoder needs to ensure that larger values or encodings of integers do not permit exploitation.  Decoders MUST limit the size of integers, both in value and encoded length, that it accepts (see integer.representation). </ins> Another common security problem is when the remote endpoint successfully causes the local endpoint to exhaust its memory.  This compressor attempts to deal with the most obvious ways that this
triggered the push, plus resource identification information provided by the server.  Request header fields are necessary for HTTP cache control validations (such as the Vary header field) to work.  For <del> this reason, caches MUST inherit request header fields from the associated stream for the push.  This includes the Cookie header field. </del> <ins> this reason, caches MUST associate the request header fields from the PUSH_PROMISE frame with the response headers and content delivered on the pushed stream.  This includes the Cookie header field. </ins> Caching resources that are pushed is possible, based on the guidance provided by the origin server in the Cache-Control header field.
frame from this client to the remote and receive a response. The value is represented in milliseconds. <del> 4 - SETTINGS_MAX_CONCURRENT_STREAMS allows the sender to inform the remote endpoint the maximum number of concurrent streams which it will allow.  By default there is no limit.  For </del> <ins> 4 - SETTINGS_MAX_CONCURRENT_STREAMS indicates the maximum number of concurrent streams which the sender of the SETTINGS frame is willing to allow the peer to open.  Note that this limit is directional.  By default there is no limit.  For </ins> implementors it is recommended that this value be no smaller <del> than 100. </del> <ins> than 100, so as not to unnecessarily limit parallelism. </ins> 5 - SETTINGS_CURRENT_CWND allows the sender to inform the remote endpoint of the current TCP CWND value.
3.1. The protocol defined in this document is identified using the string <del> "HTTP/2.0".  This identification is used in the HTTP/1.1 Upgrade header field, in the TLSALPN field, and other places where protocol </del> <ins> "h2".  This identification is used in the HTTP/1.1 Upgrade header field, in the TLSALPN field, and other places where protocol </ins> identification is required. <del> Negotiating "HTTP/2.0" implies the use of the transport, security, framing and message semantics described in this document. </del> <ins> Negotiating "h2" implies the use of the transport, security, framing and message semantics described in this document. </ins> Only implementations of the final, published RFC can identify <del> themselves as "HTTP/2.0".  Until such an RFC exists, implementations MUST NOT identify themselves using "HTTP/2.0". </del> <ins> themselves as "h2".  Until such an RFC exists, implementations MUST NOT identify themselves using "h2". </ins> <del> Examples and text throughout the rest of this document use "HTTP/2.0" as a matter of editorial convenience only.  Implementations of draft versions MUST NOT identify using this string.  The exception to this rule is the string included in the connection header sent by clients immediately after establishing an HTTP/2.0 connection (see ConnectionHeader); this fixed length sequence of octets does not change. </del> <ins> Examples and text throughout the rest of this document use "h2" as a matter of editorial convenience only.  Implementations of draft versions MUST NOT identify using this string. </ins> Implementations of draft versions of the protocol MUST add the string <del> "-draft-" and the corresponding draft number to the identifier before the separator ('/').  For example, draft-ietf-httpbis-http2-03 is identified using the string "HTTP-draft-03/2.0". </del> <ins> "-" and the corresponding draft number to the identifier.  For example, draft-ietf-httpbis-http2-09 is identified using the string "h2-09". </ins> Non-compatible experiments that are based on these draft versions <del> MUST instead replace the string "draft" with a different identifier. </del> <ins> MUST append the string "-" and a experiment name to the identifier. </ins> For example, an experimental implementation of packet mood-based <del> encoding based on draft-ietf-httpbis-http2-07 might identify itself as "HTTP-emo-07/2.0".  Note that any label MUST conform to the "token" syntax defined in HTTP-p1.  Experimenters are encouraged to </del> <ins> encoding based on draft-ietf-httpbis-http2-09 might identify itself as "h2-09-emo".  Note that any label MUST conform to the "token" syntax defined in HTTP-p1.  Experimenters are encouraged to </ins> coordinate their experiments on the ietf-http-wg@w3.org mailing list. 3.2.
A client that makes a request to an "http" URI without prior knowledge about support for HTTP/2.0 uses the HTTP Upgrade mechanism (HTTP-p1).  The client makes an HTTP/1.1 request that includes an <del> Upgrade header field identifying HTTP/2.0.  The HTTP/1.1 request MUST include exactly one Http2SettingsHeader header field. </del> <ins> Upgrade header field identifying HTTP/2.0 with the h2 token.  The HTTP/1.1 request MUST include exactly one Http2SettingsHeader header field. </ins> Requests that contain an entity body MUST be sent in their entirety before the client can send HTTP/2.0 frames.  This means that a large
A client can learn that a particular server supports HTTP/2.0 by other means.  A client MAY immediately send HTTP/2.0 frames to a server that is known to support HTTP/2.0, after the ConnectionHeader. <del> This only affects the resolution of "http" URIs; servers supporting HTTP/2.0 are required to support TLSALPN for "https" URIs. </del> <ins> A server can identify such a connection by the use of the "PRI" method in the connection header.  This only affects the resolution of "http" URIs; servers supporting HTTP/2.0 are required to support TLSALPN for "https" URIs. </ins> Prior support for HTTP/2.0 is not a strong signal that a given server will support HTTP/2.0 for future connections.  It is possible for
This header field is only used by an HTTP/2.0 client for Upgrade- based negotiation. <ins> 12.6. This section registers the "PRI" method in the HTTP-p2. PRI No No ConnectionHeader of this document This method is never used by an actual client.  This method will appear to be used when an HTTP/1.1 server or intermediary attempts to parse an HTTP/2.0 connection known-http. </ins>
The HTTP pseudo-method CONNECT (HTTP-p2) is used to convert an HTTP/1.1 connection into a tunnel to a remote host.  CONNECT is <del> primarily used with HTTP proxies to established a TLS session with a </del> <ins> primarily used with HTTP proxies to establish a TLS session with a </ins> server for the purposes of interacting with "https" resources. In HTTP/2.0, the CONNECT method is used to establish a tunnel over a
state (see HeaderBlock); similarly DATA frames MUST be counted toward the connection flow control window. <del> The GTFO frame does not define any flags. </del> <ins> The GOAWAY frame does not define any flags. </ins> <del> The GTFO frame applies to the connection, not a specific stream.  An endpoint MUST treat a </del> <ins> The GOAWAY frame applies to the connection, not a specific stream. An endpoint MUST treat a </ins> frame with a stream identifier other than 0x0 as a ConnectionErrorHandler of type . <del> The last stream identifier ("Last-Stream-ID") in the GTFO frame contains the highest numbered stream identifier for which the sender of the GTFO frame has received frames on and might have taken some action on.  All streams up to and including the identified stream might have been processed in some way.  The last stream identifier is set to 0 if no streams were processed. </del> <ins> The last stream identifier in the GOAWAY frame contains the highest numbered stream identifier for which the sender of the GOAWAY frame has received frames on and might have taken some action on.  All streams up to and including the identified stream might have been processed in some way.  The last stream identifier is set to 0 if no streams were processed. </ins> Note: In this case, "processed" means that some data from the stream was passed to some higher layer of software that might have taken some action as a result. <del> If a connection terminates without a GTFO frame, this value is </del> <ins> If a connection terminates without a GOAWAY frame, this value is </ins> effectively the highest stream identifier. On streams with lower or equal numbered identifiers that were not
be safely retried using a new connection. Activity on streams numbered lower or equal to the last stream <del> identifier might still complete successfully.  The sender of a GTFO frame might gracefully shut down a connection by sending a GTFO </del> <ins> identifier might still complete successfully.  The sender of a GOAWAY frame might gracefully shut down a connection by sending a GOAWAY </ins> frame, maintaining the connection in an open state until all in- progress streams complete.
HeaderBlock.  Otherwise, flow control or header compression state can become unsynchronized. <del> The GTFO frame also contains a 32-bit ErrorCodes that contains the reason for ending communication. </del> <ins> The GOAWAY frame also contains a 32-bit ErrorCodes that contains the reason for closing the connection. </ins> <del> Endpoints MAY append opaque data to the payload of any GTFO frame. </del> <ins> Endpoints MAY append opaque data to the payload of any GOAWAY frame. </ins> Additional debug data is intended for diagnostic purposes only and carries no semantic value.  Debug information could contain security- or privacy-sensitive data.  Logged or otherwise persistently stored