jiebi/CodeConvo huggingface dataset:
When an intermediary coalesces HTTP requests coming from multiple clients into one HTTP/2 or HTTP/3 connection going to the backend <del> server, requests that originate from one client might carry priority signals indicating higher precedence than those coming from others. </del> <ins> server, requests that originate from one client might carry signals indicating higher priority than those coming from others. </ins> It is sometimes beneficial for the server running behind an intermediary to obey Priority header field values.  As an example, a resource-constrained server might defer the transmission of software update files that would have the background urgency being associated. <del> However, in the worst case, the asymmetry between the precedence </del> <ins> However, in the worst case, the asymmetry between the priority </ins> declared by multiple clients might cause responses going to one user agent to be delayed totally after those going to another.
Omitting content by truncating a message is only possible if the content is zero-length. <ins> 3.8. Messages can be padded with any number of zero-valued bytes.  Non- zero padding bytes cause a message to be invalid (see invalid). Unlike other parts of a message, a processor MAY decide not to validate the value of padding bytes. Padding is compatible with truncation of empty parts of the messages. Zero-valued bytes will be interpreted as zero-length part, which is semantically equivalent to the part being absent. </ins> 4. This document describes a number of ways that a message can be
shown in ex-bini-request.  As the content of this message is empty, the difference in formats is negligible. <del> This indefinite-length encoding can be truncated by two bytes in the same way. </del> <ins> This indefinite-length encoding contains 10 bytes of padding.  As two additional bytes can be truncated in the same way as the known-length example, anything up to 12 bytes can be removed from this message without affecting its meaning. </ins> 5.2.
has been superseded by "selected representation". This document replaces RFC3230.  The changes described in the <del> following paragraphs are intended to be semantically compatible with existing implementations where possible. </del> <ins> following paragraphs are intended to be syntactically and semantically compatible with existing implementations where possible. </ins> The "Digest" and "Want-Digest" field definitions are updated to align with the terms and notational conventions in SEMANTICS.
This document defines two digest integrity mechanisms for HTTP. First, representation data integrity, which acts on representation <del> data (Section 3.2 of SEMANTICS).  Second, content digest integrity, which acts on conveyed content (Section 6.4 of SEMANTICS).  Both mechanisms operate independent of transport integrity, offering the potential to detect programming errors and corruption of data in flight or at rest.  They can be used across multiple hops in order to provide end-to-end integrity guarantees, which can aid fault diagnosis when resources are transferred across hops and system boundaries.  Finally, they can be used to validate integrity when reconstructing a resource fetched using different HTTP connections. </del> <ins> data (Section 3.2 of SEMANTICS).  Second, content integrity, which acts on conveyed content (Section 6.4 of SEMANTICS).  Both mechanisms operate independent of transport integrity, offering the potential to detect programming errors and corruption of data in flight or at rest.  They can be used across multiple hops in order to provide end- to-end integrity guarantees, which can aid fault diagnosis when resources are transferred across hops and system boundaries. Finally, they can be used to validate integrity when reconstructing a resource fetched using different HTTP connections. </ins> This document obsoletes RFC3230.
Such signatures can protect one or more HTTP fields and there are additional considerations when "Digest" is included in this set. <del> Since digest fields are hashes of resource representations, they </del> <ins> Since digest fields are checksums of resource representations, they </ins> explicitly depend on the "representation metadata" (e.g. the values of "Content-Type", "Content-Encoding" etc).  A signature that protects "Digest" but not other "representation metadata" can expose
Digest Algorithm: md5 <del> Description: The MD5 algorithm, as specified in RFC1321.  The output of this algorithm is encoded using the base64 encoding RFC4648.  This digest-algorithm is now vulnerable to collision attacks.  See NO-MD5 and CMU-836068. </del> <ins> Description: The MD5 algorithm RFC1321.  The output of this algorithm is encoded using base64 RFC4648.  This digest- algorithm is now vulnerable to collision attacks.  See NO-MD5 and CMU-836068. </ins> Reference: RFC1321, RFC4648, this document.
Digest Algorithm: sha Description: The SHA-1 algorithm RFC3174.  The output of this <del> algorithm is encoded using the base64 encoding RFC4648.  This digest-algorithm is now vulnerable to collision attacks.  See NO-SHA1 and IACR-2020-014. </del> <ins> algorithm is encoded using base64 RFC4648.  This digest- algorithm is now vulnerable to collision attacks.  See NO-SHA1 and IACR-2020-014. </ins> Reference: RFC3174, RFC6234, RFC4648, this document.
Digest Algorithm: unixsum <del> Description: The algorithm computed by the UNIX "sum" command, as defined by the Single UNIX Specification, Version 2 UNIX. </del> <ins> Description: The algorithm used by the UNIX "sum" command UNIX. </ins> The output of this algorithm is an ASCII decimal-digit string representing the 16-bit checksum, which is the first word of the output of the UNIX "sum" command.
Digest Algorithm: unixcksum <del> Description: The algorithm computed by the UNIX "cksum" command, as defined by the Single UNIX Specification, Version 2 </del> <ins> Description: The algorithm used by the UNIX "cksum" command </ins> UNIX.  The output of this algorithm is an ASCII digit string representing the 32-bit CRC, which is the first word of the output of the UNIX "cksum" command.
Digest Algorithm: adler32 <del> Description: The ADLER32 algorithm is a checksum specified in RFC1950 "ZLIB Compressed Data Format".  The 32-bit output is encoded in hexadecimal (using between 1 and 8 ASCII characters from 0-9, A-F, and a-f; leading 0's are allowed).  For example, adler32=03da0195 and adler32=3DA0195 are both valid checksums for the 4-byte message "Wiki".  This algorithm is obsoleted and SHOULD NOT be used. </del> <ins> Description: The ADLER32 algorithm RFC1950.  The 32-bit output is encoded in hexadecimal (using between 1 and 8 ASCII characters from 0-9, A-F, and a-f; leading 0's are allowed). For example, adler32=03da0195 and adler32=3DA0195 are both valid checksums for the 4-byte message "Wiki".  This algorithm is obsoleted and SHOULD NOT be used. </ins> Reference: RFC1950, this document.
Digest Algorithm: crc32c <del> Description: The CRC32c algorithm is a 32-bit cyclic redundancy check.  It achieves a better hamming distance (for better error-detection performance) than many other 32-bit CRC functions.  Other places it is used include iSCSI and SCTP. The 32-bit output is encoded in hexadecimal (using between 1 and 8 ASCII characters from 0-9, A-F, and a-f; leading 0's are allowed).  For example, crc32c=0a72a4df and crc32c=A72A4DF are both valid checksums for the 3-byte message "dog". </del> <ins> Description: The CRC32c algorithm RFC4960.  The 32-bit output is encoded in hexadecimal (using between 1 and 8 ASCII characters from 0-9, A-F, and a-f; leading 0's are allowed). For example, crc32c=0a72a4df and crc32c=A72A4DF are both valid checksums for the 3-byte message "dog". </ins> Reference: RFC4960 appendix B, this document.
protocols that do not have strong ordering guarantees across streams, like HTTP/3 HTTP3. <del> Multiple experiments from independent research (MARX, MEENAN) have shown that simpler schemes can reach at least equivalent performance characteristics compared to the more complex RFC 7540 setups seen in practice, at least for the web use case. </del> <ins> Experiments from independent research (MARX) have shown that simpler schemes can reach at least equivalent performance characteristics compared to the more complex RFC 7540 setups seen in practice, at least for the web use case. </ins> 2.1.
Abstract <del> This document defines the HTTP header field "Client-Cert" that allows a TLS terminating reverse proxy to convey the client certificate of a mutually-authenticated TLS connection to the origin server in a common and predictable manner. </del> <ins> This document defines HTTP extension header fields that allow a TLS terminating reverse proxy to convey the client certificate information of a mutually-authenticated TLS connection to the origin server in a common and predictable manner. </ins> 1.
commonly occurring functionality could improve and simplify interoperability between independent implementations. <del> This document aspires to standardize an HTTP header field named "Client-Cert" that a TLS terminating reverse proxy (TTRP) adds to requests that it sends to the backend origin servers.  The field value contains the client certificate from the mutually-authenticated TLS connection between the originating client and the TTRP.  This enables the backend origin server to utilize the client certificate information in its application logic.  While there may be additional proxies or hops between the TTRP and the origin server (potentially even with mutually-authenticated TLS connections between them), the scope of the "Client-Cert" header field is intentionally limited to exposing to the origin server the certificate that was presented by the originating client in its connection to the TTRP. </del> <ins> This document aspires to standardize two HTTP header fields, "Client- Cert" and "Client-Cert-Chain", which a TLS terminating reverse proxy (TTRP) adds to requests sent to the backend origin servers.  The "Client-Cert" field value contains the end-entity client certificate from the mutually-authenticated TLS connection between the originating client and the TTRP.  Optionally, the "Client-Cert-Chain" field value contains the certificate chain used for validation of the end-entity certificate.  This enables the backend origin server to utilize the client certificate information in its application logic. While there may be additional proxies or hops between the TTRP and the origin server (potentially even with mutually-authenticated TLS connections between them), the scope of the "Client-Cert" header field is intentionally limited to exposing to the origin server the certificate that was presented by the originating client in its connection to the TTRP. </ins> 1.1.
connection are dispatched to the origin server with the following modifications: <del> The client certificate is be placed in the "Client-Cert" header field of the dispatched request as defined in header. </del> <ins> The client certificate is placed in the "Client-Cert" header field of the dispatched request, as described in header. </ins> <del> Any occurrence of the "Client-Cert" header field in the original incoming request MUST be removed or overwritten before forwarding the request.  An incoming request that has a "Client-Cert" header field MAY be rejected with an HTTP 400 response. </del> <ins> If so configured, the validation chain of the client certificate is placed in the "Client-Cert-Chain" header field of the request, as described in chain-header. Any occurrence of the "Client-Cert" or "Client-Cert-Chain" header fields in the original incoming request MUST be removed or overwritten before forwarding the request.  An incoming request that has a "Client-Cert" or "Client-Cert-Chain" header field MAY be rejected with an HTTP 400 response. </ins> Requests made over a TLS connection where the use of client certificate authentication was not negotiated MUST be sanitized by <del> removing any and all occurrences "Client-Cert" header field prior to dispatching the request to the backend server. </del> <ins> removing any and all occurrences of the "Client-Cert" and "Client- Cert-Chain" header fields prior to dispatching the request to the backend server. </ins> Backend origin servers may then use the "Client-Cert" header field of the request to determine if the connection from the client to the
presented by the client. Forward proxies and other intermediaries MUST NOT add the "Client- <del> Cert" header field to requests, or modify an existing "Client-Cert" header field.  Similarly, clients MUST NOT employ the "Client-Cert" header field in requests. A server that receives a request with a "Client-Cert" header field value that it considers to be too large can respond with an HTTP 431 status code per Section 5 of RFC6585. </del> <ins> Cert" or "Client-Cert-Chain" header fields to requests, or modify an existing "Client-Cert" or "Client-Cert-Chain" header field. Similarly, clients MUST NOT employ the "Client-Cert" or "Client-Cert- Chain" header field in requests. A server that receives a request with a "Client-Cert" or "Client- Cert-Chain" header field value that it considers to be too large can respond with an HTTP 431 status code per Section 5 of RFC6585. </ins> 3.
Similarly, clients MUST NOT employ the "Client-Cert" or "Client-Cert- Chain" header field in requests. <del> A server that receives a request with a "Client-Cert" or "Client- Cert-Chain" header field value that it considers to be too large can respond with an HTTP 431 status code per RFC6585. </del> 3. <ins> 3.1. If the client certificate header field is generated by an intermediary on a connection that compresses fields (e.g., using HPACK RFC7541 or QPACK I-D.ietf-quic-qpack) and more than one client's requests are multiplexed into that connection, it can reduce compression efficiency significantly, due to the typical size of the field value and its variation between clients.  Recipients that anticipate connections with these characteristics can mitigate the efficiency loss by increasing the size of the dynamic table.  If a recipient does not do so, senders may find it beneficial to always send the field value as a literal, rather than entering it into the dynamic table. 3.2. A server in receipt of a larger header block than it is willing to handle can send an HTTP 431 (Request Header Fields Too Large) status code per RFC6585.  Due to the typical size of the field values containing certificate data, recipients may need to be configured to allow for a larger maximum header block size.  An intermediary generating client certificate header fields on connections that allow for advertising the maximum acceptable header block size (e.g. HTTP/2 RFC7540 or HTTP/3 I-D.ietf-quic-http) should account for the additional size of header block of the requests it sends vs. requests it receives by advertising a value to its clients that is sufficiently smaller so as to allow for the addition of certificate data. 4. </ins> The header fields described herein enable a TTRP and backend or origin server to function together as though, from the client's perspective, they are a single logical server side deployment of
SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2. <del> If a server which advertises support for Extended CONNECT but receives an Extended CONNECT request with a ":protocol" value that is unknown or is not supported, the server SHOULD respond to the request with a 501 (Not Implemented) status code (HTTP).  A server MAY provide more information via a Problem Details response RFC7807. </del> <ins> If a server advertises support for Extended CONNECT but receives an Extended CONNECT request with a ":protocol" value that is unknown or is not supported, the server SHOULD respond to the request with a 501 (Not Implemented) status code (HTTP).  A server MAY provide more information via a Problem Details response RFC7807. </ins> 4.
Similarly, clients MUST NOT employ the "Client-Cert" or "Client-Cert- Chain" header field in requests. <ins> When the value of the "Client-Cert" request header field is used to select a response (e.g., the response content is access-controlled), the response MUST either be uncacheable (e.g., by sending "Cache- Control: no-store") or be designated for selective reuse only for subsequent requests with the same "Client-Cert" header value by sending a "Vary: Client-Cert" response header.  If a TTRP encounters a response with a "client-cert" field name in the "Vary" header field, it SHOULD prevent the user agent from caching the response by transforming the value of the "Vary" response header field to "*". </ins> 3. 3.1.
messages during the handshake and for the server to verify the CertificateVerify and Finished messages. <ins> HTTP/2 restricts TLS 1.2 renegotiation (RFC7540) and prohibits TLS 1.3 post-handshake authentication RFC8740.  However, they are sometimes used to implement reactive client certificate authentication in HTTP/1.1 RFC7230 where the server decides whether to request a client certificate based on the HTTP request.  HTTP application data sent on such a connection after receipt and verification of the client certificate is also mutually-authenticated and thus suitable for the mechanisms described in this document. </ins> 2. This document designates the following headers, defined further in
5. <del> The "Client-Cert" and "Client-Cert-Chain" HTTP header fields will be added to the registry defined by http-core. </del> <ins> 5.1. Please register the following entries in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" defined by I-D.ietf-httpbis- semantics: Field name: Client-Cert Status: permanent Specification document: headers of [this document] Field name: Client-Cert-Chain Status: permanent Specification document: headers of [this document] </ins>
and the RSA PSS algorithm described in method-rsa-pss-sha512, giving the following message signature output value, encoded in Base64: <ins> Note that the RSA PSS algorithm in use here is non-deterministic, meaning a different signature value will be created every time the algorithm is run.  The signature value provided here can be validated against the given keys, but newly-generated signature values are not expected to match the example.  See security-nondeterministic. </ins> 3.2. Verification of an HTTP message signature is a process that takes as
string to create the digest content to which the verification function is applied.  The verifier extracts the HTTP message signature to be verified ("S") as described in verify.  The results <del> of the verification function are compared to the http message signature to determine if the signature presented is valid. </del> <ins> of the verification function indicate if the signature presented is valid. Note that the output of RSA PSS algorithms are non-deterministic, and therefore it is not correct to re-calculate a new signature on the signature input and compare the results to an existing signature. Instead, the verification algorithm defined here needs to be used. See security-nondeterministic. </ins> Use of this algorithm can be indicated at runtime using the "rsa-pss- sha512" value for the "alg" signature parameter.
it be taken from the fields of the message.  The algorithm discussed in create-sig-input provides a safe order of operations. <ins> 7.19. Some cryptographic primitives such as RSA PSS and ECDSA have non- deterministic outputs, which include some amount of entropy within the algorithm.  For such algorithms, multiple signatures generated in succession will not match.  A lazy implementation of a verifier could ignore this distinction and simply check for the same value being created by re-signing the signature input.  Such an implementation would work for deterministic algorithms such as HMAC and EdDSA but fail to verify valid signatures made using non-deterministic algorithms.  It is therefore important that a verifier always use the correctly-defined verification function for the algorithm in question and not do a simple comparison. </ins> 8. 8.1.
This document uses the Augmented Backus-Naur Form (ABNF) notation of RFC5234 with the list rule extension defined in RFC7230, Appendix B. <del> It includes by reference the DIGIT rule from RFC5234; the OWS, field- name and quoted-string rules from RFC7230; and the parameter rule from RFC7231. </del> <ins> It includes by reference the DIGIT rule from RFC5234 and the OWS and field-name rules from RFC7230. </ins> 2.
received hints from the client.  When doing so, and if the resource is cacheable, the server MUST also emit a Vary response header field (Section 7.1.4 of RFC7231), and optionally Key (I-D.ietf-httpbis- <del> key), to indicate which hints were used and whether the selected response is appropriate for a later request. </del> <ins> key), to indicate which hints can affect the selected response and whether the selected response is appropriate for a later request. </ins> Further, depending on the used hint, the server can emit additional response header fields to confirm the property of the response, such
For example: <del> When a client receives Accept-CH, it SHOULD append the Client Hint header fields that match the advertised field-values.  For example, based on Accept-CH example above, the client would append DPR, Width, Viewport-Width, and Downlink header fields to all subsequent requests. </del> <ins> When a client receives Accept-CH, or if it is capable of processing the HTML response and finds an equivalent HTML meta element, it SHOULD append the Client-Hint header fields that match the advertised field-values to the header list of all subsequent requests.  For example, based on Accept-CH example above, a user agent could append DPR, Width, Viewport-Width, and Downlink header fields to all subresource requests initiated by the page constructed from the response.  Alternatively, a client can treat advertised support as a persistent origin preference and append same header fields on all future requests initiated to and by the resources associated with that origin. </ins> 2.2.2. When selecting an optimized response based on one or more Client Hints, and if the resource is cacheable, the server needs to emit a <del> Vary response header field (RFC7234) to indicate which hints were used and whether the selected response is appropriate for a later request. </del> <ins> Vary response header field (RFC7234) to indicate which hints can affect the selected response and whether the selected response is appropriate for a later request. </ins> Above example indicates that the cache key needs to include the DPR header field.
The "Width" request header field is a number that indicates the desired resource width in physical px (i.e. intrinsic size of an image).  The provided physical px value is a number rounded to the <del> largest smallest following integer (i.e. ceiling value). </del> <ins> smallest following integer (i.e. ceiling value). </ins> If the desired resource width is not known at the time of the request or the resource does not have a display width, the Width header field
7. <del> The "Save-Data" request header field is a token that indicates client's preference for reduced data usage, due to high transfer costs, slow connection speeds, or other reasons. </del> <ins> The "Save-Data" request header field consists of one or more tokens that indicate client's preference for reduced data usage, due to high transfer costs, slow connection speeds, or other reasons. </ins> This document defines the "on" sd-token value, which is used as a signal indicating explicit user opt-in into a reduced data usage mode
CTL characters that lead to set-cookie-string rejection, as it is considered whitespace, which is handled separately. <ins> NOTE: The set-cookie-string may contain octet sequences that appear percent-encoded as per Section 2.1 of RFC3986.  However, a user agent MUST NOT decode these sequences and instead parse the individual octets as specified in this algorithm. </ins> A user agent MUST use an algorithm equivalent to the following algorithm to parse a set-cookie-string: