jiebi/CodeConvo huggingface dataset:
StreamPriority ensures that limited resources can be directed to the most important streams first. <del> HTTP/2 adds a new interaction mode whereby a server can PushResources.  Server push allows a server to speculatively send data to a client that the server anticipates the client will need, trading off some network usage against a potential latency gain.  The server does this by synthesizing a request, which it sends as a PUSH_PROMISE frame.  The server is then able to send a response to the synthetic request on a separate stream. </del> Because HTTP header fields used in a connection can contain large amounts of redundant data, frames that contain them are FieldBlock. This has especially advantageous impact upon request sizes in the common case, allowing many requests to be compressed into one packet. <ins> Finally, HTTP/2 adds a new, optional interaction mode whereby a server can PushResources.  This is intended to allow a server to speculatively send data to a client that the server anticipates the client will need, trading off some network usage against a potential latency gain.  The server does this by synthesizing a request, which it sends as a PUSH_PROMISE frame.  The server is then able to send a response to the synthetic request on a separate stream. </ins> 2.1. The HTTP/2 specification is split into four parts:
HTTP/2 allows a server to pre-emptively send (or "push") responses (along with corresponding "promised" requests) to a client in <del> association with a previous client-initiated request.  This can be useful when the server knows the client will need to have those responses available in order to fully process the response to the original request. </del> <ins> association with a previous client-initiated request. Server push was designed to allow a server to improve client- perceived performance by predicting what requests will follow those that it receives, thereby removing a round trip for them.  For example, a request for HTML is often followed by requests for stylesheets and scripts referenced by that page.  When these requests are pushed, the client does not need to wait to receive the references to them in the HTML and issue separate requests. In practice, server push is difficult to use effectively, because it requires the server to correctly anticipate the additional requests the client will make, taking into account factors such as caching, content negotiation, and user behavior.  Errors in prediction can lead to performance degradation, due to the opportunity cost that the additional data on the wire represents.  In particular, pushing any significant amount of data can cause contention issues with more- important responses. </ins> A client can request that server push be disabled, though this is negotiated for each hop independently.  The SETTINGS_ENABLE_PUSH
header field.  The header field is a connection-specific header field that includes <del> parameters that govern the HTTP/2 connection, provided in anticipation of the server accepting the request to upgrade. </del> <ins> settings that govern the HTTP/2 connection, provided in anticipation of the server accepting the request to upgrade. </ins> A server MUST NOT upgrade the connection to HTTP/2 if this header field is not present or if more than one is present.  A server MUST
additional frames to the server immediately after sending the client connection preface, without waiting to receive the server connection preface.  It is important to note, however, that the server <del> connection preface SETTINGS frame might include parameters that </del> <ins> connection preface SETTINGS frame might include settings that </ins> necessarily alter how a client is expected to communicate with the server.  Upon receiving the SETTINGS frame, the client is expected to <del> honor any parameters established.  In some configurations, it is </del> <ins> honor any settings established.  In some configurations, it is </ins> possible for the server to transmit SETTINGS before the client sends additional frames, providing an opportunity to avoid this issue.
The SETTINGS frame (type=0x4) conveys configuration parameters that affect how endpoints communicate, such as preferences and constraints on peer behavior.  The SETTINGS frame is also used to acknowledge the <del> receipt of those parameters.  Individually, a SETTINGS parameter can also be referred to as a "setting". </del> <ins> receipt of those settings.  Individually, a configuration parameter from a SETTINGS frame is referred to as a "setting". </ins> <del> SETTINGS parameters are not negotiated; they describe characteristics of the sending peer, which are used by the receiving peer.  Different values for the same parameter can be advertised by each peer.  For example, a client might set a high initial flow-control window, whereas a server might set a lower value to conserve resources. </del> <ins> Settings are not negotiated; they describe characteristics of the sending peer, which are used by the receiving peer.  Different values for the same setting can be advertised by each peer.  For example, a client might set a high initial flow-control window, whereas a server might set a lower value to conserve resources. </ins> A SETTINGS frame MUST be sent by both endpoints at the start of a connection and MAY be sent at any other time by either endpoint over the lifetime of the connection.  Implementations MUST support all of <del> the parameters defined by this specification. </del> <ins> the settings defined by this specification. </ins> Each parameter in a SETTINGS frame replaces any existing value for <del> that parameter.  Parameters are processed in the order in which they </del> <ins> that parameter.  Settings are processed in the order in which they </ins> appear, and a receiver of a SETTINGS frame does not need to maintain <del> any state other than the current value of its parameters.  Therefore, </del> <ins> any state other than the current value of each setting.  Therefore, </ins> the value of a SETTINGS parameter is the last value that is seen by a receiver. <del> SETTINGS parameters are acknowledged by the receiving peer.  To enable this, the SETTINGS frame defines the following flag: </del> <ins> SETTINGS frames are acknowledged by the receiving peer.  To enable this, the SETTINGS frame defines the ACK flag: </ins> SETTINGS frames always apply to a connection, never a single stream. The stream identifier for a SETTINGS frame MUST be zero (0x0).  If an
6.5.1. The frame payload of a SETTINGS frame consists of zero or more <del> parameters, each consisting of an unsigned 16-bit setting identifier </del> <ins> settings, each consisting of an unsigned 16-bit setting identifier </ins> and an unsigned 32-bit value. 6.5.2. <del> The following parameters are defined: </del> <ins> The following settings are defined: </ins> An endpoint that receives a SETTINGS frame with any unknown or unsupported identifier MUST ignore that setting.
when the peer has received and applied the changed parameter values. In order to provide such synchronization timepoints, the recipient of a SETTINGS frame in which the ACK flag is not set MUST apply the <del> updated parameters as soon as possible upon receipt. </del> <ins> updated settings as soon as possible upon receipt. </ins> The values in the SETTINGS frame MUST be processed in the order they appear, with no other frame processing between values.  Unsupported <del> parameters MUST be ignored.  Once all values have been processed, the </del> <ins> settings MUST be ignored.  Once all values have been processed, the </ins> recipient MUST immediately emit a SETTINGS frame with the ACK flag set.  Upon receiving a SETTINGS frame with the ACK flag set, the <del> sender of the altered parameters can rely on the setting having been </del> <ins> sender of the altered settings can rely on the value having been </ins> applied. If the sender of a SETTINGS frame does not receive an acknowledgement
8.1.2.1. <del> While HTTP/1.x used the message start-line (see HTTP11) to convey control data, HTTP/2 uses special pseudo-header fields beginning with ':' character (ASCII 0x3a) for this purpose. Pseudo-header fields are not HTTP header fields.  Pseudo-header fields contain control data (see HTTP).  Endpoints MUST NOT generate pseudo-header fields other than those defined in this document.  Note that an extension could negotiate the use of additional pseudo-header fields; see extensibility. </del> <ins> HTTP/2 uses special pseudo-header fields beginning with ':' character (ASCII 0x3a) to convey message control data (see HTTP). Pseudo-header fields are not HTTP header fields.  Endpoints MUST NOT generate pseudo-header fields other than those defined in this document.  Note that an extension could negotiate the use of additional pseudo-header fields; see extensibility. </ins> Pseudo-header fields are only valid in the context in which they are defined.  Pseudo-header fields defined for requests MUST NOT appear
"Hypertext Transfer Protocol (HTTP) Field Name Registry" registry maintained at <https://www.iana.org/assignments/http-fields/>. <del> Just as in HTTP/1.x, field names are strings of ASCII characters that are compared in a case-insensitive fashion.  Field names MUST be converted to lowercase prior to their encoding in HTTP/2.  A request or response containing uppercase header field names MUST be treated as malformed. </del> <ins> Field names are strings of ASCII characters that are compared in a case-insensitive fashion.  Field names MUST be converted to lowercase when constructing a HTTP/2 message.  A request or response containing an uppercase character ('A' to 'Z', ASCII 0x41 to 0x5a) in a field name MUST be treated as malformed. HPACK is capable of carrying field names or values that are not valid in HTTP.  Though HPACK can carry any octet, fields are not valid in the following cases: A request or response that contains a field that violates any of these conditions MUST be treated as malformed.  In particular, an intermediary that does not process fields when forwarding messages MUST NOT forward fields that contain any of the values that are listed as prohibited above. Field values that are not valid according to the definition of the corresponding field do not cause a request to be malformed except as defined by the processing rules for the field. </ins> 8.1.2.1.
10.3. <del> The HTTP/2 field block encoding allows the expression of names that are not valid field names in HTTP.  Requests or responses containing invalid field names MUST be treated as malformed.  An intermediary therefore cannot translate an HTTP/2 request or response containing an invalid field name into an HTTP/1.1 message. Similarly, HTTP/2 allows field values that are not valid.  While most of the values that can be encoded will not alter header field parsing, carriage return (CR, ASCII 0xd), line feed (LF, ASCII 0xa), and the zero character (NUL, ASCII 0x0) might be exploited by an attacker if they are translated verbatim.  Any request or response that contains a character not permitted in a field value MUST be treated as malformed.  Valid characters are defined by the ABNF rule in HTTP. </del> <ins> HPACK permits encoding of field names and values that might be treated as delimiters in other HTTP versions.  An intermediary that translates an HTTP/2 request or response MUST validate fields according to the rules in HttpHeaders roles before translating a message to another HTTP version.  Translating a field that includes invalid delimiters could be used to cause recipients to incorrectly interpret a message, which could be exploited by an attacker. 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 any validation of fields other than the minimum required by HttpHeaders could forward messages that contain invalid field names or values. </ins> 10.4.
For malformed requests, a server MAY send an HTTP response prior to closing or resetting the stream.  Clients MUST NOT accept a malformed <del> response.  Note that these requirements are intended to protect against several types of common attacks against HTTP; they are deliberately strict because being permissive can expose implementations to these vulnerabilities. </del> <ins> response. Endpoints that progressively process messages might have performed some processing before identifying a request or response as malformed.  For instance, it might be possible to generate an informational or 404 status code without having received a complete request.  Similarly, intermediaries might forward incomplete messages before detecting errors.  A server MAY generate a final response before receiving an entire request when the response does not depend on the remainder of the request being correct.  A server or intermediary MAY use RST_STREAM -- with a code other than REFUSED_STREAM -- to abort a stream if a malformed request or response is received. These requirements are intended to protect against several types of common attacks against HTTP; they are deliberately strict because being permissive can expose implementations to these vulnerabilities. </ins> 8.1.3.
This document establishes a registry for HTTP/2 frame type codes. The "HTTP/2 Frame Type" registry manages an 8-bit space.  The "HTTP/2 <del> Frame Type" registry operates under either of the RFC5226 for values between 0x00 and 0xef, with values between 0xf0 and 0xff being reserved for Experimental Use. </del> <ins> Frame Type" registry operates under either of the RFC8126 or RFC8126 policies. </ins> New entries in this registry require the following information:
This document establishes a registry for HTTP/2 settings.  The "HTTP/2 Settings" registry manages a 16-bit space.  The "HTTP/2 <del> Settings" registry operates under the RFC5226 for values in the range from 0x0000 to 0xefff, with values between and 0xf000 and 0xffff being reserved for Experimental Use. </del> <ins> Settings" registry operates under the RFC8126. </ins> New registrations are advised to provide the following information:
If an endpoint detects multiple different errors, it MAY choose to report any one of those errors.  If a frame causes a connection <del> error, that error MUST be reported. </del> <ins> error, that error MUST be reported.  Additionally, an endpoint MAY use any applicable error code when it detects an error condition; a generic error code (such as PROTOCOL_ERROR or INTERNAL_ERROR) can always be used in place of more specific error codes. </ins> 5.4.1.
they can be used by an endpoint to measure latency to their peer. This might have privacy implications in certain scenarios. <ins> 10.9. Remote timing attacks extract secrets from servers by observing variations in the time that servers take when processing requests that use secrets.  HTTP/2 enables concurrent request creation and processing, which can give attackers better control over when request processing commences.  Multiple HTTP/2 requests can be included in the same IP packet or TLS record.  HTTP/2 can therefore make remote timing attacks more efficient by eliminating variability in request delivery, leaving only request order and the delivery of responses as sources of timing variability. Ensuring that processing time is not dependent on the value of secrets is the best defense against any form of timing attack. </ins> 11. A string for identifying HTTP/2 is entered into the "Application-
ABNF rule in HTTP. <ins> 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 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. </ins> 10.4. Pushed responses do not have an explicit request from the client; the
timely fashion.  Failure to do so could lead to a deadlock when critical frames, such as WINDOW_UPDATE, are not read and acted upon. <ins> 5.2.3. If an endpoint cannot ensure that its peer always has available flow control window space that is greater than the peer's bandwidth-delay product on this connection, its receive throughput will be limited by HTTP/2 flow control.  This will result in degraded performance. Sending timely WINDOW_UPDATE frames can improve performance. Endpoints will want to balance the need to improve receive throughput with the need to manage resource exhaustion risks, and should take careful note of dos in defining their strategy to manage window sizes. </ins> 5.3. In a multiplexed protocol like HTTP/2, prioritizing allocation of
HEADERS frames can be sent on a stream in the "idle", "reserved (local)", "open", or "half-closed (remote)" state. <del> The HEADERS frame payload has the following fields: </del> <ins> The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are described in FramingLayer.  The HEADERS frame payload has the following additional fields: </ins> The HEADERS frame defines the following flags:
stream.  RST_STREAM is sent to request cancellation of a stream or to indicate that an error condition has occurred. <del> The RST_STREAM frame contains a single unsigned, 32-bit integer identifying the ErrorCodes.  The error code indicates why the stream is being terminated. </del> <ins> The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are described in FramingLayer.  Additionally, the RST_STREAM frame contains a single unsigned, 32-bit integer identifying the ErrorCodes.  The error code indicates why the stream is being terminated. </ins> The RST_STREAM frame does not define any flags.
provides additional context for the stream.  PushResources contains a thorough description of the use of PUSH_PROMISE frames. <del> The PUSH_PROMISE frame payload has the following fields: </del> <ins> The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are described in FramingLayer.  The PUSH_PROMISE frame payload has the following additional fields: </ins> The PUSH_PROMISE frame defines the following flags:
respond with a StreamErrorHandler or ConnectionErrorHandler of type FLOW_CONTROL_ERROR if it is unable to accept a frame. <del> The frame payload of a WINDOW_UPDATE frame is one reserved bit plus an unsigned 31-bit integer indicating the number of octets that the sender can transmit in addition to the existing flow-control window. The legal range for the increment to the flow-control window is 1 to 2 </del> <ins> The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are described in FramingLayer.  The frame payload of a WINDOW_UPDATE frame is one reserved bit plus an unsigned 31-bit integer indicating the number of octets that the sender can transmit in addition to the existing flow-control window.  The legal range for the increment to the flow-control window is 1 to 2 </ins> -1 (2,147,483,647) octets.
as the preceding frame is on the same stream and is a HEADERS, PUSH_PROMISE, or CONTINUATION frame without the END_HEADERS flag set. <del> The CONTINUATION frame payload contains a FieldBlock. </del> <ins> The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are described in FramingLayer.  The CONTINUATION frame payload contains a FieldBlock. </ins> The CONTINUATION frame defines the following flag:
Field names are strings of ASCII characters that are compared in a case-insensitive fashion.  Field names MUST be converted to lowercase <del> when constructing a HTTP/2 message.  A request or response containing an uppercase character ('A' to 'Z', ASCII 0x41 to 0x5a) in a field name MUST be treated as malformed. </del> <ins> when constructing a HTTP/2 message. </ins> HPACK is capable of carrying field names or values that are not valid in HTTP.  Though HPACK can carry any octet, fields are not valid in
MUST NOT forward fields that contain any of the values that are listed as prohibited above. <del> Field values that are not valid according to the definition of the corresponding field do not cause a request to be malformed except as defined by the processing rules for the field. </del> <ins> A recipient MAY treat a message that contains a field name or value that includes other characters disallowed by HTTP and HTTP as malformed. When a request message violates one of the requirements above, it SHOULD be responded to using the 400 (Bad Request) status code HTTP before the stream is reset, unless a more suitable status code is defined, or the status code cannot be sent (e.g., because the error occurs in a trailer field). Note that field values that are not valid according to the definition of the corresponding field do not cause a request to be malformed; the requirements above only apply to the generic syntax for field values as defined in HTTP. </ins> 8.1.2.1.
A malformed request or response is one that is an otherwise valid sequence of HTTP/2 frames but is invalid due to the presence of extraneous frames, prohibited fields or pseudo-header fields, the <del> absence of mandatory fields or pseudo-header fields, or the inclusion of uppercase field names. </del> <ins> absence of mandatory fields or pseudo-header fields, the inclusion of uppercase field names, or invalid field names and/or values (in certain circumstances; see HttpHeaders). </ins> A request or response that includes message content can include a
the requirements above only apply to the generic syntax for field values as defined in HTTP. <del> 8.1.2.1. HTTP/2 uses special pseudo-header fields beginning with ':' character (ASCII 0x3a) to convey message control data (see HTTP). Pseudo-header fields are not HTTP header fields.  Endpoints MUST NOT generate pseudo-header fields other than those defined in this document.  Note that an extension could negotiate the use of additional pseudo-header fields; see extensibility. Pseudo-header fields are only valid in the context in which they are defined.  Pseudo-header fields defined for requests MUST NOT appear in responses; pseudo-header fields defined for responses MUST NOT appear in requests.  Pseudo-header fields MUST NOT appear in a trailer section.  Endpoints MUST treat a request or response that contains undefined or invalid pseudo-header fields as malformed. All pseudo-header fields MUST appear in a field block before all regular field lines.  Any request or response that contains a pseudo- header field that appears in a field block after a regular field line MUST be treated as malformed. 8.1.2.2. </del> <ins> 8.2.2. </ins> HTTP/2 does not use the <del> header field to indicate connection-specific header fields; in this protocol, connection-specific metadata is conveyed by other means. An endpoint MUST NOT generate an HTTP/2 message containing </del> <ins> header field (HTTP) to indicate connection-specific header fields; in this protocol, connection-specific metadata is conveyed by other means.  An endpoint MUST NOT generate an HTTP/2 message containing </ins> connection-specific header fields; any message containing connection- specific header fields MUST be treated as malformed.
connection-specific header fields as discussed in HTTP, or their messages will be treated by other HTTP/2 endpoints as malformed. <del> 8.1.2.3. The following pseudo-header fields are defined for HTTP/2 requests: All HTTP/2 requests MUST include exactly one valid value for the , , and pseudo-header fields, unless it is a CONNECT.  An HTTP request that omits mandatory pseudo-header fields is malformed. Individual HTTP/2 requests do not carry an explicit indicator of protocol version.  All HTTP/2 messages implicitly have a protocol version of "2.0" (see HTTP). 8.1.2.4. For HTTP/2 responses, a single pseudo-header field is defined that carries the HTTP status code field (see HTTP).  This pseudo-header field MUST be included in all responses, including interim responses; otherwise, the response is malformed. HTTP/2 responses implicitly have a protocol version of "2.0". 8.1.2.5. </del> <ins> 8.2.3. </ins> The COOKIE uses a semi-colon (";") to delimit cookie-pairs (or "crumbs").  This header field contains multiple values, but does not