jiebi/CodeConvo huggingface dataset:
Backend origin servers may then use the "Client-Cert" header field of the request to determine if the connection from the client to the TTRP was mutually-authenticated and, if so, the certificate thereby <del> presented by the client. Forward proxies and other intermediaries MUST NOT add the "Client- 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. </del> <ins> presented by the client.  Access control decisions based on the client certificate (or lack thereof) can be conveyed by selecting response content as appropriate or with an HTTP 403 response, if the certificate is deemed unacceptable for the given context.  Note that TLS clients that rely on error indications at the TLS layer for an unacceptable certificate will not receive those signals. </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),
field, it SHOULD prevent the user agent from caching the response by transforming the value of the "Vary" response header field to "*". <ins> Forward proxies and other intermediaries MUST NOT add the "Client- 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. </ins> 3. 3.1. If the client certificate header field is generated by an intermediary on a connection that compresses fields (e.g., using <del> 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. </del> <ins> HPACK HPACK or QPACK 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. </ins> 3.2.
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. <del> 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. </del> <ins> HTTP/2 RFC9113 or HTTP/3 RFC9114) should account for the additional size of the 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. </ins> 3.3.
field, it SHOULD prevent the user agent from caching the response by transforming the value of the "Vary" response header field to "*". <ins> Forward proxies and other intermediaries MUST NOT add the "Client- 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. </ins> 3. 3.1.
The value of the header is encoded as described in encoding. The "Client-Cert" header field is only for use in HTTP requests and <del> MUST NOT be used in HTTP responses.  It is a single HTTP header field value as defined in Section 3.2 of RFC7230, which MUST NOT have a </del> <ins> MUST NOT be used in HTTP responses.  It is a singleton header field value as defined in Section 5.5 of RFC9110, which MUST NOT have a </ins> list of values or occur multiple times in a request. 2.3. In the context of a TLS terminating reverse proxy deployment, the <del> proxy MAY make the certificate chain used for validation of the end- entity certificate available to the backend application with the Client-Cert-Chain HTTP header field.  This field contains certificates used by the proxy to validate the certificate used by the client in the TLS handshake.  These certificates might or might not have been provided by the client during the TLS handshake. </del> <ins> proxy MAY make the certificate chain available to the backend application with the Client-Cert-Chain HTTP header field. </ins> Client-Cert-Chain is a List Structured Header RFC8941.  Each item in the list MUST be a Byte Sequence (RFC8941) encoded as described in <del> encoding. </del> <ins> encoding.  The order is the same as the ordering in TLS (such as described in TLS). </ins> The header's ABNF is:
purposes, it might be advantageous to split lists into multiple instances. <del> The first certificate in the list SHOULD directly certify the end- entity certificate provided in the "Client-Cert" header; each following certificate SHOULD directly certify the one immediately preceding it.  Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that the server is known to possess any omitted certificates. However, for maximum compatibility, servers SHOULD be prepared to handle potentially extraneous certificates and arbitrary orderings. </del> 2.4. This section outlines the applicable processing rules for a TLS
The QUERY method is subject to the same general security considerations as all HTTP methods as described in HTTP. <del> The QUERY method can be used as an alternative to passing query information in the query portion of a URI.  This is preferred in some cases, as the URI is more likely to be logged than the request content.  If a server creates a temporary resource to represent the results of a QUERY request (e.g., for use in the Location or Content- Location field) and the request contains sensitive information that cannot be logged, then the URI of this resource SHOULD be chosen such that it does not include any sensitive portions of the original request content. </del> <ins> The QUERY method can be used as an alternative to passing request information in the URI (e.g., in the query section).  This is preferred in some cases, as the URI is more likely to be logged or otherwise processed by intermediaries than the request content.  If a server creates a temporary resource to represent the results of a QUERY request (e.g., for use in the Location or Content-Location field) and the request contains sensitive information that cannot be logged, then the URI of this resource SHOULD be chosen such that it does not include any sensitive portions of the original request content. </ins> 6.
Authorization field be covered to protect the authorization credentials and mandate the signature parameters contain a "created" parameter, while an API expecting semantically relevant <del> HTTP message content could require the Content-Digest header to be present and covered as well as mandate a value for "tag" that is specific to the API being protected. </del> <ins> HTTP message content could require the Content-Digest header defined in DIGEST to be present and covered as well as mandate a value for "tag" that is specific to the API being protected. </ins> A means of retrieving the key material used to verify the signature.  An application will usually use the "keyid" parameter
The "Client-Cert" header field is only for use in HTTP requests and MUST NOT be used in HTTP responses.  It is a singleton header field <del> value as defined in Section 5.5 of RFC9110, which MUST NOT have a list of values or occur multiple times in a request. </del> <ins> value as defined in RFC9110, which MUST NOT have a list of values or occur multiple times in a request. </ins> 2.3.
commonly occurring functionality could improve and simplify interoperability between independent implementations. <del> 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 </del> <ins> This document describes 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 </ins> certificate that was presented by the originating client in its connection to the TTRP.
application requirements.  In order for these types of application deployments to work in practice, the reverse proxy needs to convey information about the client certificate to the origin application <del> server.  A common way this information is conveyed in practice today is by using non-standard fields to carry the certificate (in some encoding) or individual parts thereof in the HTTP request that is dispatched to the origin server.  This solution works but </del> <ins> server.  At the time of writing, a common way this information is conveyed is by using non-standard fields to carry the certificate (in some encoding) or individual parts thereof in the HTTP request that is dispatched to the origin server.  This solution works but </ins> interoperability between independently developed components can be cumbersome or even impossible depending on the implementation choices respectively made (like what field names are used or are
3.1. <del> If the client certificate header field is generated by an intermediary on a connection that compresses fields (e.g., using HPACK HPACK or QPACK 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. </del> <ins> If the connection between the TTRP and origin is capable of field compression (e.g., HPACK HPACK or QPACK QPACK), and the TTRP multiplexes more than one client's requests into that connection, the size and variation of "Client-Cert" and "Client-Cert-Chain" field values can reduce compression efficiency significantly.  An origin could mitigate the efficiency loss by increasing the size of the dynamic table.  If the TTRP determines that the origin dynamic table is not sufficiently large, it may find it beneficial to always send the field value as a literal, rather than entering it into the table. </ins> 3.2.
3.2. <del> A server in receipt of a larger header block than it is willing to </del> <ins> A server in receipt of a larger message header than it is willing to </ins> 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 <del> 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 RFC9113 or HTTP/3 RFC9114) should account for the additional size of the 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. </del> <ins> allow for a larger maximum header size.  An intermediary generating client certificate header fields on connections that allow for advertising the maximum acceptable header size (e.g.  HTTP/2 RFC9113 or HTTP/3 RFC9114) should account for the additional size of the header 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. </ins> 3.3.
deployments.  The communication between a TTRP and backend or origin server, for example, might be authenticated in some way with the insertion and consumption of the "Client-Cert" and "Client-Cert- <del> Chain" header fields occurring only on that connection. Alternatively the network topology might dictate a private network such that the backend application is only able to accept requests from the TTRP and the proxy can only make requests to that server. Other deployments that meet the requirements set forth herein are also possible. </del> <ins> Chain" header fields occurring only on that connection.  I-D.ietf- httpbis-message-signatures gives one example of this with an application of HTTP Message Signatures.  Alternatively the network topology might dictate a private network such that the backend application is only able to accept requests from the TTRP and the proxy can only make requests to that server.  Other deployments that meet the requirements set forth herein are also possible. </ins> 5.
2.1. <del> The headers in this document encode certificates as Structured Field Byte Sequences (RFC8941) where the value of the binary data is a DER encoded ITU.X690.1994 X.509 certificate RFC5280.  In effect, this means that the binary DER certificate is encoded using base64 (without line breaks, spaces, or other characters outside the base64 alphabet) and delimited with colons on either side. </del> <ins> The headers in this document encode certificates as Byte Sequences (RFC8941) where the value of the binary data is a DER encoded ITU.X690.1994 X.509 certificate RFC5280.  In effect, this means that the binary DER certificate is encoded using base64 (without line breaks, spaces, or other characters outside the base64 alphabet) and delimited with colons on either side. </ins> Note that certificates are often stored encoded in a textual format, such as the one described in RFC7468, which is already nearly <del> compatible with a Structured Field Byte Sequence; if so, it will be sufficient to replace "---(BEGIN|END) CERTIFICATE---" with ":" and remove line breaks in order to generate an appropriate item. </del> <ins> compatible with a Byte Sequence; if so, it will be sufficient to replace "---(BEGIN|END) CERTIFICATE---" with ":" and remove line breaks in order to generate an appropriate item. </ins> 2.2.
contains the end-entity certificate used by the client in the TLS handshake. <del> Client-Cert is an Item Structured Header RFC8941.  Its value MUST be a Byte Sequence (RFC8941).  Its ABNF is: The value of the header is encoded as described in encoding. </del> <ins> Client-Cert is a Byte Sequence with the value of the header encoded as described in encoding. </ins> The "Client-Cert" header field is only for use in HTTP requests and MUST NOT be used in HTTP responses.  It is a singleton header field
proxy MAY make the certificate chain available to the backend application with the Client-Cert-Chain HTTP header field. <del> Client-Cert-Chain is a List Structured Header RFC8941.  Each item in the list MUST be a Byte Sequence (RFC8941) encoded as described in encoding.  The order is the same as the ordering in TLS (such as described in TLS). The header's ABNF is: </del> <ins> Client-Cert-Chain is a List (RFC8941).  Each item in the list MUST be a Byte Sequence encoded as described in encoding.  The order is the same as the ordering in TLS (such as described in TLS). </ins> The "Client-Cert-Chain" header field is only for use in HTTP requests and MUST NOT be used in HTTP responses.  It MAY have a list of values
For example, given the following message: <del> ```http-message HTTP/1.1 200 OK Content-Type: text/plain Transfer- Encoding: chunked Trailer: Expires 4 HTTP 7 Message 10 Signatures 0 Expires: Wed, 9 Nov 2022 07:28:00 GMT ``` </del> The signer decides to add both the Trailer header field as well as <del> the Expires trailer to the signature base: ""@status": 200 "trailer": Expires "expires";tr: Wed, 9 Nov 2022 07:28:00 GMT " </del> <ins> the Expires trailer to the signature base, along with the status code derived component: </ins> <del> IF a field is available as both a header and trailer in a message, both values MAY be signed separately.  The values of header fields and trailer fields of the same name MUST NOT be combined. </del> <ins> If a field is available as both a header and trailer in a message, both values MAY be signed, but the values MUST be signed separately. The values of header fields and trailer fields of the same name MUST NOT be combined for purposes of the signature. </ins> Since trailer fields could be merged into the header fields or dropped entirely by intermediaries as per HTTP, it is NOT RECOMMENDED
CertificateVerify and Finished messages. HTTP/2 restricts TLS 1.2 renegotiation (RFC9113) and prohibits TLS <del> 1.3 post-handshake authentication RFC8740.  However, they are </del> <ins> 1.3 post-handshake authentication (RFC9113).  However, they are </ins> sometimes used to implement reactive client certificate authentication in HTTP/1.1 RFC9112 where the server decides whether to request a client certificate based on the HTTP request.  HTTP
enabled. A TTRP negotiates the use of a mutually-authenticated TLS connection <del> with the client, such as is described in TLS or RFC5246, and validates the client certificate per its policy and trusted certificate authorities.  Each HTTP request on the underlying TLS connection are dispatched to the origin server with the following modifications: </del> <ins> with the client, such as is described in TLS or TLS1.2, and validates the client certificate per its policy and trusted certificate authorities.  Each HTTP request on the underlying TLS connection are dispatched to the origin server with the following modifications: </ins> The client certificate is placed in the "Client-Cert" header field of the dispatched request, as described in header.
indicates that proxy.example.net, which used the IP address "2001:db8::1" as the next hop for this request, encountered the <del> CNAMEs "tracker.example.com." and "service1.example-cdn.com" in the </del> <ins> CNAMEs "tracker.example.com" and "service1.example-cdn.com" in the </ins> DNS resolution chain.  Note that while this example includes both the "next-hop" and "next-hop-aliases" parameters, "next-hop-aliases" can be included without including "next-hop".
1. Existing RFCs define extensions to HTTP/2 HTTP2 which remain useful <del> in HTTP/3.  Section A.2.3 of HTTP3 describes the required updates for HTTP/2 frames to be used with HTTP/3. </del> <ins> in HTTP/3.  HTTP3 describes the required updates for HTTP/2 frames to be used with HTTP/3. </ins> ORIGIN defines the HTTP/2 ORIGIN frame, which indicates what origins are available on a given connection.  It defines a single HTTP/2 frame type. <ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. Frame diagrams in this document use the format defined in QUIC- TRANSPORT to illustrate the order and size of fields. </ins> 2. The ORIGIN HTTP/3 frame allows a server to indicate what origin(s) (RFC6454) the server would like the client to consider as members of <del> the Origin Set (Section 2.3 of ORIGIN) for the connection within which it occurs. </del> <ins> the Origin Set (ORIGIN) for the connection within which it occurs. </ins> The semantics of the frame payload are identical to those of the HTTP/2 frame defined in ORIGIN.  Where HTTP/2 reserves Stream 0 for
An Origin-Entry is a length-delimited string.  Specifically, it contains two fields: <del> An unsigned, 16-bit integer indicating the length, in octets, of the ASCII-Origin field. An OPTIONAL sequence of characters containing the ASCII serialization of an origin (RFC6454, Section 6.2) that the sender asserts this connection is or could be authoritative for. </del> 3. This document introduces no new security considerations beyond those
chain of aliases encountered during DNS resolution when connecting to the next hop. <del> Knowing the full chain of aliases that were used during DNS resolution is particularly useful for clients of forward proxies, in which the client is requesting to connect to a specific target hostname using the CONNECT method HTTP or UDP proxying CONNECT-UDP. DNS aliases can be used to "cloak" hosts that perform tracking or malicious activity behind more innocuous hostnames, and clients such as web browsers use the chain of DNS aliases to influence behavior like cookie usage policies COOKIES or blocking of malicious hosts. This document allows clients to receive the chain of DNS aliases for the next hop by including the list of names in a new "next-hop- </del> <ins> Knowing the full chain of names that were used during DNS resolution via CNAME records DNS is particularly useful for clients of forward proxies, in which the client is requesting to connect to a specific target hostname using the CONNECT method HTTP or UDP proxying CONNECT-UDP.  CNAME records can be used to "cloak" hosts that perform tracking or malicious activity behind more innocuous hostnames, and clients such as web browsers use the chain of DNS names to influence behavior like cookie usage policies COOKIES or blocking of malicious hosts. This document allows clients to receive the CNAME chain of DNS names for the next hop by including the list of names in a new "next-hop- </ins> aliases" Proxy-Status parameter. 1.1.