jiebi/CodeConvo huggingface dataset:
Servers SHOULD NOT increase the QUIC MAX_STREAM_ID limit after sending a GOAWAY frame. <del> Once GOAWAY is sent, the server MUST reject requests sent on streams with an identifier greater than or equal to the indicated last Stream ID.  Clients MUST NOT send new requests on the connection after receiving GOAWAY, although requests might already be in transit.  A new connection can be established for new requests. If the client has sent requests on streams with a Stream ID greater than or equal to that indicated in the GOAWAY frame, those requests are considered rejected (request-cancellation).  Clients SHOULD cancel any requests on streams above this ID.  Servers MAY also reject requests on streams below the indicated ID if these requests were not processed. </del> <ins> Clients MUST NOT send new requests on the connection after receiving GOAWAY; a new connection MAY be established to send additional requests. Some requests might already be in transit.  If the client has already sent requests on streams with a Stream ID greater than or equal to that indicated in the GOAWAY frame, those requests will not be processed and MAY be retried by the client on a different connection. The client MAY cancel these requests.  It is RECOMMENDED that the server explicitly reject such requests (see request-cancellation) in order to clean up transport state for the affected streams. </ins> Requests on Stream IDs less than the Stream ID in the GOAWAY frame <del> might have been processed; their status cannot be known until they are completed successfully, reset individually, or the connection terminates. </del> <ins> might have been processed; their status cannot be known until a response is received, the stream is reset individually, or the connection terminates.  Servers MAY reject individual requests on streams below the indicated ID if these requests were not processed. </ins> Servers SHOULD send a GOAWAY frame when the closing of a connection is known in advance, even if the advance notice is small, so that the
can be mounted using spoofed source addresses.  In determining this limit, servers only count the size of successfully processed packets. <del> Clients MUST ensure that UDP datagrams containing Initial packets are sized to at least 1200 bytes, adding padding to packets in the datagram as necessary.  Once a client has received an acknowledgment for a Handshake packet it MAY send smaller datagrams.  Sending padded datagrams ensures that the server is not overly constrained by the amplification restriction. </del> <ins> Clients MUST ensure that UDP datagrams containing only Initial packets are sized to at least 1200 bytes, adding padding to packets in the datagram as necessary.  Sending padded datagrams ensures that the server is not overly constrained by the amplification restriction. </ins> Packet loss, in particular loss of a Handshake packet from the server, can cause a situation in which the server cannot send when
though 1-RTT keys are available to a server after receiving the first handshake messages from a client, the server cannot consider the client to be authenticated until it receives and validates the <del> client's Finished message. </del> <ins> client's Finished message.  A server MUST NOT process 1-RTT packets until the handshake is complete.  A server MAY buffer or discard 1-RTT packets that it cannot read. </ins> The requirement for the server to wait for the client Finished message creates a dependency on that message being delivered.  A
contain frames. QUIC payloads MUST contain at least one frame, and MAY contain <del> multiple frames and multiple frame types. </del> <ins> multiple frames and multiple frame types.  Frames MUST fit within a single QUIC packet and MUST NOT span a QUIC packet boundary. </ins> <del> Frames MUST fit within a single QUIC packet and MUST NOT span a QUIC packet boundary.  Each frame begins with a Frame Type, indicating its type, followed by additional type-dependent fields: </del> <ins> Each frame begins with a Frame Type, indicating its type, followed by additional type-dependent fields: </ins> The frame types defined in this specification are listed in frame- types.  The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED,
connections.  Servers MAY discard any Initial packet that does not carry the expected token. <ins> A token SHOULD be constructed for the server to easily distinguish it from tokens that are sent in Retry packets as they are carried in the same field. The token MUST NOT include information that would allow it to be linked by an on-path observer to the connection on which it was issued.  For example, it cannot include the connection ID or addressing information unless the values are encrypted. </ins> Unlike the token that is created for a Retry packet, there might be some time between when the token is created and when the token is <del> subsequently used.  Thus, a token SHOULD include an expiration time. The server MAY include either an explicit expiration time or an issued timestamp and dynamically calculate the expiration time.  It is also unlikely that the client port number is the same on two </del> <ins> subsequently used.  Thus, a token SHOULD have an expiration time, which could be either an explicit expiration time or an issued timestamp that can be used to dynamically calculate the expiration time.  A server can store the expiration time or include it in an encrypted form in the token. It is unlikely that the client port number is the same on two </ins> different connections; validating the port is therefore unlikely to be successful. <del> A token SHOULD be constructed for the server to easily distinguish it from tokens that are sent in Retry packets as they are carried in the same field. </del> If the client has a token received in a NEW_TOKEN frame on a previous connection to what it believes to be the same server, it SHOULD include that value in the Token field of its Initial packet.
Before a TLS ciphersuite can be used with QUIC, a header protection algorithm MUST be specified for the AEAD used with that ciphersuite. This document defines algorithms for AEAD_AES_128_GCM, <del> AEAD_AES_128_CCM, AEAD_AES_256_GCM, AEAD_AES_256_CCM (all AES AEADs are defined in AEAD), and AEAD_CHACHA20_POLY1305 CHACHA.  Prior to TLS selecting a ciphersuite, AES header protection is used (hp-aes), matching the AEAD_AES_128_GCM packet protection. </del> <ins> AEAD_AES_128_CCM, AEAD_AES_256_GCM (all AES AEADs are defined in AEAD), and AEAD_CHACHA20_POLY1305 CHACHA.  Prior to TLS selecting a ciphersuite, AES header protection is used (hp-aes), matching the AEAD_AES_128_GCM packet protection. </ins> 5.4.2.
5.4.3. This section defines the packet protection algorithm for <del> AEAD_AES_128_GCM, AEAD_AES_128_CCM, AEAD_AES_256_GCM, and AEAD_AES_256_CCM.  AEAD_AES_128_GCM and AEAD_AES_128_CCM use 128-bit AES AES in electronic code-book (ECB) mode.  AEAD_AES_256_GCM, and AEAD_AES_256_CCM use 256-bit AES in ECB mode. </del> <ins> AEAD_AES_128_GCM, AEAD_AES_128_CCM, and AEAD_AES_256_GCM. AEAD_AES_128_GCM and AEAD_AES_128_CCM use 128-bit AES AES in electronic code-book (ECB) mode.  AEAD_AES_256_GCM uses 256-bit AES in ECB mode. </ins> This algorithm samples 16 bytes from the packet ciphertext.  This value is used as the input to AES-ECB.  In pseudocode:
8.1. <del> The QUIC version negotiation mechanism is used to negotiate the version of QUIC that is used prior to the completion of the handshake.  However, this packet is not authenticated, enabling an active attacker to force a version downgrade. To ensure that a QUIC version downgrade is not forced by an attacker, version information is copied into the TLS handshake, which provides integrity protection for the QUIC negotiation.  This does not prevent version downgrade prior to the completion of the handshake, though it means that a downgrade causes a handshake failure. </del> QUIC requires that the cryptographic handshake provide authenticated protocol negotiation.  TLS uses Application Layer Protocol Negotiation (ALPN) RFC7301 to select an application protocol.  Unless
have been lost or discarded by the server.  A client MAY attempt to resend data in 0-RTT packets after it sends a new Initial packet. <del> A client MUST NOT reset the packet number it uses for 0-RTT packets. The keys used to protect 0-RTT packets will not change as a result of responding to a Retry packet unless the client also regenerates the cryptographic handshake message.  Sending packets with the same packet number in that case is likely to compromise the packet </del> <ins> A client MUST NOT reset the packet number it uses for 0-RTT packets, since the keys used to protect 0-RTT packets will not change as a result of responding to a Retry packet.  Sending packets with the same packet number in that case is likely to compromise the packet </ins> protection for all 0-RTT packets because the same key and nonce could be used to protect different content.
from a packet number of 0.  Thus, 0-RTT packets could need to use a longer packet number encoding. <del> A client SHOULD instead generate a fresh cryptographic handshake message and start packet numbers from 0.  This ensures that new 0-RTT packets will not use the same keys, avoiding any risk of key and nonce reuse; this also prevents 0-RTT packets from previous handshake attempts from being accepted as part of the connection. </del> A client MUST NOT send 0-RTT packets once it starts processing 1-RTT packets from the server.  This means that 0-RTT packets cannot contain any response to frames from 1-RTT packets.  For instance, a
compression-induced head-of-line blocking.  See that document for additional details. <ins> To allow for better compression efficiency, the cookie header field RFC6265 MAY be split into separate header fields, each with one or more cookie-pairs, before compression.  If a decompressed header list contains multiple cookie header fields, these MUST be concatenated before being passed into a non-HTTP/2, non-HTTP/3 context, as described in HTTP2, Section 8.1.2.5. </ins> An HTTP/3 implementation MAY impose a limit on the maximum size of the message header it will accept on an individual HTTP message.  A server that receives a larger header field list than it is willing to
The most appropriate error code (error-codes) SHOULD be included in the frame that signals the error.  Where this specification identifies error conditions, it also identifies the error code that <del> is used. </del> <ins> is used; though these are worded as requirements, different implementation strategies might lead to different errors being reported.  In particular, an endpoint MAY use any applicable error code when it detects an error condition; a generic error code (such as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place of specific error codes. </ins> A stateless reset (stateless-reset) is not suitable for any error that can be signaled with a CONNECTION_CLOSE or RESET_STREAM frame.
See iana-error-codes for details of registering new error codes. <ins> In defining these error codes, several principles are applied.  Error conditions that might require specific action on the part of a recipient are given unique codes.  Errors that represent common conditions are given specific codes.  Absent either of these conditions, error codes are used to identify a general function of the stack, like flow control or transport parameter handling. Finally, generic errors are provided for conditions where implementations are unable or unwilling to use more specific codes. </ins> 20.1. Application protocol error codes are 62-bit unsigned integers, but
process performed at the beginning of the connection SHOULD be applied for all paths used by the connection. <del> In case multiple connections share the same network path, as determined by having the same source and destination IP address and UDP ports, endpoints should try to co-ordinate across all connections to ensure a clear signal to any on-path measurement points. </del> When the spin bit is disabled, endpoints MAY set the spin bit to any value, and MUST ignore any incoming value.  It is RECOMMENDED that endpoints set the spin bit to a random value either chosen
An encoder informs the decoder of a change to the dynamic table capacity using an instruction which begins with the '001' three-bit <del> pattern.  The new dynamic table capacity is represented as an integer with a 5-bit prefix (see Section 5.1 of RFC7541). </del> <ins> pattern.  This is followed by the new dynamic table capacity represented as an integer with a 5-bit prefix (see prefixed- integers). </ins> The new capacity MUST be lower than or equal to the limit described in maximum-dynamic-table-capacity.  In HTTP/3, this limit is the
or the dynamic table using an instruction that starts with the '1' one-bit pattern.  The second ("S") bit indicates whether the reference is to the static or dynamic table.  The 6-bit prefix <del> integer (see Section 5.1 of RFC7541) that follows is used to locate the table entry for the header name.  When S=1, the number represents the static table index; when S=0, the number is the relative index of the entry in the dynamic table. </del> <ins> integer (see prefixed-integers) that follows is used to locate the table entry for the header name.  When S=1, the number represents the static table index; when S=0, the number is the relative index of the entry in the dynamic table. </ins> The header name reference is followed by the header field value <del> represented as a string literal (see Section 5.2 of RFC7541). </del> <ins> represented as a string literal (see string-literals). </ins> 4.3.3. An encoder adds an entry to the dynamic table where both the header field name and the header field value are represented as string <del> literals (see primitives) using an instruction that starts with the '01' two-bit pattern. </del> <ins> literals using an instruction that starts with the '01' two-bit pattern. </ins> <del> The name is represented as a 6-bit prefix string literal, while the value is represented as an 8-bit prefix string literal. </del> <ins> This is followed by the name represented as a 6-bit prefix string literal, and the value represented as an 8-bit prefix string literal (see string-literals). </ins> 4.3.4. An encoder duplicates an existing entry in the dynamic table using an <del> instruction that starts with the '000' three-bit pattern.  The relative index of the existing entry is represented as an integer with a 5-bit prefix. </del> <ins> instruction that begins with the '000' three-bit pattern.  This is followed by the relative index of the existing entry represented as an integer with a 5-bit prefix (see prefixed-integers. </ins> The existing entry is re-inserted into the dynamic table without resending either the name or the value.  This is useful to mitigate
After processing a header block whose declared Required Insert Count is not zero, the decoder emits a Header Acknowledgement instruction. <del> The instruction begins with the '1' one-bit pattern and includes the header block's associated stream ID, encoded as a 7-bit prefix integer.  It is used by the peer's encoder to know when it is safe to evict an entry (blocked-insertion), and possibly update the Known Received Count (known-received-count). </del> <ins> The instruction begins with the '1' one-bit pattern which is followed by the header block's associated stream ID encoded as a 7-bit prefix integer (see prefixed-integers). This instruction is used as described in known-received-count and in state-synchronization. </ins> If an encoder receives a Header Acknowledgement instruction referring to a stream on which every header block with a non-zero Required
When a stream is reset or reading is abandoned, the decoder emits a Stream Cancellation instruction.  The instruction begins with the <del> '01' two-bit pattern.  The instruction includes the stream ID of the affected stream encoded as a 6-bit prefix integer.  See state- synchronization. </del> <ins> '01' two-bit pattern, which is followed by the stream ID of the affected stream encoded as a 6-bit prefix integer. This instruction is used as described in state-synchronization. </ins> 4.4.3. The Insert Count Increment instruction begins with the '00' two-bit <del> pattern.  The instruction specifies the total number of dynamic table inserts and duplications since the last Insert Count Increment or Header Acknowledgement that increased the Known Received Count for the dynamic table (see known-received-count).  The Increment field is encoded as a 6-bit prefix integer.  The encoder uses this value to determine which table entries might cause a stream to become blocked, as described in state-synchronization. </del> <ins> pattern, followed by the Increment encoded as a 6-bit prefix integer. The value of the Increment is the total number of dynamic table insertions and duplications processed by the decoder since the last time it sent a Header Acknowledgement instruction that increased the Known Received Count (see known-received-count) or an Insert Count Increment instruction.  The encoder uses this value to update the Known Received Count, as described in state-synchronization. </ins> An encoder that receives an Increment field equal to zero or one that increases the Known Received Count beyond what the encoder has sent
4.5. <del> Header blocks contain compressed representations of header lists and are carried in frames on streams defined by the enclosing protocol. These representations reference the static table, or dynamic table in a particular state without modifying it. </del> <ins> A header block consists of a prefix and a possibly empty sequence of representations defined in this section.  Each representation corresponds to a single header field.  These representations reference the static table or the dynamic table in a particular state, but do not modify that state. Header blocks are carried in frames on streams defined by the enclosing protocol. </ins> 4.5.1.
absolute index less than the Base, this representation starts with the '1' 1-bit pattern, followed by the "S" bit indicating whether the reference is into the static or dynamic table.  The 6-bit prefix <del> integer (see Section 5.1 of RFC7541) that follows is used to locate the table entry for the header name.  When S=1, the number represents </del> <ins> integer (see prefixed-integers) that follows is used to locate the table entry for the header field.  When S=1, the number represents </ins> the static table index; when S=0, the number is the relative index of the entry in the dynamic table.
10. The security considerations of HTTP/3 should be comparable to those <del> of HTTP/2 with TLS.  Note that where HTTP/2 employs PADDING frames and Padding fields in other frames to make a connection more resistant to traffic analysis, HTTP/3 can either rely on transport- layer padding or employ the reserved frame and stream types discussed in frame-grease and stream-grease. </del> <ins> of HTTP/2 with TLS; the considerations from Section 10 of HTTP2 apply in addition to those listed here. </ins> When HTTP Alternative Services is used for discovery for HTTP/3 endpoints, the security considerations of ALTSVC also apply. <ins> 10.1. Where HTTP/2 employs PADDING frames and Padding fields in other frames to make a connection more resistant to traffic analysis, HTTP/3 can either rely on transport-layer padding or employ the reserved frame and stream types discussed in frame-grease and stream- grease.  These methods of padding produce different results in terms of the granularity of padding, the effect of packet loss and recovery, and how an implementation might control padding. 10.2. </ins> Several protocol elements contain nested length elements, typically in the form of frames with an explicit length containing variable- length integers.  This could pose a security risk to an incautious implementer.  An implementation MUST ensure that the length of a frame exactly matches the length of the fields it contains. <ins> 10.3. </ins> The use of 0-RTT with HTTP/3 creates an exposure to replay attack. The anti-replay mitigations in HTTP-REPLAY MUST be applied when using HTTP/3 with 0-RTT. <ins> 10.4. </ins> Certain HTTP implementations use the client address for logging or access-control purposes.  Since a QUIC client's address might change during a connection (and future versions might support simultaneous
peer.  For example, a client might be willing to consume a very large response header, while servers are more cautious about request size. <del> Parameters MUST NOT occur more than once in the SETTINGS frame.  A receiver MAY treat the presence of the same parameter more than once as a connection error of type HTTP_SETTINGS_ERROR. </del> <ins> The same setting identifier MUST NOT occur more than once in the SETTINGS frame.  A receiver MAY treat the presence of duplicate setting identifiers as a connection error of type HTTP_SETTINGS_ERROR. </ins> The payload of a SETTINGS frame consists of zero or more parameters. Each parameter consists of a setting identifier and a value, both
ChaCha20 function as defined in Section 2.4 of CHACHA.  This uses a 256-bit key and 16 bytes sampled from the packet protection output. <del> The first 4 bytes of the sampled ciphertext are interpreted as a 32-bit number in little-endian order and are used as the block count. The remaining 12 bytes are interpreted as three concatenated 32-bit numbers in little-endian order and used as the nonce. </del> <ins> The first 4 bytes of the sampled ciphertext are the block counter.  A ChaCha20 implementation could take a 32-bit integer in place of a byte sequence, in which case the byte sequence is interpreted as a little-endian value. The remaining 12 bytes are used as the nonce.  A ChaCha20 implementation might take an array of three 32-bit integers in place of a byte sequence, in which case the nonce bytes are interpreted as a sequence of 32-bit little-endian integers. </ins> The encryption mask is produced by invoking ChaCha20 to protect 5 zero bytes.  In pseudocode:
set to 0. A QUIC packet with a short header includes a Destination Connection <del> ID.  The short header does not include the Connection ID Lengths, Source Connection ID, or Version fields. </del> <ins> ID immediately following the first byte.  The short header does not include the Connection ID Lengths, Source Connection ID, or Version fields.  The length of the Destination Connection ID is not specified in packets with a short header and is not constrained by this specification. </ins> The remainder of the packet has version-specific semantics.
Packets containing only ACK frames are not congestion controlled, so there are limits on how frequently they can be sent.  An endpoint MUST NOT send more than one ACK-frame-only packet in response to <del> receiving an ack-eliciting packet (one containing frames other than ACK and/or PADDING).  An endpoint MUST NOT send a packet containing only an ACK frame in response to a non-ack-eliciting packet (one containing only ACK and/or PADDING frames), even if there are packet gaps which precede the received packet.  Limiting ACK frames avoids an infinite feedback loop of acknowledgements, which could prevent the connection from ever becoming idle.  However, the endpoint acknowledges non-ack-eliciting packets when it sends an ACK frame. </del> <ins> receiving an ack-eliciting packet.  An endpoint MUST NOT send a non- ack-eliciting packet in response to a non-ack-eliciting packet, even if there are packet gaps which precede the received packet.  Limiting ACK frames avoids an infinite feedback loop of acknowledgements, which could prevent the connection from ever becoming idle.  However, the endpoint acknowledges non-ACK-eliciting packets when it sends an ACK frame. </ins> An endpoint SHOULD treat receipt of an acknowledgment for a packet it did not send as a connection error of type PROTOCOL_VIOLATION, if it