jiebi/CodeConvo huggingface dataset:
connections becoming unusable due to limits on the number of messages the underlying cipher suite can encipher. <del> A client MAY use renegotiation to provide confidentiality protection for client credentials offered in the handshake, but any </del> <ins> An endpoint MAY use renegotiation to provide confidentiality protection for client credentials offered in the handshake, but any </ins> renegotiation MUST occur prior to sending the connection preface.  A server SHOULD request a client certificate if it sees a renegotiation request immediately after establishing a connection.
assigned incorrect or default priority values. Similarly, streams that are in the "idle" state can be assigned <del> priority or become a dependency for other streams.  This allows for the creation of a grouping node in the dependency tree, which enables </del> <ins> priority or become a parent of other streams.  This allows for the creation of a grouping node in the dependency tree, which enables </ins> more flexible expressions of priority.  Idle streams that are made a <del> dependency are assigned a pri-default. </del> <ins> parent of another stream are assigned a pri-default. </ins> The retention of priority information for streams that are not counted toward the limit set by
(remote)" or "closed" - state, this frame can only affect processing of the current stream and not frame transmission. <del> The PRIORITY frame is the only frame that can be sent for a stream in the "idle" or "closed" states.  This allows for the reprioritization of a group of dependent streams by altering the priority of an unused or closed parent stream. </del> <ins> The PRIORITY frame can be sent for a stream in the "idle" or "closed" states.  This allows for the reprioritization of a group of dependent streams by altering the priority of an unused or closed parent stream. </ins> A PRIORITY frame with a length other than 5 octets MUST be treated as a StreamErrorHandler of type
The general TLS usage guidance in TLSBCP SHOULD be followed, with some additional restrictions that are specific to HTTP/2. <del> An implementation of HTTP/2 over TLS MUST use TLS 1.2 or higher with the restrictions on feature set and cipher suite described in this section.  Due to implementation limitations, it might not be possible to fail TLS negotiation.  An endpoint MUST immediately terminate an HTTP/2 connection that does not meet the TLS requirements described in this section with a ConnectionErrorHandler of type </del> <ins> The TLS implementation MUST support the TLS-EXT extension to TLS. HTTP/2 clients MUST indicate the target domain name when negotiating TLS. </ins> <del> . </del> <ins> The restrictions in this and subsequent sections apply only to deployments of HTTP/2.  Implementations SHOULD provide defaults that comply, but it is recognized that deployments are ultimately responsible for compliance. </ins> 9.2.1. <del> The TLS implementation MUST support the TLS-EXT extension to TLS. HTTP/2 clients MUST indicate the target domain name when negotiating TLS. </del> <ins> A deployment of HTTP/2 over TLS MUST use TLS 1.2 or higher with the restrictions on feature set described in this section.  Due to deployment limitations, it might not be possible to fail TLS negotiation when these restrictions are not met.  An endpoint SHOULD immediately terminate an HTTP/2 connection that does not meet these TLS requirements with a ConnectionErrorHandler of type </ins> <del> The TLS implementation MUST disable compression.  TLS compression can lead to the exposure of information that would not otherwise be </del> <ins> . A deployment of TLS 1.2 MUST disable compression.  TLS compression can lead to the exposure of information that would not otherwise be </ins> revealed RFC3749.  Generic compression is unnecessary since HTTP/2 provides compression features that are more aware of context and therefore likely to be more appropriate for use for performance, security or other reasons. <del> The TLS implementation MUST disable renegotiation.  An endpoint MUST treat a TLS renegotiation as a ConnectionErrorHandler of type </del> <ins> The TLS 1.2 implementation MUST disable renegotiation.  An endpoint MUST treat a TLS renegotiation as a ConnectionErrorHandler of type </ins> .  Note that disabling renegotiation can result in long-lived connections becoming unusable due to limits on the number of messages
9.2.2. <del> The set of TLS cipher suites that are permitted in HTTP/2 is restricted.  HTTP/2 MUST only be used with cipher suites that have ephemeral key exchange, such as the TLS12 or the RFC4492.  Ephemeral key exchange MUST have a minimum size of 2048 bits for DHE or security level of 128 bits for ECDHE.  Clients MUST accept DHE sizes of up to 4096 bits.  HTTP MUST NOT be used with cipher suites that use stream or block ciphers.  Authenticated Encryption with Additional Data (AEAD) modes, such as the RFC5288 are acceptable. The effect of these restrictions is that TLS 1.2 implementations could have non-intersecting sets of available cipher suites, since these prevent the use of the cipher suite that TLS 1.2 makes mandatory.  To avoid this problem, implementations of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS-ECDHE with P256 FIPS186. Clients MAY advertise support of cipher suites that are prohibited by the above restrictions in order to allow for connection to servers that do not support HTTP/2.  This enables a fallback to protocols without these constraints without the additional latency imposed by using a separate connection for fallback. </del> <ins> The set of TLS 1.2 cipher suites that are permitted in HTTP/2 is restricted.  HTTP/2 MUST NOT be used with the cipher suites that are listed in BadCipherSuites.  Implementations MAY choose to generate a ConnectionErrorHandler of type if one of the prohibited cipher suites are negotiated; implementations MUST NOT generate this error in reaction to the negotiation of a cipher suite that is not in the prohibited list. The effect of prohibiting these cipher suites is that TLS 1.2 implementations could have non-intersecting sets of available cipher suites, since the prohibited set includes the cipher suite that TLS 1.2 makes mandatory.  To avoid this problem, implementations of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS-ECDHE with P256 FIPS186. A corollary of prohibiting the use of for cipher suites that are not prohibited is that when clients offer a cipher suite that is not prohibited, they have to be prepared to use that cipher suite with HTTP/2. </ins> 10.
unless separate compression dictionaries are used for each source of data.  Compression MUST NOT be used if the source of data cannot be reliably determined.  Generic stream compression, such as that <del> provided by TLS MUST NOT be used with HTTP/2 (TLSFeatures). </del> <ins> provided by TLS MUST NOT be used with HTTP/2 (TLSUsage). </ins> Further considerations regarding the compression of header fields are described in COMPRESSION.
The PRIORITY frame does not define any flags. <del> The PRIORITY frame is associated with an existing stream.  If a PRIORITY frame is received with a stream identifier of 0x0, the recipient MUST respond with a ConnectionErrorHandler of type </del> <ins> The PRIORITY frame always identifies a stream.  If a PRIORITY frame is received with a stream identifier of 0x0, the recipient MUST respond with a ConnectionErrorHandler of type </ins> .
cannot be sent between consecutive frames that comprise a single HeaderBlock.  Note that this frame could arrive after processing or frame sending has completed, which would cause it to have no effect <del> on the current stream.  For a stream that is in the "half closed </del> <ins> on the identified stream.  For a stream that is in the "half closed </ins> (remote)" or "closed" - state, this frame can only affect processing <del> of the current stream and not frame transmission. </del> <ins> of the identified stream and its dependent streams and not frame transmission on that stream. </ins> The PRIORITY frame can be sent for a stream in the "idle" or "closed" states.  This allows for the reprioritization of a group of dependent
The PUSH_PROMISE frame defines the following flags: <del> PUSH_PROMISE frames MUST be associated with an existing, peer- initiated stream.  The stream identifier of a PUSH_PROMISE frame indicates the stream it is associated with.  If the stream identifier field specifies the value 0x0, a recipient MUST respond with a ConnectionErrorHandler of type </del> <ins> 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 associated with.  If the stream identifier field specifies the value 0x0, a recipient MUST respond with a ConnectionErrorHandler of type </ins> .
A large HeaderBlock can cause an implementation to commit a large amount of state.  Header fields that are critical for routing can appear toward the end of a header block, which prevents streaming of <del> header fields to their ultimate destination.  For this an other </del> <ins> header fields to their ultimate destination.  For this and other </ins> reasons, such as ensuring cache correctness, means that an endpoint might need to buffer the entire header block.  Since there is no hard limit to the size of a header block, some endpoints could be forced
Promised requests MUST be cacheable (see RFC7231), MUST be safe (see RFC7231) and MUST NOT include a request body.  Clients that receive a <del> promised request that is not cacheable, unsafe or that includes a request body MUST reset the stream with a StreamErrorHandler of type </del> <ins> promised request that is not cacheable, is not known to be safe or that indicates the presence of a request body MUST reset the promised stream with a StreamErrorHandler of type </ins> <del> . </del> <ins> .  Note this could result in the promised stream being reset if the client does not recognize a newly defined method as being safe. </ins> Pushed responses that are cacheable (see RFC7234) can be stored by the client, if it implements an HTTP cache.  Pushed responses are
10.6. <del> HTTP/2 enables greater use of compression for both header fields (HeaderBlock) and entity bodies.  Compression can allow an attacker to recover secret data when it is compressed in the same context as data under attacker control. </del> <ins> Compression can allow an attacker to recover secret data when it is compressed in the same context as data under attacker control. HTTP/2 enables compression of header fields (HeaderBlock); the following concerns also apply to the use of HTTP compressed content- codings (RFC7231). </ins> There are demonstrable attacks on compression that exploit the characteristics of the web (e.g., BREACH).  The attacker induces
unless separate compression dictionaries are used for each source of data.  Compression MUST NOT be used if the source of data cannot be reliably determined.  Generic stream compression, such as that <del> provided by TLS MUST NOT be used with HTTP/2 (TLSUsage). </del> <ins> provided by TLS MUST NOT be used with HTTP/2 (see TLSUsage). </ins> Further considerations regarding the compression of header fields are described in COMPRESSION.
5.3.5. <del> Providing priority information is optional.  Streams are assigned a non-exclusive dependency on stream 0x0 by default.  PushResources initially depend on their associated stream.  In both cases, streams are assigned a default weight of 16. </del> <ins> All streams are initially assigned a non-exclusive dependency on stream 0x0.  PushResources initially depend on their associated stream.  In both cases, streams are assigned a default weight of 16. </ins> 5.4.
to correlate actions of a single client or server over time.  This includes the value of settings, the manner in which flow control windows are managed, the way priorities are allocated to streams, <del> timing of reactions to stimulus, and handling of any optional features. </del> <ins> timing of reactions to stimulus, and handling of any features that are controlled by settings. </ins> As far as this creates observable differences in behavior, they could be used as a basis for fingerprinting a specific client, as defined
token.  Such an HTTP/1.1 request MUST include exactly one Http2SettingsHeader header field. <del> Requests that contain an entity body MUST be sent in their entirety </del> <ins> Requests that contain an payload body MUST be sent in their entirety </ins> before the client can send HTTP/2 frames.  This means that a large <del> request entity can block the use of the connection until it is completely sent. </del> <ins> request can block the use of the connection until it is completely sent. </ins> If concurrency of an initial request with subsequent requests is important, an OPTIONS request can be used to perform the upgrade to
A name-value pair.  Both the name and value are treated as opaque sequences of octets. <del> The dynamic table (see dynamic.table) is a header table used to associate stored header fields to index values.  This table is dynamic and specific to an encoding or decoding context. </del> <ins> The dynamic table (see dynamic.table) is a table that associates stored header fields with index values.  This table is dynamic and specific to an encoding or decoding context. </ins> <del> The static table (see static.table) is a header table used to associate static header fields to index values.  This table is </del> <ins> The static table (see static.table) is a table that statically associates header fields with index values.  This table is </ins> ordered, read-only, always accessible, and may be shared amongst all encoding or decoding contexts.
acknowledgement (see HTTP2). Multiple updates to the maximum table size can occur between the <del> sending of two header blocks.  In the case that the value of this parameter is changed more than once, if any changed value is smaller than the new maximum size, the smallest value for the parameter MUST be sent in an encoding context update.  The altered maximum size is always sent, resulting in at most two encoding context updates.  This ensures that the decoder is able to perform eviction based on the decoder table size (see entry.eviction). </del> <ins> sending of two header blocks.  In the case that this size is changed more than once in this interval, the smallest maximum table size that occurs in that interval MUST be sent in an encoding context update. The final maximum size is always sent, resulting in at most two encoding context updates.  This ensures that the decoder is able to perform eviction based on reductions in decoder table size (see entry.eviction). </ins> This mechanism can be used to completely clear entries from the dynamic table by setting a maximum size of 0, which can subsequently
4.4. <del> Whenever a new entry is to be added to the dynamic table, entries are evicted from the end of the dynamic table until the size of the dynamic table is less than or equal to (maximum size - new entry size), or until the table is empty. </del> <ins> Before a new entry is added to the dynamic table, entries are evicted from the end of the dynamic table until the size of the dynamic table is less than or equal to (maximum size - new entry size), or until the table is empty. </ins> If the representation of the added entry references the name of an entry in the dynamic table, the referenced name is cached prior to
9.2.2. A deployment of HTTP/2 over TLS 1.2 SHOULD NOT use any of the cipher <del> suites that are listed in BadCipherSuites. </del> <ins> suites that are listed in the BadCipherSuites. </ins> Endpoints MAY choose to generate a ConnectionErrorHandler of type <del> if one of the prohibited cipher suites are negotiated.  A deployment that chooses to use a prohibited cipher suite risks triggering a connection error unless the set of potential peers is known to accept that cipher suite. </del> <ins> if one of the cipher suites from the black list are negotiated.  A deployment that chooses to use a black-listed cipher suite risks triggering a connection error unless the set of potential peers is known to accept that cipher suite. </ins> Implementations MUST NOT generate this error in reaction to the <del> negotiation of a cipher suite that is not in the prohibited list. Consequently, when clients offer a cipher suite that is not prohibited, they have to be prepared to use that cipher suite with </del> <ins> negotiation of a cipher suite that is not on the black list. Consequently, when clients offer a cipher suite that is not on the black list, they have to be prepared to use that cipher suite with </ins> HTTP/2. <del> The effect of prohibiting these cipher suites is that TLS 1.2 deployments could have non-intersecting sets of available cipher suites, since the prohibited set includes the cipher suite that TLS 1.2 makes mandatory.  To avoid this problem, deployments of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS-ECDHE with the P256 elliptic curve FIPS186. </del> <ins> The black list includes the cipher suite that TLS 1.2 makes mandatory, which means that TLS 1.2 deployments could have non- intersecting sets of permitted cipher suites.  To avoid this problem causing TLS handshake failures, deployments of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS-ECDHE with the P256 elliptic curve FIPS186. </ins> Note that clients might advertise support of cipher suites that are <del> prohibited by the above restrictions in order to allow for connection to servers that do not support HTTP/2 and support only prohibited cipher suites.  This allows servers to select HTTP/1.1 with a cipher suite that is prohibited for HTTP/2.  However, this can result in HTTP/2 being negotiated with a prohibited cipher suite if the application protocol and cipher suite are independently selected. </del> <ins> on the black list in order to allow for connection to servers that do not support HTTP/2.  This allows servers to select HTTP/1.1 with a cipher suite that is on the HTTP/2 black list.  However, this can result in HTTP/2 being negotiated with a black-listed cipher suite if the application protocol and cipher suite are independently selected. </ins> 10.
frame has the END_HEADERS flag set. Header compression is stateful.  One compression context and one <del> decompression context is used for the entire connection.  Each header block is processed as a discrete unit.  Header blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved frames of any other type or from any other stream.  The last frame in a sequence of </del> <ins> decompression context is used for the entire connection.  A decoding error in a header block MUST be treated as a ConnectionErrorHandler of type . Each header block is processed as a discrete unit.  Header blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved frames of any other type or from any other stream.  The last frame in a sequence of </ins> or
frame. <del> The HTTP/1.1 request that is sent prior to upgrade is assigned stream identifier 1 and is assigned pri-default.  Stream 1 is implicitly half closed from the client toward the server, since the request is completed as an HTTP/1.1 request.  After commencing the HTTP/2 connection, stream 1 is used for the response. </del> <ins> The HTTP/1.1 request that is sent prior to upgrade is assigned a stream identifier of 1 (see StreamIdentifiers) with pri-default. Stream 1 is implicitly "half closed" from the client toward the server (see StreamStates), since the request is completed as an HTTP/1.1 request.  After commencing the HTTP/2 connection, stream 1 is used for the response. </ins> 3.2.1.
An error on the HTTP/2.0 session. <del> A bi-directional flow of bytes across a virtual channel within the HTTP/2.0 session. </del> <ins> A bi-directional flow of frames across a virtual channel within the HTTP/2.0 session. </ins> An error on the individual HTTP/2.0 stream. 2. <del> Just as HTTP/1.1 does, HTTP/2.0 uses the "http:" and "https:" URI schemes.  An HTTP/2.0-capable client is therefore required to discover whether the upstream server (including intermediaries) supports HTTP/2.0. </del> <ins> HTTP/2.0 uses the same "http:" and "https:" URI schemes used by HTTP/1.1.  As a result, implementations processing requests for a target resource URIs like "http://example.org/foo" or "https://example.com/bar" are required to first discover whether the upstream server (the immediate peer to which the client wishes to establish a connection) supports HTTP/2.0. </ins> <del> Different discovery mechanisms are defined for "http:" and "https:" URIs.  Discovery for "http:" URIs is described in discover-http; discovery for "https:" URIs is described in discover-https. </del> <ins> The means by which support for HTTP/2.0 is determined is different for "http" and "https" URIs.  Discovery for "https:" URIs is described in discover-https.  Discovery for "http" URIs is described here. </ins> 2.1.
3.1. <del> The HTTP/2.0 session runs atop TCP (RFC0793).  The client is the TCP connection initiator. </del> <ins> The HTTP/2.0 session is an Application Level protocol running on top of a TCP connection (RFC0793).  The client is the TCP connection initiator. </ins> HTTP/2.0 connections are persistent.  That is, for best performance, <del> it is expected that clients will not close connections until the user navigates away from all Web pages referencing a connection, or until the server closes the connection.  Servers are encouraged to leave connections open for as long as possible, but can terminate idle connections if necessary.  When either endpoint closes the transport- level connection, it MUST first send a GOAWAY frame so that the endpoints can reliably determine if messages were processed beforehand. </del> <ins> it is expected a clients will not close connections until it is determined that no further communication with a server is necessary (for example, when a user navigates away from a particular web page), or until the server closes the connection. Servers are encouraged to maintain open connections for as long as possible, but are permitted to terminate idle connections if necessary.  When either endpoint chooses to close the transport-level TCP connection, the terminating endpoint MUST first send a GOAWAY frame so that both endpoints can reliably determine whether previously sent frames have been processed and gracefully complete or terminate any necessary remaining tasks. </ins> 3.2. <del> The first data sent on an HTTP/2.0 session - after opening a TCP connection and performing either an HTTP/1.1 Upgrade or TLS handshake - is a session header. The session header provides a final confirmation that both peers agree to use the HTTP/2.0 protocol.  The SETTINGS frame ensures that client or server configuration is known as quickly as possible. </del> <ins> Upon establishment of a TCP connection and determination that HTTP/2.0 will be used by both peers to communicate, each endpoint MUST send a session header as a final confirmation and to establish the default parameters for the HTTP/2.0 session. </ins> The client session header is a sequence of 25 octets (in hex notation)