jiebi/CodeConvo huggingface dataset:
Structured Field (a Dictionary), respectively. In each case, cookie names are Tokens.  Their values are Strings, <del> unless they can be represented accurately and unambiguously using the textual representation of another structured types (e.g., an Integer or Decimal). </del> <ins> unless the value can be successfully parsed as the textual representation of another, bare Item structured type (e.g., Byte Sequence, Decimal, Integer, Token, or Boolean). </ins> Set-Cookie parameters map to Parameters on the appropriate SF-Set- Cookie member, with the parameter name being forced to lowercase.
that use different grammatical notations than this document (which uses ABNF from RFC5234). <ins> NOTE: The name of an attribute-value pair is not case sensitive.  So while they are presented here in CamelCase, such as "HttpOnly" or "SameSite", any case is accepted.  E.x.: "httponly", "Httponly", "hTTPoNLY", etc. </ins> The semantics of the cookie-value are not defined by this document. To maximize compatibility with user agents, servers that wish to
For example, the Date HTTP header field carries a date: <del> Its value is more efficiently represented as an Integer number of delta seconds from the Unix epoch (00:00:00 UTC on 1 January 1970, minus leap seconds).  Thus, the example above would be mapped to: </del> <ins> Its value would be mapped to: </ins> As in compatible, these fields are unable to carry values that are not valid Structured Fields, and so an application using this
have values that can be mapped into Structured Fields by parsing their payload according to HTTP and representing the result as an Integer number of seconds delta from the Unix Epoch (00:00:00 UTC on <del> 1 January 1970, excluding leap seconds). </del> <ins> 1 January 1970, excluding leap seconds), using the Date Structured Fields data type defined in date-type. </ins> For example, an Expires field could be mapped as:
specification defines types for existing cookie attributes in cookie- params. <del> The Expires attribute is mapped to an Integer representation of parsed-cookie-date (see COOKIES) expressed as a number of seconds delta from the Unix Epoch (00:00:00 UTC on 1 January 1970, excluding leap seconds). </del> <ins> The Expires attribute is mapped to a Date representation of parsed- cookie-date (see COOKIES). </ins> For example, these unstructured fields:
inputs.  However, the canonicalized component value is never parsed by the message signature process, merely used as part of the signature base in create-sig-input.  Even so, caution needs to be <del> taken when including such fields in signatures, see security-non-list for more discussion of this issue. </del> <ins> taken when including such fields in signatures, and the "bs" parameter defined in http-header-byte-sequence provides a method for wrapping such problematic fields.  See security-non-list for more discussion of this issue. </ins> If the combined value is not available for a given header, the following algorithm will produce canonicalized results for an
parameters in specific circumstances, each described in detail in their own sections: <ins> Multiple parameters MAY be specified together, though some combinations are redundant or incompatible.  For example, the "sf" parameter's functionality is already covered when the "key" parameter is used on a dictionary item.  The "bs" parameter, which requires the raw field values from the message, is not compatible with use of the "sf" or "key" parameters, which require the parsed data structures of the field values after combination. </ins> Additional parameters MAY be defined in a registry established in param-registry. 2.1.1. If the value of the the HTTP field in question is known by the <del> application to be a structured field (STRUCTURED-FIELDS), the component identifier MAY include the "sf" parameter to indicate it is a known structured field.  If this parameter is included with a component identifier, the HTTP field value MUST be serialized using the rules specified in STRUCTURED-FIELDS applicable to the type of the HTTP field.  Note that this process will replace any optional internal whitespace with a single space character, among other potential transformations of the value. </del> <ins> application to be a structured field (STRUCTURED-FIELDS), and the expected type of the structured field is known, the signer MAY include the "sf" parameter in the component identifier.  If this parameter is included with a component identifier, the HTTP field value MUST be serialized using the rules specified in STRUCTURED- FIELDS applicable to the type of the HTTP field.  Note that this process will replace any optional internal whitespace with a single space character, among other potential transformations of the value. Processing of this parameter MUST occur after multiple field values have been combined into a single List or Dictionary structure. </ins> For example, the following dictionary field is a valid serialization:
Note that the value for "key="c"" has been re-serialized according to the strict "member_value" algorithm. <ins> 2.1.3. If the value of the the HTTP field in question is known by the application to cause problems with serialization, particularly with combination of multiple values as discussed in security-non-list, the signer MAY include the "bs" parameter in a component identifier to indicate the values of the fields need to be wrapped as binary structures before being combined. If this parameter is included with a component identifier, the component value is calculated using the following algorithm: Let the input be the ordered set of values for a field For each field value in the set: Strip leading and trailing whitespace from each item in the list.  Note that since HTTP field values are not allowed to contain leading and trailing whitespace, this will be a no-op in a compliant implementation. Remove any obsolete line-folding within the line and replace it with a single space (" "), as discussed in HTTP1.  Note that this behavior is specific to HTTP1 and does not apply to other versions of the HTTP specification. Encode the string as a Byte Sequence Add the Byte Sequence to a List accumulator The intermediate result is a List of Byte Sequence values Follow the strict serialization of a List as described in STRUCTURED-FIELDS and return this output For example, the following field with internal commas prevents the distinct field values from being safely combined: If included in the signature base without parameters, its value would be: This is problematic because the same component value is created with the semantically distinct single field: However, if the "bs" parameter is added, the value is encoded and serialized as follows: For the single-instance field above, the encoding with the "bs" parameter is: This component value is distinct from the multiple-instance field above. </ins> 2.2. In addition to HTTP fields, there are a number of different
base by adding the "req" parameter to the component identifier. This parameter can be applied to both HTTP fields and derived <del> components with the same semantics.  The component value for a message component using this parameter is calculated in the same manner as it is normally, but data is pulled from the request message. </del> <ins> components that target the request, with the same semantics.  The component value for a message component using this parameter is calculated in the same manner as it is normally, but data is pulled from the request message instead of the target response message to which the signature is applied. </ins> Note that the same component name MAY be included with and without the "req" parameter in a single signature base, indicating the same
Since two semantically distinct inputs can create the same output in the signature base, special care has to be taken when handling such <del> values. </del> <ins> values.  Signers can make use of the "bs" parameter to armor such fields, as described in http-header-byte-sequence. </ins> Specifically, the Set-Cookie field COOKIE defines an internal syntax that does not conform to the List syntax in STRUCTURED-FIELDS.  In
This document is structured as follows: <del> content-digest defines the Content-Digest request and response header and trailer field, </del> <ins> New request and response header and trailer field definitions. </ins> <del> representation-digest defines the Repr-Digest request and response header and trailer field, </del> <ins> content-digest (Content-Digest), </ins> <del> want-fields defines the Want-Repr-Digest and Want-Content-Digest request and response header and trailer field, </del> <ins> representation-digest (Repr-Digest), and </ins> <del> algorithms describes algorithms and their relation to the fields defined in this document, </del> <ins> want-fields (Want-Content-Digest and Want-Repr-Digest). </ins> <del> state-changing-requests details computing representation digests, </del> <ins> Considerations specific to representation data integrity. </ins> <del> examples-unsolicited and examples-solicited provide examples of using Repr-Digest and Want-Repr-Digest. </del> <ins> state-changing-requests (State-changing requests), digest-and-content-location (Content-Location), resource-representation contains worked examples of Representation data in message exchanges, and examples-unsolicited and examples-solicited contain worked examples of Repr-Digest and Want-Repr-Digest fields in message exchanges. algorithms bootstraps a new IANA registry hash algorithms and defines registration procedures for future entries. </ins> 1.2.
If the attribute-name case-insensitively matches the string "Max- Age", the user agent MUST process the cookie-av as follows. <del> If the first character of the attribute-value is not a DIGIT or a "-" character, ignore the cookie-av. </del> <ins> If the attribute-value is empty, ignore the cookie-av. If the first character of the attribute-value is neither a DIGIT, nor a "-" character followed by a DIGIT, ignore the cookie-av. </ins> If the remainder of attribute-value contains a non-DIGIT character, ignore the cookie-av. <del> Let delta-seconds be the attribute-value converted to an integer. </del> <ins> Let delta-seconds be the attribute-value converted to a base 10 integer. </ins> Let cookie-age-limit be the maximum age of the cookie (which SHOULD be 400 days or less, see attribute-max-age).
that use different grammatical notations than this document (which uses ABNF from RFC5234). <del> NOTE: The name of an attribute-value pair is not case sensitive.  So while they are presented here in CamelCase, such as "HttpOnly" or "SameSite", any case is accepted.  E.x.: "httponly", "Httponly", "hTTPoNLY", etc. </del> <ins> Per the grammar above, servers SHOULD NOT produce nameless cookies (i.e.: an empty cookie-name) as such cookies may be unpredictably serialized by UAs when sent back to the server. </ins> The semantics of the cookie-value are not defined by this document.
store arbitrary data in a cookie-value SHOULD encode that data, for example, using Base64 RFC4648. <del> The domain-value is a subdomain as defined by RFC1034, Section 3.5, and as enhanced by RFC1123, Section 2.1.  Thus, domain-value is a string of USASCII characters, such as one obtained by applying the "ToASCII" operation defined in Section 4 of RFC3490. </del> Per the grammar above, the cookie-value MAY be wrapped in DQUOTE characters.  Note that in this case, the initial and trailing DQUOTE characters are not stripped.  They are part of the cookie-value, and will be included in Cookie header fields sent to the server. <ins> The domain-value is a subdomain as defined by RFC1034, Section 3.5, and as enhanced by RFC1123, Section 2.1.  Thus, domain-value is a string of USASCII characters, such as one obtained by applying the "ToASCII" operation defined in Section 4 of RFC3490. </ins> The portions of the set-cookie-string produced by the cookie-av term are known as attributes.  To maximize compatibility with user agents, servers SHOULD NOT produce two attributes with the same name in the same set-cookie-string.  (See storage-model for how user agents handle this case.) <ins> NOTE: The name of an attribute-value pair is not case sensitive.  So while they are presented here in CamelCase, such as "HttpOnly" or "SameSite", any case is accepted.  E.x.: "httponly", "Httponly", "hTTPoNLY", etc. </ins> Servers SHOULD NOT include more than one Set-Cookie header field in the same response with the same cookie-name.  (See set-cookie for how user agents handle this case.)
Signatures, an application or profile of this specification MUST specify all of the following items: <del> The set of covered-content that are expected and required to be included in the covered components list.  For example, an authorization protocol could mandate that the Authorization field be covered to protect the authorization credentials and mandate the signature parameters contain a "created" parameter, while an API expecting semantically relevant HTTP message content could require the Content-Digest header to be present and covered. </del> <ins> The set of covered-content and signature-params that are expected and required to be included in the covered components list.  For example, an authorization protocol could mandate that the Authorization field be covered to protect the authorization credentials and mandate the signature parameters contain a "created" parameter, while an API expecting semantically relevant HTTP message content could require the Content-Digest header to be present and covered as well as mandate a value for "context" 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
Requiring keys to be of a certain size (e.g., 2048 bits vs. 1024 bits). <del> Enforcing uniqueness of a "nonce" value. </del> <ins> Enforcing uniqueness of the "nonce" parameter. Requiring an application-specific value for the "context" parameter. </ins> Application-specific requirements are expected and encouraged.  When an application defines additional requirements, it MUST enforce them
padding attack would be rejected by the field value processor, even in the case where the attacker could force a signature collision. <ins> 7.25. Multiple applications and protocols could apply HTTP signatures on the same message simultaneously.  A naive verifier could become confused in processing multiple signatures, either accepting or rejecting a message based on an unrelated or irrelevant signature. In order to help an application select which signatures apply to its own processing, the application can declare a specific value for the "context" signature parameter.  For example, a signature targeting an application gateway could require "context="app-gateway"" as part of the signature parameters for that application. </ins> 8. 8.1.
the Origin Set (Section 2.3 of ORIGIN) for the connection within which it occurs. <del> Where HTTP/2 reserves Stream 0 for frames related to the state of the connection, HTTP/3 defines a pair of unidirectional streams called "control streams" for this purpose.  Where ORIGIN indicates that the ORIGIN frame should be sent on Stream 0, this should be interpreted to mean the HTTP/3 control stream.  The ORIGIN frame is sent from servers to clients on the server's control stream. The layout and semantics of the frame payload are identical to those of the HTTP/2 frame defined in ORIGIN.  The ORIGIN frame type is 0xc (decimal 12), as in HTTP/2. </del> <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 frames related to the state of the connection, HTTP/3 defines a pair of unidirectional streams called "control streams" for this purpose. Where ORIGIN indicates that the ORIGIN frame should be sent on Stream 0, this should be interpreted to mean the HTTP/3 control stream.  The ORIGIN frame is sent from servers to clients on the server's control stream. 2.1. The ORIGIN frame has a nearly identical layout to that used in HTTP/2, restated here for clarity.  The ORIGIN frame type is 0xc (decimal 12) as in HTTP/2.  The payload contains zero or more instances of the Origin-Entry field. An Origin-Entry is a length-delimited string.  Specifically, it contains two fields: 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. </ins> 3.
3.3.5. <ins> To sign using this algorithm, the signer applies the "ECDSA" algorithm defined in FIPS186-4 using curve P-384 with the signer's private signing key and the signature base (create-sig-input).  The hash SHA-384 RFC6234 is applied to the signature base to create the digest content to which the digital signature is applied, ("M").  The signature algorithm returns two integer values, "r" and "s".  These are both encoded as big-endian unsigned integers, zero-padded to 48-octets each.  These encoded values are concatenated into a single 96-octet array consisting of the encoded value of "r" followed by the encoded value of "s".  The resulting concatenation of "(r, s)" is byte array of the HTTP message signature output used in sign. To verify using this algorithm, the verifier applies the "ECDSA" algorithm defined in FIPS186-4 using the public key portion of the verification key material and the signature base re-created as described in verify.  The hash function SHA-384 RFC6234 is applied to the signature base to create the digest content to which the signature verification function is applied, ("M").  The verifier extracts the HTTP message signature to be verified ("S") as described in verify.  This value is a 96-octet array consisting of the encoded values of "r" and "s" concatenated in order.  These are both encoded in big-endian unsigned integers, zero-padded to 48-octets each.  The resulting signature value "(r, s)" is used as input to the signature verification function.  The results of the verification function indicate if the signature presented is valid. Note that the output of ECDSA algorithms are non-deterministic, and therefore it is not correct to re-calculate a new signature on the signature base and compare the results to an existing signature. Instead, the verification algorithm defined here needs to be used. See security-nondeterministic. Use of this algorithm can be indicated at runtime using the "ecdsa- p384-sha384" value for the "alg" signature parameter. 3.3.6. </ins> To sign using this algorithm, the signer applies the "Ed25519" algorithm defined in RFC8032 with the signer's private signing key and the signature base (create-sig-input).  The signature base is
credentials and mandate the signature parameters contain a "created" parameter, while an API expecting semantically relevant HTTP message content could require the Content-Digest header to be <del> present and covered as well as mandate a value for "context" that is specific to the API being protected. </del> <ins> 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
"keyid": The identifier for the key material as a String value. <del> "context": An application-specific context for the signature as a String value.  This value is used by applications to help identify </del> <ins> "tag": An application-specific tag for the signature as a String value.  This value is used by applications to help identify </ins> signatures relevant for specific applications or protocols. Additional parameters can be defined in the iana-param-contents.
present, and applications should not put semantic meaning on the labels themselves.  Instead, additional signature parameters can be used to convey whatever additional meaning is required to be attached <del> to and covered by the signature.  In particular, the "context" parameter can be used to define an application-specific value as described in security-signature-context. </del> <ins> to and covered by the signature.  In particular, the "tag" parameter can be used to define an application-specific value as described in security-signature-tag. </ins> 7.2.6.
either accepting or rejecting a message based on an unrelated or irrelevant signature.  In order to help an application select which signatures apply to its own processing, the application can declare a <del> specific value for the "context" signature parameter as defined in </del> <ins> specific value for the "tag" signature parameter as defined in </ins> signature-params.  For example, a signature targeting an application <del> gateway could require "context="app-gateway"" as part of the signature parameters for that application. The use of the "context" parameter does not prevent an attacker from also using the same value as a target application, since the parameter's value is public and otherwise unrestricted.  As a consequence, a verifier should only use value of the "context" parameter to limit which signatures to check.  Each signature still needs to be examined by the verifier to ensure that sufficient coverage is provided, as discussed in security-coverage. </del> <ins> gateway could require "tag="app-gateway"" as part of the signature parameters for that application. The use of the "tag" parameter does not prevent an attacker from also using the same value as a target application, since the parameter's value is public and otherwise unrestricted.  As a consequence, a verifier should only use value of the "tag" parameter to limit which signatures to check.  Each signature still needs to be examined by the verifier to ensure that sufficient coverage is provided, as discussed in security-coverage. </ins> 7.2.8.
with a certificate, a client presents its X.509 certificate RFC5280 and proves possession of the corresponding private key to a server when negotiating a TLS connection or the resumption of such a <del> connection.  In contemporary versions of TLS RFC8446 RFC5246 this requires that the client send the Certificate and CertificateVerify messages during the handshake and for the server to verify the </del> <ins> connection.  In contemporary versions of TLS TLS TLS1.2 this requires that the client send the Certificate and CertificateVerify messages during the handshake and for the server to verify the </ins> CertificateVerify and Finished messages. <del> HTTP/2 restricts TLS 1.2 renegotiation (RFC7540) and prohibits TLS </del> <ins> HTTP/2 restricts TLS 1.2 renegotiation (RFC9113) and prohibits TLS </ins> 1.3 post-handshake authentication RFC8740.  However, they are sometimes used to implement reactive client certificate <del> authentication in HTTP/1.1 RFC7230 where the server decides whether </del> <ins> authentication in HTTP/1.1 RFC9112 where the server decides whether </ins> 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
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.