jiebi/CodeConvo huggingface dataset:
MUST either be represented as a quoted string, or MUST NOT include ";" or "," in the character sets used for the encoding. <del> 3.1. A representation digest is the value of the output of a digest algorithm, together with an indication of the algorithm used (and any parameters). As explained in resource-representation the digest is computed on the entire selected "representation data" of the resource defined in RFC7231: The encoded digest output uses the encoding format defined for the specific digest-algorithm. 3.1.1. The "sha-256" digest-algorithm uses base64 encoding.  Note that digest-algorithm values are case insensitive. The "UNIXsum" digest-algorithm uses ASCII string of decimal digits. 4. The Want-Digest message header field indicates the sender's desire to receive a representation digest on messages associated with the request URI and representation metadata. If a digest-algorithm is not accompanied by a qvalue, it is treated as if its associated qvalue were 1.0. The sender is willing to accept a digest-algorithm if and only if it is listed in a Want-Digest header field of a message, and its qvalue is non-zero. If multiple acceptable digest-algorithm values are given, the sender's preferred digest-algorithm is the one (or ones) with the highest qvalue. Two examples of its use are 5. The Digest header field provides a digest of the representation data. "Representation data" might be: fully contained in the message body, partially-contained in the message body, or not at all contained in the message body. The resource is specified by the effective request URI and any "validator" contained in the message. For example, in a response to a HEAD request, the digest is calculated using the representation data that would have been enclosed in the payload body if the same request had been a GET. Digest can be used in requests too. The "Digest" value depends on the representation metadata. A Digest header field MAY contain multiple representation-data-digest values.  This could be useful for responses expected to reside in caches shared by users with different browsers, for example. A recipient MAY ignore any or all of the representation-data-digests in a Digest header field.  This allows the recipient to chose which digest-algorithm(s) to use for validation instead of verifying every received representation-data-digest. A sender MAY send a representation-data-digest using a digest- algorithm without knowing whether the recipient supports the digest- algorithm, or even knowing that the recipient will ignore it. Two examples of its use are </del> 6. POST and PATCH requests may appear to convey partial representations
3. <del> The Digest header field provides a digest of the representation data. </del> <ins> The Digest header field contains a list of one or more representation digest values as defined in representation-digest.  It can be used in both request and response. </ins> The resource is specified by the effective request URI and any "validator" contained in the message. <del> For example, in a response to a HEAD request, the digest is calculated using the representation data that would have been enclosed in the payload body if the same request had been a GET. Digest can be used in requests too. The "Digest" value depends on the representation metadata. </del> <ins> See post-not-request-uri for an example of how digest relates to header fields such as Content-Location (see RFC7231 Section 3.1.4.2) while a comprehensive set of examples showing the impacts of representation metadata, payload transformations and HTTP methods on digest is provided in examples-solicited and examples-unsolicited. </ins> A Digest header field MAY contain multiple representation-data-digest values.  This could be useful for responses expected to reside in
strings beginning with the letter "Q".  Likewise, Inner Lists are only valid when a field definition explicitly allows them. <del> When parsing fails, the field is ignored (see text-parse); in most situations, violating field-specific constraints should have the same effect.  Thus, if a header is defined as an Item and required to be an Integer, but a String is received, it will by default be ignored. If the field requires different error handling, this should be explicitly specified. However, both Items and Inner Lists allow parameters as an extensibility mechanism; this means that values can later be extended to accommodate more information, if need be.  As a result, field specifications are discouraged from defining the presence of an unrecognized Parameter as an error condition. To help assure that this extensibility is available in the future, </del> <ins> When parsing fails, the entire field is ignored (see text-parse); in most situations, violating field-specific constraints should have the same effect.  Thus, if a header is defined as an Item and required to be an Integer, but a String is received, the field will by default be ignored.  If the field requires different error handling, this should be explicitly specified. Both Items and Inner Lists allow parameters as an extensibility mechanism; this means that values can later be extended to accommodate more information, if need be.  To preserve forward compatibility, field specifications are discouraged from defining the presence of an unrecognized Parameter as an error condition. To further assure that this extensibility is available in the future, </ins> and to encourage consumers to use a complete parser implementation, a field definition can specify that "grease" Parameters be added by <del> senders.  For example, a specification could stipulate that all Parameters beginning with the letter "h" are reserved for this use, and then encourage them to be sent on some portion of requests.  This helps to discourage recipients from writing a parser that does not account for Parameters. Note that a field definition cannot relax the requirements of this </del> <ins> senders.  A specification could stipulate that all Parameters that fit a defined pattern are reserved for this use and then encourage them to be sent on some portion of requests.  This helps to discourage recipients from writing a parser that does not account for Parameters. Specifications that use Dictionaries can also allow for forward compatibility by requiring that the presence of - as well as value and type associated with - unknown members be ignored.  Later specifications can then add additional members, specifying constraints on them as appropriate. An extension to a structured field can then require that an entire field value be ignored by a recipient that understands the extension if constraints on the value it defines are not met. A field definition cannot relax the requirements of this </ins> specification because doing so would preclude handling by generic software; they can only add additional constraints (for example, on the numeric range of Integers and Decimals, the format of Strings and
Such features SHOULD take into account the following aspects of the information exposed: <del> Exposing highly granular data can be used to help identify users across multiple requests to different origins.  Reducing the set of header field values that can be expressed, or restricting them to an enumerated range where the advertised value is close but is not an exact representation of the current value, can improve privacy and reduce risk of linkability by ensuring that the same value is sent by multiple users. The feature SHOULD NOT expose user sensitive information.  To that end, information available to the application, but gated behind specific user actions (e.g. a permission prompt or user activation) SHOULD NOT be exposed as a Client Hint. The feature SHOULD NOT expose user information that changes over time, unless the state change itself is also exposed (e.g. through JavaScript callbacks). </del> <ins> Entropy - Exposing highly granular data can be used to help identify users across multiple requests to different origins. Reducing the set of header field values that can be expressed, or restricting them to an enumerated range where the advertised value is close but is not an exact representation of the current value, can improve privacy and reduce risk of linkability by ensuring that the same value is sent by multiple users. Sensitivity - The feature SHOULD NOT expose user sensitive information.  To that end, information available to the application, but gated behind specific user actions (e.g. a permission prompt or user activation) SHOULD NOT be exposed as a Client Hint. Change over time - The feature SHOULD NOT expose user information that changes over time, unless the state change itself is also exposed (e.g. through JavaScript callbacks). </ins> Different features will be positioned in different points in the space between low-entropy, non-sensitive and static information (e.g.
Specification document(s): accept-ch of this document Related information: for Client Hints <del> 7. </del> <ins> 7.  References </ins> <del> 7.1. Issue 168 (make Save-Data extensible) updated ABNF. Issue 163 (CH review feedback) editorial feedback from httpwg list. Issue 153 (NetInfo API citation) added normative reference. 7.2. Issue 200: Moved Key reference to informative. Issue 215: Extended passive fingerprinting and mitigation considerations. Changed document status to experimental. 7.3. Issue 239: Updated reference to CR-css-values-3 Issue 240: Updated reference for Network Information API Issue 241: Consistency in IANA considerations Issue 250: Clarified Accept-CH 7.4. Issue 284: Extended guidance for Accept-CH Issue 308: Editorial cleanup Issue 306: Define Accept-CH-Lifetime 7.5. Issue 361: Removed Downlink Issue 361: Moved Key to appendix, plus other editorial feedback 7.6. Issue 372: Scoped CH opt-in and delivery to secure transports Issue 373: Bind CH opt-in to origin 7.7. Issue 524: Save-Data is now defined by NetInfo spec, dropping PR 775: Removed specific features to be defined in other specifications 7.8. Issue 761: Clarified that the defined headers are response headers. Issue 730: Replaced Key reference with Variants. Issue 700: Replaced ABNF with structured headers. PR 878: Removed Accept-CH-Lifetime based on feedback at IETF 105 7.9. PR 985: Describe the bytesize cost of hints. PR 776: Add Sec- and CH- prefix considerations. PR 1001: Clear CH persistence when cookies are cleared. 7.10. PR 1064: Fix merge issues with "cost of sending hints". 7.11. PR 1072: LC feedback from Julian Reschke. PR 1080: Improve list style. PR 1082: Remove section mentioning Variants. PR 1097: Editorial feedback from mnot. PR 1131: Remove unused references. PR 1132: Remove nested list. 8.  References 8.1.  URIs </del> <ins> 7.1.  URIs </ins> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/
in this document are to be interpreted as described in I-D.ietf- httpbis-semantics. <del> The definition "validator" in this document is to be interpreted as described in Section 10.2 of I-D.ietf-httpbis-semantics. </del> <ins> The definition "validator fields" in this document is to be interpreted as described in Section 10.2 of I-D.ietf-httpbis- semantics. </ins> 2.
Serialize the cookie-list into a cookie-string by processing each cookie in the cookie-list in order: <del> Output the cookie's name, the %x3D ("=") character, and the cookie's value. </del> <ins> If the cookies' name is not empty, output the cookie's name followed by the %x3D ("=") character. If the cookies' value is not empty, output the cookie's value. </ins> If there is an unprocessed cookie in the cookie-list, output the characters %x3B and %x20 ("; ").
This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle <del> HTTP header and trailer fields, known as "Structured Fields", or "Structured Headers".  It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. </del> <ins> HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers".  It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. </ins> Note to Readers
Clients and servers that will accept requests for HTTP-layer certificate authentication indicate this using the HTTP/2 <del> "SETTINGS_HTTP_CERT_AUTH" (0xSETTING-TBD) setting. The initial value for the "SETTINGS_HTTP_CERT_AUTH" setting is 0, indicating that the peer does not support HTTP-layer certificate authentication.  If a peer does support HTTP-layer certificate authentication, the value is non-zero. </del> <ins> "SETTINGS_HTTP_CLIENT_CERT_AUTH" (0xSETTING-TBD1) and "SETTINGS_HTTP_SERVER_CERT_AUTH" (0xSETTING-TBD2) settings. The initial value for both settings is 0, indicating that the peer does not support HTTP-layer certificate authentication.  If a peer does support HTTP-layer certificate authentication, one or both of the values is non-zero.  "SETTINGS_HTTP_CLIENT_CERT_AUTH" indicates that servers can use certificates for client authentication, while "SETTINGS_HTTP_SERVER_CERT_AUTH" indicates that servers are able to offer additional certificates to demonstrate control over other origin hostnames. </ins> In order to ensure that the TLS connection is direct to the server, rather than via a TLS-terminating proxy, each side will separately <del> compute and confirm the value of this setting.  The setting is derived from a TLS exporter (see Section 7.5 of RFC8446 and RFC5705 for more details on exporters).  Clients MUST NOT use an early exporter during their 0-RTT flight, but MUST send an updated SETTINGS frame using a regular exporter after the TLS handshake completes. </del> <ins> compute and confirm the value of these settings.  The setting values are derived from a TLS exporter (see Section 7.5 of RFC8446 and RFC5705 for more details on exporters).  Clients MUST NOT use an early exporter during their 0-RTT flight, but MUST send an updated SETTINGS frame using a regular exporter after the TLS handshake completes. </ins> The exporter is constructed with the following input:
Context: Empty <del> Length: Four bytes </del> <ins> Length: Eight bytes The value of the exporter is split into two four-byte values.  The first four bytes are used for the "SETTINGS_HTTP_CLIENT_CERT_AUTH" value, while the following four bytes are used for the "SETTINGS_HTTP_SERVER_CERT_AUTH" value. </ins> <del> The resulting exporter is converted to a setting value as: </del> <ins> Each is converted to a setting value as: </ins> That is, the most significant bit will always be set, regardless of the value of the exporter.  Each endpoint will compute the expected <del> value from their peer.  If the setting is not received, or if the </del> <ins> values from their peer.  If the setting is not received, or if the </ins> value received is not the expected value, the frames defined in this <del> document SHOULD NOT be sent. </del> <ins> document SHOULD NOT be sent in the indicated direction. </ins> 2.2. When both peers have advertised support for HTTP-layer certificates <del> as in setting, either party can supply additional certificates into the connection at any time.  This means that clients or servers which predict a certificate will be required could supply the certificate before being asked.  These certificates are available for reference by future "USE_CERTIFICATE" frames. </del> <ins> in a given direction as in setting, the indicated endpoint can supply additional certificates into the connection at any time.  That is, if both endpoints have sent "SETTINGS_HTTP_SERVER_CERT_AUTH" and validated the value received from the peer, the server may send certificates.  If both endpoints have sent "SETTINGS_HTTP_CLIENT_CERT_AUTH" and validated the value received from the peer, the client may send certificates. Implementations which predict a certificate will be required could supply the certificate before being asked.  These certificates are available for reference by future "USE_CERTIFICATE" frames. </ins> Certificates supplied by servers can be considered by clients without further action by the server.  A server SHOULD NOT send certificates
current connection, but MAY use the ORIGIN frame RFC8336 to indicate that not all covered origins will be served. <del> Likewise, either party can supply a "CERTIFICATE_REQUEST" that outlines parameters of a certificate they might request in the future.  Upon receipt of a "CERTIFICATE_REQUEST", endpoints SHOULD provide a corresponding certificate in anticipation of a request shortly being blocked.  Clients MAY wait for a "CERTIFICATE_NEEDED" frame to assist in associating the certificate request with a particular HTTP transaction. </del> <ins> Likewise, a party can supply a "CERTIFICATE_REQUEST" that outlines parameters of a certificate they might request in the future.  Upon receipt of a "CERTIFICATE_REQUEST", endpoints SHOULD provide a corresponding certificate in anticipation of a request shortly being blocked.  Clients MAY wait for a "CERTIFICATE_NEEDED" frame to assist in associating the certificate request with a particular HTTP transaction. </ins> 2.3.
If the TLS certificate does not contain the new origin, but the server has claimed support for that origin (with an ORIGIN frame, see <del> RFC8336) and advertised support for HTTP-layer certificates (see setting), the client MAY send a "CERTIFICATE_REQUEST" frame </del> <ins> RFC8336) and advertised support for HTTP-layer server certificates (see setting), the client MAY send a "CERTIFICATE_REQUEST" frame </ins> describing the desired origin.  The client then sends a "CERTIFICATE_NEEDED" frame for stream zero referencing the request, indicating that the connection cannot be used for that origin until
stream zero.  Multiple "CERTIFICATE_NEEDED" frames on any other stream MUST be considered a stream error of type "PROTOCOL_ERROR". <del> The "CERTIFICATE_NEEDED" frame MUST NOT be sent to a peer which has not advertised support for HTTP-layer certificate authentication. </del> <ins> The "CERTIFICATE_NEEDED" frame MUST NOT be sent to a client which has not advertised the "SETTINGS_HTTP_CLIENT_CERT_AUTH", or to a server which has not advertised the "SETTINGS_HTTP_SERVER_CERT_AUTH" setting. </ins> The "CERTIFICATE_NEEDED" frame MUST NOT reference a stream in the "half-closed (local)" or "closed" states RFC7540.  A client that
to a request that has not yet been received, servers SHOULD cache the indication briefly in anticipation of the request. <del> Receipt of more than one unsolicited "USE_CERTIFICATE" frames or an </del> <ins> Receipt of more than one unsolicited "USE_CERTIFICATE" frame or an </ins> unsolicited "USE_CERTIFICATE" frame which is not the first in reference to a given stream MUST be treated as a stream error of type "CERTIFICATE_OVERUSED".
specifies a desired certificate.  This describes the certificate the sender wishes to have presented. <del> The "CERTIFICATE_REQUEST" frame SHOULD NOT be sent to a peer which has not advertised support for HTTP-layer certificate authentication. </del> <ins> The "CERTIFICATE_REQUEST" frame SHOULD NOT be sent to a client which has not advertised the "SETTINGS_HTTP_CLIENT_CERT_AUTH", or to a server which has not advertised the "SETTINGS_HTTP_SERVER_CERT_AUTH" setting. </ins> The "CERTIFICATE_REQUEST" frame MUST be sent on stream zero.  A "CERTIFICATE_REQUEST" frame received on any other stream MUST be
This draft adds entries in three registries. <del> The HTTP/2 "SETTINGS_HTTP_CERT_AUTH" setting is registered in iana- setting.  Four frame types are registered in iana-frame.  Six error codes are registered in iana-errors. </del> <ins> The feature negotiation settings is registered in iana-setting.  Four frame types are registered in iana-frame.  Six error codes are registered in iana-errors. </ins> 7.1. <del> The SETTINGS_HTTP_CERT_AUTH setting is registered in the "HTTP/2 Settings" registry established in RFC7540. SETTINGS_HTTP_CERT_AUTH 0xSETTING-TBD 0 This document. </del> <ins> The SETTINGS_HTTP_CLIENT_CERT_AUTH and SETTINGS_HTTP_SERVER_CERT_AUTH settings are registered in the "HTTP/2 Settings" registry established in RFC7540. </ins> 7.2.
Empty Authenticator, as described in Section 5 of I-D.ietf-tls- exported-authenticator, in a "CERTIFICATE" frame in response to the request, followed by a "USE_CERTIFICATE" frame for stream zero which <del> references the Empty Authenticator.  In this case, or if the server has not advertised support for HTTP-layer certificates, the client MUST NOT send any requests for resources in that origin on the current connection. </del> <ins> references the Empty Authenticator. If a server has not advertised support for HTTP-layer certificates, fails to provide a requested certificate, or provides a certificate which is unacceptable to the client, the client MUST NOT send any requests for resources in that origin on the current connection.  The client MAY open a new connection in an effort to reach an authoritative server. </ins> If a client receives a "PUSH_PROMISE" referencing an origin for which <del> it has not yet received the server's certificate, this is a fatal connection error (see section 8.2 of RFC7540).  To avoid this, servers MUST supply the associated certificates before pushing resources from a different origin. </del> <ins> it has not yet received the server's certificate, this is a stream error (see section 8.2 of RFC7540).  To avoid this, servers MUST supply the associated certificates before pushing resources from a different origin. </ins> 2.3.2.
an Empty Authenticator, as described in Section 5 of I-D.ietf-tls- exported-authenticator, in a "CERTIFICATE" frame in response to the request, followed by a "USE_CERTIFICATE" frame which references the <del> Empty Authenticator.  In this case, or if the client has not advertised support for HTTP-layer certificates, the server processes the request based solely on the certificate provided during the TLS handshake, if any.  This might result in an error response via HTTP, such as a status code 403 (Not Authorized). </del> <ins> Empty Authenticator. If the client has not advertised support for HTTP-layer certificates, fails to provide a requested certificate, or provides a certificate the server is unable to verify, the server processes the request based solely on the certificate provided during the TLS handshake, if any.  This might result in an error response via HTTP, such as a status code 403 (Not Authorized). </ins> 3.
The "CERTIFICATE_NEEDED" frame MUST NOT be sent to a client which has not advertised the "SETTINGS_HTTP_CLIENT_CERT_AUTH", or to a server which has not advertised the "SETTINGS_HTTP_SERVER_CERT_AUTH" <del> setting. </del> <ins> setting.  An endpoint which receives a "CERTIFICATE_NEEDED" frame but did not advertise support MAY treat this as a connection error of type "CERTIFICATE_WITHOUT_CONSENT". </ins> The "CERTIFICATE_NEEDED" frame MUST NOT reference a stream in the "half-closed (local)" or "closed" states RFC7540.  A client that