jiebi/CodeConvo huggingface dataset:
therefore likely to be more appropriate for use for performance, security or other reasons. <del> Implementations MUST negotiate - and therefore use - ephemeral cipher suites, such as ephemeral Diffie-Hellman (DHE) or the elliptic curve variant (ECDHE) with a minimum size of 2048 bits (DHE) or security level of 128 bits (ECDHE).  Clients MUST accept DHE sizes of up to 4096 bits. Implementations are encouraged not to negotiate TLS cipher suites with known vulnerabilities, such as RC4. An implementation that negotiates a TLS connection that does not meet the requirements in this section, or any policy-based constraints, SHOULD NOT negotiate HTTP/2.  Removing HTTP/2 protocols from consideration could result in the removal of all protocols from the set of protocols offered by the client.  This causes protocol negotiation failure, as described in TLSALPN. Due to implementation limitations, it might not be possible to fail TLS negotiation based on all of these requirements.  An endpoint MUST terminate an HTTP/2 connection that is opened on a TLS session that does not meet these minimum requirements with a ConnectionErrorHandler of type </del> <ins> 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. Clients MAY advertise support of other cipher suites in order to allow for connection to servers that do not support HTTP/2 to complete without the additional latency imposed by using a separate connection for fallback. An implementation SHOULD NOT negotiate a TLS connection for HTTP/2 without also negotiating a cipher suite that meets these requirements.  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 these minimum requirements with a ConnectionErrorHandler of type </ins> .
. <del> 9.3. Clients MUST support GZIP compression for HTTP response bodies. Regardless of the value of the accept-encoding header field, a server MAY send responses with GZIP encoding.  A compressed response MUST still bear an appropriate content-encoding header field. This effectively changes the implicit value of the Accept-Encoding header field (HTTP-p2) from "identity" to "identity, gzip", however GZIP encoding cannot be suppressed by including ";q=0". Intermediaries that perform translation from HTTP/2 to HTTP/1.1 MUST decompress payloads unless the request includes an Accept-Encoding value that includes "gzip". </del> 10. 10.1.
Bit 4 being set indicates that the Pad Length field is present. <del> Bit 6 being set indicates that the data in the frame has been compressed with GZIP compression (GZIP).  Padding is not compressed. </del> DATA frames MUST be associated with a stream.  If a DATA frame is received whose stream identifier field is 0x0, the recipient MUST respond with a ConnectionErrorHandler of type . <del> Data frames are optionally compressed using GZIP.  Each frame is individually compressed; the state of the compressor is reset for each frame. An endpoint MUST NOT send a DATA frame with the COMPRESSED flag set unless the setting is enabled, that is, set to 1.  An endpoint that has not enabled DATA frame compression MUST treat the receipt of a DATA frame with the COMPRESSED flag set as a ConnectionErrorHandler of type . </del> DATA frames are subject to flow control and can only be sent when a stream is in the "open" or "half closed (remote)" states.  The entire DATA frame payload is included in flow control, including Pad Low,
instead send an ALTSVC frame.  A single ALTSVC frame can be sent for a connection; a new frame is not required for every request. <ins> When using HTTP2, clients SHOULD instead send an ALTSVC frame.  A single ALTSVC frame can be sent for a connection; a new frame is not required for every request. </ins> 3.1. When an alternative service is advertised using Alt-Svc, it is
7.2.3. A literal header field never indexed representation causes the <del> emission of a header field without altering the header table.  It requires intermediaries to use the same representation for encoding this header field. </del> <ins> emission of a header field without altering the header table. Intermediaries MUST use the same representation for encoding this header field. </ins> A literal header field never indexed representation starts with the '0001' 4-bit pattern.
connection. Extensions are permitted to use new FrameHeader, SettingValues, <del> ErrorCodes, header fields that start with a colon (:), or any reserved flags or fields in frames.  Of these, registries are established for iana-frames, iana-settings and iana-errors. </del> <ins> ErrorCodes, or header fields that start with a colon (:).  Of these, registries are established for iana-frames, iana-settings and iana- errors. </ins> Implementations MUST ignore unknown or unsupported values in all extensible protocol elements.  Implementations MUST discard frames <del> that have unknown or unsupported types.  Note that only frames can be flow controlled, extensions cannot be flow controlled. This means that any of these extension points can be safely used by extensions without prior arrangement or negotiation. </del> <ins> that have unknown or unsupported types.  This means that any of these extension points can be safely used by extensions without prior arrangement or negotiation. </ins> However, extensions can negotiate any use that could change to the semantics of existing protocol components.  For example, an extension
frame cannot be used until the peer has given a positive signal that this is acceptable.  In this case, it could also be necessary to <del> coordinate when the revised layout comes into effect. </del> <ins> coordinate when the revised layout comes into effect.  Note that treating any frame other than frames as flow controlled is such a change in semantics, and can only be done through negotiation. </ins> This document doesn't mandate a specific method for negotiating the use of an extension, but notes that a SettingValues could be used for
4.3. <del> A header field in HTTP/2 is a name-value pair with one or more associated values.  They are used within HTTP request and response messages as well as server push operations (see PushResources). </del> <ins> A header field in HTTP/2 is a name with one or more associated values.  They are used within HTTP request and response messages as well as server push operations (see PushResources). </ins> Header sets are collections of zero or more header fields.  When transmitted over a connection, a header set is serialized into a
Stream identifiers cannot be reused.  Long-lived connections can result in an endpoint exhausting the available range of stream identifiers.  A client that is unable to establish a new stream <del> identifier can establish a new connection for new streams. </del> <ins> identifier can establish a new connection for new streams.  A server that is unable to establish a new stream identifier may send a frame to require the client to establish a new connection. </ins> 5.1.2.
prioritization, since the stream could be given a priority that is higher than intended. <del> To avoid these problems, endpoints SHOULD maintain prioritization state for closed streams for a period after streams close. An endpoint SHOULD retain stream prioritization state for a period after streams become closed.  The longer state is retained, the lower the chance that streams are assigned incorrect or default priority values. </del> <ins> To avoid these problems, an endpoint SHOULD retain stream prioritization state for a period after streams become closed.  The longer state is retained, the lower the chance that streams are assigned incorrect or default priority values. </ins> This could create a large state burden for an endpoint, so this state MAY be limited.  An endpoint MAY apply a fixed upper limit on the
that requires immediate termination of the connection.  The last stream identifier from the last GOAWAY frame received indicates which streams could have been acted upon.  Endpoints MUST NOT increase the <del> value they send in the last stream identifier, since this could cause their peers to erroneously retry streams if a GOAWAY frame is lost. </del> <ins> value they send in the last stream identifier, since the peers might already have retried unprocessed requests on another connection. </ins> A client that is unable to retry requests loses all requests that are in flight when the server closes the connection.  This is especially
subject to flow control.  Of the frame types defined in this document, this includes only <del> frame.  Frames that are exempt from flow control MUST be accepted and processed, unless the receiver is unable to assign resources to </del> <ins> frames.  Frames that are exempt from flow control MUST be accepted and processed, unless the receiver is unable to assign resources to </ins> handling the frame.  A receiver MAY respond with a StreamErrorHandler or ConnectionErrorHandler of type
3.3. A client that makes a request to an "https" URI without prior <del> knowledge about support for HTTP/2 uses TLS12 with the TLSALPN. </del> <ins> knowledge about support for HTTP/2 uses TLS12 with the TLS-ALPN. </ins> HTTP/2 over TLS uses the "h2" application token.  The "h2c" token MUST NOT be sent by a client or selected by a server.
such a connection by the use of the "PRI" method in the connection preface.  This only affects the establishment of HTTP/2 connections over cleartext TCP; implementations that support HTTP/2 over TLS MUST <del> use TLSALPN. </del> <ins> use TLS-ALPN. </ins> Prior support for HTTP/2 is not a strong signal that a given server will support HTTP/2 for future connections.  It is possible for
use stream or block ciphers.  Authenticated Encryption with Additional Data (AEAD) modes, such as the RFC5288 are acceptable. <del> Clients MAY advertise support of other cipher suites in order to allow for connection to servers that do not support HTTP/2 to complete without the additional latency imposed by using a separate connection for fallback. </del> <ins> 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. </ins> An implementation SHOULD NOT negotiate a TLS connection for HTTP/2 without also negotiating a cipher suite that meets these
values.  They are used within HTTP request and response messages as well as server push operations (see PushResources). <del> Header sets are collections of zero or more header fields.  When transmitted over a connection, a header set is serialized into a </del> <ins> Header lists are collections of zero or more header fields.  When transmitted over a connection, a header list is serialized into a </ins> header block using COMPRESSION.  The serialized header block is then divided into one or more octet sequences, called header block fragments, and transmitted within the payload of HEADERS, PUSH_PROMISE or CONTINUATION frames. <del> HTTP Header Compression does not preserve the relative ordering of header fields.  Header fields with multiple values are encoded into a single header field using a special delimiter (see HeaderOrdering), this preserves the relative order of values for that header field. </del> The COOKIE is treated specially by the HTTP mapping (see CompressCookie). A receiving endpoint reassembles the header block by concatenating its fragments, then decompresses the block to reconstruct the header <del> set. </del> <ins> list. </ins> A complete header block consists of either:
encoding in HTTP/2.  A request or response containing uppercase header field names MUST be treated as malformed. <ins> All pseudo-header fields MUST appear in the header block before regular header fields.  Any request or response that contains any pseudo-header field that appears in a header block after a regular header field MUST treated as malformed. 8.1.2.2. </ins> HTTP/2 does not use the Connection header field to indicate "hop-by- hop" header fields; in this protocol, connection-specific metadata is conveyed by other means.  As such, a HTTP/2 message containing
HTTP/2 does not define a way to carry the version or reason phrase that is included in an HTTP/1.1 status line. <del> 8.1.2.3. COMPRESSION does not preserve the order of header fields, because the relative order of header fields with different names is not important.  However, the same header field can be repeated to form a list (see RFC7230), where the relative order of header field values is significant.  This repetition can occur either as a single header field with a comma-separated list of values, or as several header fields with a single value, or any combination thereof.  Therefore, in the latter case, ordering needs to be preserved before compression takes place. To preserve the order of multiple occurrences of a header field with the same name, its ordered values are concatenated into a single value using a zero-valued octet (0x0) to delimit them. After decompression, header fields that have values containing zero octets (0x0) MUST be split into multiple header fields before being processed. For example, the following HTTP/1.x header block: contains three Cache-Control directives; two directives in the first Cache-Control header field, and the third directive in the second Cache-Control field.  Before compression, they would need to be converted to a form similar to this (with 0x0 represented as '\0'): Note here that the ordering between Content-Type and Cache-Control is not preserved, but the relative ordering of the Cache-Control directives - as well as the fact that the first two were comma- separated, while the last was on a different line - is. Header fields containing multiple values MUST be concatenated into a single value unless the ordering of that header field is known to be not significant. The special case of "set-cookie" - which does not form a comma- separated list, but can have multiple values - does not depend on ordering.  The "set-cookie" header field MAY be encoded as multiple header field values, or as a single concatenated value. 8.1.2.4. </del> <ins> 8.1.2.5. </ins> The COOKIE can carry a significant amount of redundant data.
before being passed into a non-HTTP/2 context, such as an HTTP/1.1 connection, or a generic HTTP server application. <del> The Cookie header field MAY be split using a zero octet (0x0), as defined in HeaderOrdering.  When decoding, zero octets MUST be replaced with the cookie delimiter ("; "). 8.1.2.5. </del> <ins> 8.1.2.6. </ins> A malformed request or response is one that is an otherwise valid sequence of HTTP/2 frames, but is otherwise invalid due to the
Abstract <del> This specification describes an optimized expression of the syntax of the Hypertext Transfer Protocol (HTTP).  HTTP/2 enables a more </del> <ins> This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP).  HTTP/2 enables a more </ins> efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent messages on the same connection.  It also introduces
are used in support of other HTTP/2 features. Multiplexing of requests is achieved by having each HTTP request- <del> response exchanged assigned to a single StreamsLayer.  Streams are largely independent of each other, so a blocked or stalled request does not prevent progress on other requests. </del> <ins> response exchange associated with its own StreamsLayer.  Streams are largely independent of each other, so a blocked or stalled request or response does not prevent progress on other streams. </ins> Flow control and prioritization ensure that it is possible to <del> properly use multiplexed streams.  FlowControl helps to ensure that only data that can be used by a receiver is transmitted. </del> <ins> efficiently use multiplexed streams.  FlowControl helps to ensure that only data that can be used by a receiver is transmitted. </ins> StreamPriority ensures that limited resources can be directed to the <del> most important requests first. </del> <ins> most important streams first. </ins> HTTP/2 adds a new interaction mode, whereby a server can PushResources.  Server push allows a server to speculatively send a
using frames and streams. While some of the frame and stream layer concepts are isolated from <del> HTTP, the intent is not to define a completely generic framing layer. The framing and streams layers are tailored to the needs of the HTTP protocol and server push. </del> <ins> HTTP, this specification does not define a completely generic framing layer.  The framing and streams layers are tailored to the needs of the HTTP protocol and server push. </ins> 2.2.
8.2. HTTP/2 allows a server to pre-emptively send (or "push") responses <del> (along with corresponding requests) to a client in 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> (along with corresponding "promised" requests) to a client in 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. </ins> Pushing additional message exchanges in this fashion is optional, and is negotiated between individual endpoints.  The setting can be set to 0 to indicate that server push is disabled. <ins> Promised requests MUST be cacheable (see RFC7231), MUST be safe (see RFC7231) and MUST NOT include a request body.  Clients that receive a promised request that is not cacheable, unsafe or that includes a request body MUST reset the stream with a StreamErrorHandler of type . Pushed responses that are cacheable (see RFC7234) SHOULD be stored by the client, if it implements a HTTP cache.  Such responses MAY be considered successfully validated on the origin server (e.g., if the "no-cache" cache response directive RFC7234 is present) while the stream identified by the promised stream ID is still open. Pushed responses that are not cacheable MUST NOT be stored by any HTTP cache.  They MAY be made available to the application separately. </ins> Because server push is effectively hop-by-hop, an intermediary could receive pushes from the server and choose not to forward them on to the client.  In other words, how to make use of the pushed
frame.  SettingsSync is not necessary, since a 101 response serves as implicit acknowledgment.  Providing these values in the Upgrade <del> request ensures that the protocol does not require default values for the above SETTINGS parameters, and gives a client an opportunity to provide other parameters prior to receiving any frames from the server. </del> <ins> request gives a client an opportunity to provide parameters prior to receiving any frames from the server. </ins> 3.3. <del> A client that makes a request to an "https" URI without prior knowledge about support for HTTP/2 uses TLS12 with the TLS-ALPN. </del> <ins> A client that makes a request to an "https" URI uses TLS12 with the TLS-ALPN. </ins> HTTP/2 over TLS uses the "h2" application token.  The "h2c" token MUST NOT be sent by a client or selected by a server.
4. <del> 4.1. </del> To limit the memory requirements on the decoder side, the dynamic table is constrained in size. <ins> 4.1. The size of the dynamic table is the sum of the size of its entries. The size of an entry is the sum of its name's length in octets (as defined in string.literal.representation), its value's length in octets (see string.literal.representation), plus 32. The size of an entry is calculated using the length of the name and value without any Huffman encoding applied. NOTE: The additional 32 octets account for the overhead associated with an entry.  For example, an entry structure using two 64-bit pointers to reference the name and the value of the entry, and two 64-bit integers for counting the number of references to the name and value would have 32 octets of overhead. 4.2. </ins> Protocols that use HPACK determine the maximum size of table that the encoder is permitted to use.  In HTTP/2, this value is determined by the SETTINGS_HEADER_TABLE_SIZE setting (see HTTP2).
dynamic table by setting a maximum size of 0, which can subsequently be restored. <del> The size of the dynamic table is the sum of the size of its entries. The size of an entry is the sum of its name's length in octets (as defined in string.literal.representation), its value's length in octets (see string.literal.representation), plus 32. The size of an entry is calculated using the length of the name and value without any Huffman encoding applied. NOTE: The additional 32 octets account for the overhead associated with an entry.  For example, an entry structure using two 64-bit pointers to reference the name and the value of the entry, and two 64-bit integers for counting the number of references to the name and value would have 32 octets of overhead. 4.2. </del> <ins> 4.3. </ins> Whenever the maximum size for the dynamic table is reduced, entries are evicted from the end of the dynamic table until the size of the dynamic table is less than or equal to the maximum size. <del> 4.3. </del> <ins> 4.4. </ins> 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
. Pushed responses that are cacheable (see RFC7234) can be stored by <del> the client, if it implements a HTTP cache.  Pushed responses are </del> <ins> the client, if it implements an HTTP cache.  Pushed responses are </ins> considered successfully validated on the origin server (e.g., if the "no-cache" cache response directive RFC7234 is present) while the stream identified by the promised stream ID is still open.
The DATA frame defines the following flags: <del> Bit 1 being set indicates that this frame is the last that the </del> <ins> Bit 0 being set indicates that this frame is the last that the </ins> endpoint will send for the identified stream.  Setting this flag causes the stream to enter one of StreamStates. <del> Bit 4 being set indicates that the Pad Length field and any </del> <ins> Bit 3 being set indicates that the Pad Length field and any </ins> padding that it describes is present. DATA frames MUST be associated with a stream.  If a DATA frame is
SETTINGS parameters are acknowledged by the receiving peer.  To enable this, the SETTINGS frame defines the following flag: <del> Bit 1 being set indicates that this frame acknowledges receipt and </del> <ins> Bit 0 being set indicates that this frame acknowledges receipt and </ins> application of the peer's SETTINGS frame.  When this bit is set, the payload of the SETTINGS frame MUST be empty.  Receipt of a SETTINGS frame with the ACK flag set and a length field value