jiebi/CodeConvo huggingface dataset:
and ends with a frame bearing END_STREAM, which places the stream in the "closed" state. <del> 8.3. </del> <ins> 8.5. </ins> <del> In HTTP/1.x, the pseudo-method CONNECT (HTTP) is used to convert an HTTP connection into a tunnel to a remote host.  CONNECT is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with </del> <ins> The CONNECT method (HTTP) is used to convert an HTTP connection into a tunnel to a remote host.  CONNECT is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with </ins> resources. <del> In HTTP/2, the CONNECT method is used to establish a tunnel over a single HTTP/2 stream to a remote host for similar purposes.  A CONNECT header section is constructed as defined in HttpRequest ("HttpRequest"), with a few differences.  Specifically: </del> <ins> In HTTP/2, the CONNECT method establishes a tunnel over a single HTTP/2 stream to a remote host, rather than converting the entire connection to a tunnel.  A CONNECT header section is constructed as defined in HttpRequest ("HttpRequest"), with a few differences. Specifically: </ins> A CONNECT request that does not conform to these restrictions is malformed.
Implementations MUST support ephemeral key exchange sizes of at least 2048 bits for cipher suites that use ephemeral finite field Diffie- Hellman (DHE) TLS13 and 224 bits for cipher suites that use ephemeral <del> elliptic curve Diffie-Hellman (ECDHE) RFC4492.  Clients MUST accept </del> <ins> elliptic curve Diffie-Hellman (ECDHE) RFC8422.  Clients MUST accept </ins> DHE sizes of up to 4096 bits.  Endpoints MAY treat negotiation of key sizes smaller than the lower limits as a ConnectionErrorHandler of type INADEQUATE_SECURITY.
largely independent of each other, so a blocked or stalled request or response does not prevent progress on other streams. <del> Flow control and prioritization ensure that it is possible to efficiently use multiplexed streams.  FlowControl helps to ensure that only data that can be used by a receiver is transmitted. StreamPriority ensures that limited resources can be directed to the most important streams first. </del> <ins> Effective use of multiplexing depends on flow control and prioritization.  FlowControl ensures that it is possible to efficiently use multiplexed streams by restricting data that is transmitted to what the receiver is able to handle.  StreamPriority ensures that limited resources are used most effectively.  This revision of HTTP/2 deprecates the priority signaling scheme from RFC7540. </ins> Because HTTP fields used in a connection can contain large amounts of redundant data, frames that contain them are FieldBlock.  This has
3.1. <del> The protocol defined in this document has two identifiers. Negotiating "h2" or "h2c" implies the use of the transport, security, framing, and message semantics described in this document. </del> <ins> The protocol defined in this document has two identifiers.  Creating a connection based on either implies the use of the transport, security, framing, and message semantics described in this document. </ins> 3.2.
The HEADERS frame changes the connection state as described in FieldBlock. <del> The HEADERS frame can include padding.  Padding fields and flags are identical to those defined for DATA.  Padding that exceeds the size remaining for the field block fragment MUST be treated as a PROTOCOL_ERROR. </del> <ins> The total number of padding octets is determined by the value of the Pad Length field.  Padding that exceeds the size remaining for the field block fragment MUST be treated as a PROTOCOL_ERROR. </ins> 6.3.
Note that an illegal stream identifier is an identifier for a stream that is not currently in the "idle" state. <del> The PUSH_PROMISE frame can include padding.  Padding fields and flags are identical to those defined for DATA. </del> <ins> The total number of padding octets is determined by the value of the Pad Length field.  Padding that exceeds the size remaining for the field block fragment MUST be treated as a PROTOCOL_ERROR. </ins> 6.7.
1. <del> The Hypertext Transfer Protocol (HTTP) is a wildly successful protocol.  However, the way HTTP/1.1 uses the underlying transport (HTTP11) has several characteristics that have a negative overall effect on application performance today. In particular, HTTP/1.0 allowed only one request to be outstanding at a time on a given TCP connection.  HTTP/1.1 added request pipelining, but this only partially addressed request concurrency and still suffers from head-of-line blocking.  Therefore, HTTP/1.0 and HTTP/1.1 clients that need to make many requests use multiple connections to a server in order to achieve concurrency and thereby reduce latency. </del> <ins> The performance of applications using the Hypertext Transfer Protocol (HTTP) is linked to how each version of HTTP uses the underlying transport, and the conditions under which the transport operates. Making multiple concurrent requests can reduce latency and improve application performance.  HTTP/1.0 allowed only one request to be outstanding at a time on a given TCP connection.  HTTP/1.1 (HTTP11) added request pipelining, but this only partially addressed request concurrency and still suffers from application-layer head-of-line blocking.  Therefore, HTTP/1.0 and HTTP/1.1 clients use multiple connections to a server to make concurrent requests. </ins> Furthermore, HTTP fields are often repetitive and verbose, causing unnecessary network traffic as well as causing the initial TCP TCP
does not affect the existing options for extending HTTP, such as defining new methods, status codes, or fields (see HTTP). <del> Extensions are permitted to use new FrameHeader, new SettingValues, or new ErrorCodes.  Registries are established for managing these extension points: iana-frames, iana-settings, and iana-errors. </del> <ins> Extensions are permitted to use new FrameHeader, new SETTINGS, or new ErrorCodes.  Registries are established for managing these extension points: iana-frames, iana-settings, and iana-errors. </ins> Implementations MUST ignore unknown or unsupported values in all extensible protocol elements.  Implementations MUST discard frames
Streams have the following states: <del> In the absence of more specific guidance elsewhere in this document, implementations SHOULD treat the receipt of a frame that is not expressly permitted in the description of a state as a ConnectionErrorHandler of type PROTOCOL_ERROR.  Note that PRIORITY can be sent and received in any stream state.  Frames of unknown types are ignored. </del> <ins> In the absence of more specific rules, implementations SHOULD treat the receipt of a frame that is not expressly permitted in the description of a state as a ConnectionErrorHandler of type PROTOCOL_ERROR.  Note that PRIORITY can be sent and received in any stream state. The rules in this section only apply to frames defined in this document.  Receipt of frames for which the semantics are unknown cannot be treated as an error as the conditions for sending and receiving those frames are also unknown; see extensibility. </ins> An example of the state transitions for an HTTP request/response exchange can be found in HttpExamples.  An example of the state
PROTOCOL_ERROR; errors on the connection flow-control window MUST be treated as a ConnectionErrorHandler. <del> WINDOW_UPDATE can be sent by a peer that has sent a frame bearing the END_STREAM flag.  This means that a receiver could receive a </del> <ins> WINDOW_UPDATE can be sent by a peer that has sent a frame with the END_STREAM flag set.  This means that a receiver could receive a </ins> WINDOW_UPDATE frame on a "half-closed (remote)" or "closed" stream. A receiver MUST NOT treat this as an error (see StreamStates).
interim response consists of a HEADERS frames (which might be followed by zero or more CONTINUATION frames) containing the control data and header section of an interim (1xx) HTTP response (see HTTP). <del> A HEADERS frame with an END_STREAM flag that carries an informational status code is malformed. </del> <ins> A HEADERS frame with the END_STREAM flag set that carries an informational status code is malformed. </ins> The last frame in the sequence bears an END_STREAM flag, noting that <del> a HEADERS frame bearing the END_STREAM flag can be followed by </del> <ins> a HEADERS frame with the END_STREAM flag set can be followed by </ins> CONTINUATION frames that carry any remaining fragments of the field block.
An HTTP request/response exchange fully consumes a single stream.  A request starts with the HEADERS frame that puts the stream into an <del> "open" state.  The request ends with a frame bearing END_STREAM, which causes the stream to become "half-closed (local)" for the </del> <ins> "open" state.  The request ends with a frame with the END_STREAM flag set, which causes the stream to become "half-closed (local)" for the </ins> client and "half-closed (remote)" for the server.  A response stream starts with zero or more interim responses in HEADERS frames or a HEADERS frame containing a final status code.
that has not been sent and received.  When this is true, a server MAY request that the client abort transmission of a request without error by sending a RST_STREAM with an error code of NO_ERROR after sending <del> a complete response (i.e., a frame with the END_STREAM flag). </del> <ins> a complete response (i.e., a frame with the END_STREAM flag set). </ins> Clients MUST NOT discard responses as a result of receiving such a RST_STREAM, though clients can always discard responses at their discretion for other reasons.
The response for a PUSH_PROMISE stream begins with a HEADERS frame, which immediately puts the stream into the "half-closed (remote)" state for the server and "half-closed (local)" state for the client, <del> and ends with a frame bearing END_STREAM, which places the stream in the "closed" state. </del> <ins> and ends with a frame with the END_STREAM flag set, which places the stream in the "closed" state. </ins> 8.5.
The TCP connection can be closed by either peer.  The END_STREAM flag on a DATA frame is treated as being equivalent to the TCP FIN bit.  A client is expected to send a DATA frame with the END_STREAM flag set <del> after receiving a frame bearing the END_STREAM flag.  A proxy that </del> <ins> after receiving a frame with the END_STREAM flag set.  A proxy that </ins> receives a DATA frame with the END_STREAM flag set sends the attached data with the FIN bit set on the last TCP segment.  A proxy that receives a TCP segment with the FIN bit set sends a DATA frame with
FieldBlock. The total number of padding octets is determined by the value of the <del> Pad Length field.  Padding that exceeds the size remaining for the field block fragment MUST be treated as a PROTOCOL_ERROR. </del> <ins> Pad Length field.  If the length of the padding is the length of the frame payload or greater, the recipient MUST treat this as a ConnectionErrorHandler of type PROTOCOL_ERROR. </ins> 6.3.
that is not currently in the "idle" state. The total number of padding octets is determined by the value of the <del> Pad Length field.  Padding that exceeds the size remaining for the field block fragment MUST be treated as a PROTOCOL_ERROR. </del> <ins> Pad Length field.  If the length of the padding is the length of the frame payload or greater, the recipient MUST treat this as a ConnectionErrorHandler of type PROTOCOL_ERROR. </ins> 6.7.
3.3. A client can learn that a particular server supports HTTP/2 by other <del> means.  For example, ALT-SVC describes a mechanism for advertising this capability. A client MUST send the ConnectionHeader and then MAY immediately send HTTP/2 frames to such a server; servers can identify these connections by the presence of the connection preface.  This only affects the establishment of HTTP/2 connections over cleartext TCP; implementations that support HTTP/2 over TLS MUST use TLS-ALPN. </del> <ins> means.  For example, a client could be configured with knowledge that a server supports HTTP/2. A client that knows that a server supports HTTP/2 can establish a TCP connection and send the ConnectionHeader followed by HTTP/2 frames. Servers can identify these connections by the presence of the connection preface.  This only affects the establishment of HTTP/2 connections over cleartext TCP; implementations that support HTTP/2 over TLS MUST use TLS-ALPN. </ins> Likewise, the server MUST send a ConnectionHeader.
8.2.1. <del> 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: </del> <ins> The definitions of field names and values in HTTP prohibits some characters that HPACK might be able to convey.  HTTP/2 implementations SHOULD validate field names and values according to their definitions in Sections HTTP and HTTP respectively and treat messages that contain prohibited characters as malformed. Failure to validate fields can be exploited for request smuggling attacks.  In particular, unvalidated fields might enable attacks when messages are forwarded using HTTP11, where characters such as CR and COLON are used as delimiters.  Implementations that do not fully validate field names and values MUST perform the following minimal validation: </ins> A request or response that contains a field that violates any of these conditions MUST be treated as malformed.  In particular, an
MUST NOT forward fields that contain any of the values that are listed as prohibited above. <del> 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. </del> <ins> When a request message violates one of these requirements, an implementation SHOULD generate a HTTP, 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). </ins> 8.2.2.
connection and send the ConnectionHeader followed by HTTP/2 frames. Servers can identify these connections by the presence of the connection preface.  This only affects the establishment of HTTP/2 <del> connections over cleartext TCP; implementations that support HTTP/2 over TLS MUST use TLS-ALPN. </del> <ins> connections over cleartext TCP; HTTP/2 connections over TLS MUST use TLS-ALPN. </ins> Likewise, the server MUST send a ConnectionHeader.
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 <del> connection-specific header fields; any message containing connection- specific header fields MUST be treated as malformed. </del> <ins> connection-specific header fields.  This includes the header field and those listed as having connection-specific semantics in HTTP (that is, , , , and ).  Any message containing connection-specific header fields MUST be treated as malformed. </ins> The only exception to this is the TE header field, which MAY be present in an HTTP/2 request; when it is, it MUST NOT contain any
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 RFC8126 or RFC8126 policies. </del> <ins> Frame Type" registry operates under either of the "IETF Review" (RFC8126) or "IESG Approval" (RFC8126) policies. </ins> New entries in this registry require the following information:
This document establishes a registry for HTTP/2 error codes.  The "HTTP/2 Error Code" registry manages a 32-bit space.  The "HTTP/2 <del> Error Code" registry operates under the RFC8126. </del> <ins> Error Code" registry operates under the "Expert Review" policy (RFC8126). </ins> Registrations for error codes are required to include a description of the error code.  An expert reviewer is advised to examine new
PUSH_PROMISE frames. The body of a PUSH_PROMISE includes a "Promised-Stream-ID".  This <del> unsigned 31-bit integer indentifies the stream the endpoint intends to start sending frames for.  The promised stream identifier MUST be a valid choice for the next stream sent by the sender (see </del> <ins> unsigned 31-bit integer identifies the stream the endpoint intends to start sending frames for.  The promised stream identifier MUST be a valid choice for the next stream sent by the sender (see </ins> StreamCreation). PUSH_PROMISE frames MUST be associated with an existing stream.  If
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, the inclusion of uppercase field names, or invalid field names and/or values (in certain circumstances; see HttpHeaders). </del> <ins> absence of mandatory 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
a server supports HTTP/2. A client that knows that a server supports HTTP/2 can establish a TCP <del> connection and send the ConnectionHeader followed by HTTP/2 frames. Servers can identify these connections by the presence of the connection preface.  This only affects the establishment of HTTP/2 connections over cleartext TCP; HTTP/2 connections over TLS MUST use TLS-ALPN. </del> <ins> connection and send the preface followed by HTTP/2 frames.  Servers can identify these connections by the presence of the connection preface.  This only affects the establishment of HTTP/2 connections over cleartext TCP; HTTP/2 connections over TLS MUST use TLS-ALPN. </ins> <del> Likewise, the server MUST send a ConnectionHeader. </del> <ins> Likewise, the server MUST send a preface. </ins> Without additional information, prior support for HTTP/2 is not a strong signal that a given server will support HTTP/2 for future
defining new methods, status codes, or fields (see HTTP). Extensions are permitted to use new FrameHeader, new SETTINGS, or new <del> ErrorCodes.  Registries are established for managing these extension points: iana-frames, iana-settings, and iana-errors. </del> <ins> ErrorCodes.  Registries for managing these extension points are defined in RFC7540. </ins> Implementations MUST ignore unknown or unsupported values in all extensible protocol elements.  Implementations MUST discard frames
protocol. The cleartext version of HTTP/2 has minimal protection against cross- <del> protocol attacks.  The ConnectionHeader contains a string that is designed to confuse HTTP/1.1 servers, but no special protection is offered for other protocols. </del> <ins> protocol attacks.  The preface contains a string that is designed to confuse HTTP/1.1 servers, but no special protection is offered for other protocols. </ins> 10.3.
to HTTP/2, but are not redefined in this document. [RFC Editor: please remove this paragraph.]  IANA is requested to <del> update references in these registries to refer to this document.  The registration of the </del> <ins> update references to RFC 7540 in the following registries to refer to this document: Application-Layer Protocol Negotiation (ALPN) Protocol IDs, HTTP/2 Frame Type, HTTP/2 Settings, HTTP/2 Error Code, and HTTP Method Registry.  The registration of the </ins> method needs to be updated to refer to preface; all other section numbers have not changed.
This section marks the <del> header field registered in RFC7540 as obsoleted.  This capability has been removed: see versioning.  The registration is updated to include the details as required by HTTP: </del> <ins> header field registered by RFC7540 in the Hypertext Transfer Protocol (HTTP) Field Name Registry as obsolete.  This capability has been removed: see versioning.  The registration is updated to include the details as required by HTTP: </ins> 11.2. This section records the <del> upgrade token registered in RFC7540 as obsolete.  This capability has been removed: see versioning.  The registration is updated as </del> <ins> upgrade token registered by RFC7540 in the Hypertext Transfer Protocol (HTTP) Upgrade Token Registry as obsolete.  This capability has been removed: see versioning.  The registration is updated as </ins> follows:
All numeric values are in network byte order.  Values are unsigned unless otherwise indicated.  Literal values are provided in decimal or hexadecimal as appropriate.  Hexadecimal literals are prefixed <del> with </del> <ins> with " </ins> <del> to distinguish them from decimal literals. </del> <ins> " to distinguish them from decimal literals. </ins> This specification describes binary formats using the convention described in QUIC.  Note that this format uses network byte order and
The client connection preface starts with a sequence of 24 octets, which in hex notation is: <del> That is, the connection preface starts with the string </del> <ins> That is, the connection preface starts with the string " </ins> <del> . This sequence MUST be followed by a SETTINGS frame (SETTINGS), </del> <ins> ".  This sequence MUST be followed by a SETTINGS frame (SETTINGS), </ins> which MAY be empty.  The client sends the client connection preface as the first application data octets of a connection.
The HEADERS+PRIORITY frame is identical to the HEADERS, preceded by a single reserved bit and a 31-bit priority; see StreamPriority. <del> No type-specific flags are defined. </del> <ins> HEADERS+PRIORITY uses exactly the same flags as the HEADERS 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
PushResources contains a thorough description of the use of PUSH_PROMISE frames. <del> The body of a PUSH_PROMISE includes a "Promised-Stream-ID".  This </del> <ins> The payload of a PUSH_PROMISE includes a "Promised-Stream-ID".  This </ins> unsigned 31-bit integer identifies the stream the endpoint intends to start sending frames for.  The promised stream identifier MUST be a valid choice for the next stream sent by the sender (see
Any number of HEADERS frames can may be sent on an existing stream at any time. <del> The HEADERS frame does not define any type-specific flags. </del> <ins> Additional type-specific flags for the HEADERS frame are: </ins> <del> The body of a HEADERS frame contains a HeaderBlock. </del> <ins> Bit 2 being set indicates that this frame does not contain the entire payload necessary to interpret the HEADERS data.  The payload in any series of headers frames is only interpretable when HDR_CONTINUES has NOT been set, and then only when concatenated with the payload from the unbroken series of HEADERS frames where HDR_CONTINUES was set.  When this bit is set for a HEADERS frame on a particular stream (A), HEADERS frames MUST NOT be sent on other streams until a HEADERS frame has been sent on the same stream (A) where the HDR_CONTINUES bit is unset. The payload of a HEADERS frame contains a HeaderBlock. </ins> The HEADERS frame is associated with an existing stream.  If a HEADERS frame is received with a stream identifier of 0x0, the