jiebi/CodeConvo huggingface dataset:
to process further frames.  Note that this does not address the concerns raised in TALKING. <del> The server session header is a SETTINGS.  The server sends the server session header (i.e., a SETTINGS frame) as the first frame in a new session. </del> <ins> The server session header consists of just a SETTINGS that MUST be the first frame the server sends in the HTTP/2.0 session. </ins> <del> The client sends requests immediately after sending the session header, without waiting to receive a server session header.  This ensures that confirming session headers does not add latency. </del> <ins> In order to avoid unnecessary latency, clients are permitted to send additional frames to the server immediately after sending the client session header, without waiting to receive the server session header. However, it is important to note that the server session header SETTINGS frame might include parameters that necessarily alter how a client is expected to communicate with the server. </ins> <del> Both clients and servers MUST close the connection if it does not begin with a valid session header.  A GOAWAY MAY be omitted if it is clear that the peer is not using HTTP/2.0. </del> <ins> Clients and servers MUST terminate the TCP connection if either peer does not begin with a valid session header.  A GOAWAY MAY be omitted if it is clear that the peer is not using HTTP/2.0. </ins> 3.3. <del> Once the connection is established, clients and servers exchange HTTP/2.0 frames.  Frames are the basic unit of communication. </del> <ins> Once the HTTP/2.0 session is established, clients and servers can begin exchanging frames. </ins> 3.3.1.
A client that makes a request to an "https" URI uses TLS12 with the TLS-ALPN. <del> HTTP/2 over TLS uses the "h2" application token.  The "h2c" token MUST NOT be sent by a client or selected by a server. </del> <ins> HTTP/2 over TLS uses the "h2" protocol identifier.  The "h2c" protocol identifier MUST NOT be sent by a client or selected by a server; the "h2c" protocol identifier describes a protocol that does not use TLS. </ins> Once TLS negotiation is complete, both the client and the server MUST send a ConnectionHeader.
followed by the new maximum size, represented as an integer with a 5-bit prefix (see integer.representation). <del> The new maximum size MUST be lower than or equal to the last value of the maximum size of the dynamic table.  A value that exceeds this </del> <ins> The new maximum size MUST be lower than or equal to the limit determined by the protocol using HPACK.  A value that exceeds this </ins> limit MUST be treated as a decoding error.  In HTTP/2, this limit is the last value of the SETTINGS_HEADER_TABLE_SIZE parameter (see HTTP2) received from the decoder and acknowledged by the encoder (see
6.8. <del> The GOAWAY frame (type=0x7) informs the remote peer to stop creating streams on this connection.  GOAWAY can be sent by either the client or the server.  Once sent, the sender will ignore frames sent on any new streams with identifiers higher than the included last stream identifier.  Receivers of a GOAWAY frame MUST NOT open additional streams on the connection, although a new connection can be established for new streams. The purpose of this frame is to allow an endpoint to gracefully stop accepting new streams, while still finishing processing of previously established streams.  This enables administrative actions, like server maintenance. </del> <ins> The GOAWAY frame (type=0x7) is used to initiate shutdown of a connection or to signal serious error conditions.  GOAWAY allows an endpoint to gracefully stop accepting new streams, while still finishing processing of previously established streams.  This enables administrative actions, like server maintenance. </ins> There is an inherent race condition between an endpoint starting new streams and the remote sending a GOAWAY frame.  To deal with this
GOAWAY frame, the identified stream is the highest numbered stream initiated by the client. <ins> Once sent, the sender will ignore frames sent on streams initiated by the receiver if the stream has an identifier higher than the included last stream identifier.  Receivers of a GOAWAY frame MUST NOT open additional streams on the connection, although a new connection can be established for new streams. </ins> If the receiver of the GOAWAY has sent data on streams with a higher stream identifier than what is indicated in the GOAWAY frame, those streams are not or will not be processed.  The receiver of the GOAWAY
-1 and a code.  This signals to the client that a shutdown is imminent and <del> 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. </del> <ins> that initiating further requests is prohibited.  After allowing time for any in flight stream creation - 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 causing clients to lose requests. </ins> After sending a GOAWAY frame, the sender can discard frames for <del> streams with identifiers higher than the identified last stream. However, any frames that alter connection state cannot be completely ignored.  For instance, </del> <ins> streams initiated by the receiver with identifiers higher than the identified last stream.  However, any frames that alter connection state cannot be completely ignored.  For instance, </ins> ,
control window is set to the default initial window size until a WINDOW_UPDATE frame is received. <del> A </del> <ins> In addition to changing the flow control window for streams that are not yet active, a </ins> <del> frame can alter the initial flow control window size for all streams in the "open" or "half closed (remote)" state.  When the value of </del> <ins> frame can alter the initial flow control window size for streams with active flow control windows (that is, streams in the "open" or "half closed (remote)" state).  When the value of </ins> changes, a receiver MUST adjust the size of all stream flow control windows that it maintains by the difference between the new value and
The PUSH_PROMISE frame defines the following flags: <del> PUSH_PROMISE frames MUST be associated with a peer-initiated stream that is in either the "open" or "half closed (remote)" state.  The stream identifier of a PUSH_PROMISE frame indicates the stream it is </del> <ins> PUSH_PROMISE frames MUST only be sent on a peer-initiated stream that is in either the "open" or "half closed (remote)" state.  The stream identifier of a PUSH_PROMISE frame indicates the stream it is </ins> associated with.  If the stream identifier field specifies the value 0x0, a recipient MUST respond with a ConnectionErrorHandler of type
The server session header consists of just a SETTINGS that MUST be the first frame the server sends in the HTTP/2.0 session. <del> In order to avoid unnecessary latency, clients are permitted to send </del> <ins> To avoid unnecessary latency, clients are permitted to send </ins> additional frames to the server immediately after sending the client session header, without waiting to receive the server session header. <del> However, it is important to note that the server session header </del> <ins> It is important to note, however, that the server session header </ins> SETTINGS frame might include parameters that necessarily alter how a <del> client is expected to communicate with the server. </del> <ins> client is expected to communicate with the server.  Upon receiving the SETTINGS frame, the client is expected to honor any parameters established. </ins> Clients and servers MUST terminate the TCP connection if either peer does not begin with a valid session header.  A GOAWAY MAY be omitted
3.3.1. <del> HTTP/2.0 frames share a common format, consisting of 8 byte of header with between 0 and 65535 bytes of data. </del> <ins> HTTP/2.0 frames share a common base format consisting of an 8-byte header followed by 0 to 65535 bytes of data. </ins> The fields of the frame header are defined as: <del> The 16-bit length of the frame data in bytes.  The length of the frame header is not included. </del> <ins> The length of the frame data expressed as an unsigned, 16-bit integer.  The 8 bytes of the frame header are not included. </ins> The 8-bit type of the frame.  The frame type determines how the remainder of the frame header and data are interpreted.
3.4.2. <del> The creator of a stream can assign a priority for that stream. Priority is represented as a 31 bit integer.  0 represents the highest priority and 2 </del> <ins> The endpoint establishing a new stream can assign a priority for the stream.  Priority is represented as an unsigned 31-bit integer.  0 represents the highest priority and 2 </ins> -1 represents the lowest priority. <del> Senders and receivers SHOULD use best-effort to process streams in the order of highest priority to lowest priority. </del> <ins> The purpose of this value is to allow the initiating endpoint to request that frames for the stream be processed with higher priority relative to any other concurrently active streams.  That is, if an endpoint receives interleaved frames for multiple streams, the endpoint ought to make a best-effort attempt at processing frames for higher priority streams before processing those for lower priority streams. Explicitly setting the priority for a stream does not guarantee any particular processing order for the stream relative to any other stream.  Nor is there is any mechanism provided by which the initiator of a stream can force or require a receiving endpoint to process frames from one stream before processing frames from another. </ins> 3.4.3. <del> When one side of the stream sends a frame with the FINAL flag set, the stream is half-closed from that endpoint.  The sender of the FINAL flag MUST NOT send further frames on that stream.  When both sides have half-closed, the stream is closed. </del> <ins> When an endpoint sends a frame for a stream with the FINAL flag set, the stream is considered to be half-closed for that endpoint. Subsequent frames MUST NOT be sent by that endpoint for the half closed stream for the remaining duration of the HTTP/2.0 session. When both endpoints have sent frames with the FINAL flag set, the stream is considered to be fully closed. If an endpoint receives additional frames for a stream that was previously half-closed by the sending peer, the recipient MUST respond with a StreamErrorHandler of type STREAM_CLOSED. </ins> <del> Receivers of frames on a half-closed stream MUST handle them as a StreamErrorHandler of type STREAM_CLOSED. </del> <ins> An endpoint that has not yet half-closed a stream by sending the FINAL flag can continue sending frames on the stream. </ins> <del> It is not necessary to half-close a stream if no frames have been sent.  This allows an endpoint to create a unidirectional stream that does not require an explicit close from the peer that does not transmit frames.  Endpoints can avoid committing resources for streams until the first frame is received. </del> <ins> It is not necessary for an endpoint to half-close a stream for which it has not sent any frames.  This allows endpoints to utilize fully unidirectional streams that do not require explicit action or acknowledgement from the receiver. </ins> 3.4.4.
FINAL flag is sent.  The active sender on the stream MUST be prepared to receive frames after closing the stream. <del> Either the peer can send a RST_STREAM control frame at any time to </del> <ins> Either peer can send a RST_STREAM control frame at any time to </ins> terminate an active stream.  RST_STREAM contains an error code to indicate the reason for termination.  A RST_STREAM indicates that the sender will transmit no further data on the stream and that
HTTP/2 clients MUST indicate the target domain name when negotiating TLS. <del> Deployments of HTTP/2 that negotiate TLS 1.3 or higher need only support and use the SNI extension; deployments of TLS 1.2 are subject to the requirements in the following sections.  Implementations are </del> <ins> Requirements for deployments of HTTP/2 that negotiate TLS13 are included in tls13features.  Deployments of TLS 1.2 are subject to the requirements in tls12features and tls12ciphers.  Implementations are </ins> encouraged to provide defaults that comply, but it is recognized that deployments are ultimately responsible for compliance.
Implementations MUST support ephemeral key exchange sizes of at least 2048 bits for cipher suites that use ephemeral finite field Diffie- <del> Hellman (DHE) TLS12 and 224 bits for cipher suites that use ephemeral </del> <ins> Hellman (DHE) TLS13 and 224 bits for cipher suites that use ephemeral </ins> elliptic curve Diffie-Hellman (ECDHE) RFC4492.  Clients MUST accept DHE sizes of up to 4096 bits.  Endpoints MAY treat negotiation of key sizes smaller than the lower limits as a ConnectionErrorHandler of
HTTP/2 being negotiated with a prohibited cipher suite if the application protocol and cipher suite are independently selected. <ins> 9.2.3. TLS 1.3 includes a number of features not available in earlier versions.  This section discusses the use of these features. HTTP/2 servers MUST NOT send post-handshake TLS 1.3 CertificateRequest messages.  HTTP/2 clients MUST treat a TLS post- handshake CertificateRequest message as a ConnectionErrorHandler of type PROTOCOL_ERROR. The prohibition on post-handshake authentication applies even if the client offered the "post_handshake_auth" TLS extension.  Post- handshake authentication support might be advertised independently of TLS-ALPN.  Clients might offer the capability for use in other protocols, but inclusion of the extension cannot imply support within HTTP/2. TLS13 defines other post-handshake messages, NewSessionTicket and KeyUpdate, which can be used as they have no direct interaction with HTTP/2.  Unless the use of a new type of TLS message depends on an interaction with the application-layer protocol, that TLS message can be sent after the handshake completes. TLS early data MAY be used to send requests, provided that the guidance in RFC8470 is observed.  Clients send requests in early data assuming initial values for all server settings. </ins> 10. 10.1.
receives an unexpected stream identifier MUST respond with a ConnectionErrorHandler of type PROTOCOL_ERROR. <del> The first use of a new stream identifier implicitly closes all streams in the "idle" state that might have been initiated by that peer with a lower-valued stream identifier.  For example, if a client sends a HEADERS frame on stream 7 without ever sending a frame on stream 5, then stream 5 transitions to the "closed" state when the first frame for stream 7 is sent or received. </del> <ins> A HEADERS frame will transition the client-initiated stream identified by the stream identifier in the frame header from "idle" to "open".  A PUSH_PROMISE frame will transition the server-initiated stream identified by the "Promised Stream ID" field in the frame payload from "idle" to "reserved".  When a stream transitions out of the "idle" state, all streams that might have been initiated by that peer with a lower-valued stream identifier are implicitly transitioned to "closed".  That is, an endpoint may skip a stream identifier, with the effect being that the skipped stream is immediately closed. </ins> Stream identifiers cannot be reused.  Long-lived connections can result in an endpoint exhausting the available range of stream
A list of error codes is included in ErrorCodes. <ins> It is possible that an endpoint will encounter frames that would cause multiple errors.  Implementations MAY discover multiple errors during processing, but they SHOULD report at most one stream and one connection error as a result. The first stream error reported for a given stream prevents any other errors on that stream from being reported.  In comparison, the protocol permits multiple GOAWAY frames, though an endpoint SHOULD report just one type of connection error unless an error is encountered during graceful shutdown.  If this occurs, an endpoint MAY send an additional GOAWAY frame with the new error code, in addition to any prior GOAWAY that contained NO_ERROR. If an endpoint detects multiple different errors, it MAY choose to report any one of those errors.  If a frame causes a connection error, that error MUST be reported. </ins> 5.4.1. A connection error is any error that prevents further processing of
supports HTTP/2. The means by which support for HTTP/2 is determined is different for <del> "http" and "https" URIs.  Discovery for "http" URIs is described in discover-http.  Discovery for "https" URIs is described in discover- https. </del> <ins> "http" and "https" URIs.  Discovery for "https" URIs is described in discover-https.  HTTP/2 support for "http" URIs can only be discovered by out-of-band means, and requires prior knowledge of the support as described in known-http. </ins> 3.1.
. This sequence MUST be followed by a SETTINGS frame (SETTINGS), which MAY be empty.  The client sends the client connection preface <del> immediately upon receipt of a 101 (Switching Protocols) response (indicating a successful upgrade) or as the first application data octets of a TLS connection.  If starting an HTTP/2 connection with prior knowledge of server support for the protocol, the client connection preface is sent upon connection establishment. </del> <ins> as the first application data octets of a connection. </ins> The server connection preface consists of a potentially empty SETTINGS frame (SETTINGS) that MUST be the first frame the server
messages; the stream identifier of zero cannot be used to establish a new stream. <del> HTTP/1.1 requests that are upgraded to HTTP/2 (see discover-http) are responded to with a stream identifier of one (0x1).  After the upgrade completes, stream 0x1 is "half-closed (local)" to the client. Therefore, stream 0x1 cannot be selected as a new stream identifier by a client that upgrades from HTTP/1.1. </del> The identifier of a newly established stream MUST be numerically greater than all streams that the initiating endpoint has opened or reserved.  This governs streams that are opened using a HEADERS frame
The cleartext version of HTTP/2 has minimal protection against cross- protocol attacks.  The ConnectionHeader contains a string that is designed to confuse HTTP/1.1 servers, but no special protection is <del> offered for other protocols.  A server that is willing to ignore parts of an HTTP/1.1 request containing an Upgrade header field in addition to the client connection preface could be exposed to a cross-protocol attack. </del> <ins> offered for other protocols. </ins> 10.3.
excessive number of server push streams can be treated as a StreamErrorHandler of type ENHANCE_YOUR_CALM. <del> Processing capacity cannot be guarded as effectively as state capacity. The SETTINGS frame can be abused to cause a peer to expend additional processing time.  This might be done by pointlessly changing SETTINGS parameters, setting multiple undefined parameters, or changing the same setting multiple times in the same frame.  WINDOW_UPDATE or PRIORITY frames can be abused to cause an unnecessary waste of resources. Large numbers of small or empty frames can be abused to cause a peer to expend time processing frame headers.  Note, however, that some uses are entirely legitimate, such as the sending of an empty DATA or CONTINUATION frame at the end of a stream. Field section compression also offers some opportunities to waste processing resources; see COMPRESSION for more details on potential abuses. Limits in SETTINGS parameters cannot be reduced instantaneously, which leaves an endpoint exposed to behavior from a peer that could exceed the new limits.  In particular, immediately after establishing a connection, limits set by a server are not known to clients and could be exceeded without being an obvious protocol violation. All these features -- i.e., SETTINGS changes, small frames, field section compression -- have legitimate uses.  These features become a burden only when they are used unnecessarily or to excess. An endpoint that doesn't monitor this behavior exposes itself to a risk of denial-of-service attack.  Implementations SHOULD track the use of these features and set limits on their use.  An endpoint MAY treat activity that is suspicious as a ConnectionErrorHandler of type </del> <ins> A number of HTTP/2 implementations were found to be vulnerable to denial of service NFLX-2019-002.  The following lists known ways that implementations might be subject to denial of service attack: Most of the features that might be exploited for denial of service -- i.e., SETTINGS changes, small frames, field section compression -- have legitimate uses.  These features become a burden only when they are used unnecessarily or to excess. An endpoint that doesn't monitor use of these features exposes itself to a risk of denial of service.  Implementations SHOULD track the use of these features and set limits on their use.  An endpoint MAY treat activity that is suspicious as a ConnectionErrorHandler of type </ins> ENHANCE_YOUR_CALM. 10.5.1.
Although POSTs are inherently chunked, POST requests SHOULD also be accompanied by a Content-Length header field.  First, it informs the <del> server of how much data to expect, which the server can used to track </del> <ins> server of how much data to expect, which the server can use to track </ins> overall progress and provide appropriate user feedback.  More importantly, some HTTP server implementations fail to correctly process requests that omit the Content-Length header field.  Many <del> existing clients send a Content-Length header field, which caused server implementations have come to depend upon its presence. </del> <ins> existing clients send a Content-Length header field, and some server implementations have come to depend upon its presence. </ins> The user-agent is free to prioritize requests as it sees fit.  If the user-agent cannot make progress without receiving a resource, it
A client cannot push.  Thus, servers MUST treat the receipt of a PUSH_PROMISE frame as a ConnectionErrorHandler of type <del> PROTOCOL_ERROR.  Clients MUST reject any attempt to change the SETTINGS_ENABLE_PUSH setting to a value other than 0 by treating the message as a ConnectionErrorHandler of type PROTOCOL_ERROR. </del> <ins> PROTOCOL_ERROR.  A server cannot set the SETTINGS_ENABLE_PUSH setting to a value other than 0 (see SettingValues). </ins> 8.2.1.
version 2 (HTTP/2).  HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the <del> same connection.  It also introduces unsolicited push of representations from servers to clients. </del> <ins> same connection. </ins> This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.