jiebi/CodeConvo huggingface dataset:
be met in a number of ways, which will vary based on specific deployments.  The communication between a TTRP and backend or origin server, for example, might be authenticated in some way with the <del> insertion and consumption of the "Client-Cert" header occurring only </del> <ins> insertion and consumption of the "Client-Cert" field occurring only </ins> 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
messages during the handshake and for the server to verify the CertificateVerify and Finished messages. <del> TODO: HTTP2 forbids TLS renegotiation and post-handshake authentication but it's possible with HTTP1.1 and maybe needs to be discussed explicitly here or somewhere in this document? Naively I'd say that the "Client-Cert" header will be sent with the data of the most recent client cert anytime after renegotiation or post-handshake auth.  And only for requests that are fully covered by the cert but that in practice making the determination of where exactly in the application data the cert messages arrived is hard to impossible so it'll be a best effort kind of thing. </del> 2. 2.1.
To sign using this algorithm, the signer applies the "RSASSA-PSS-SIGN (K, M)" function RFC8017 with the signer's private signing key ("K") <del> and the signature input string ("M") (create-sig-input).  The hash SHA-512 RFC6234 is applied to the signature input string to create the digest content to which the digital signature is applied.  The resulting signed content byte array ("S") is the HTTP message signature output used in sign. </del> <ins> and the signature input string ("M") (create-sig-input).  The mask generation function is "MGF1" as specified in RFC8017 with a hash function of SHA-512 RFC6234.  The salt length ("sLen") is 64 bytes. The hash function ("Hash") SHA-512 RFC6234 is applied to the signature input string to create the digest content to which the digital signature is applied.  The resulting signed content byte array ("S") is the HTTP message signature output used in sign. </ins> To verify using this algorithm, the verifier applies the "RSASSA-PSS- VERIFY ((n, e), M, S)" function RFC8017 using the public key portion of the verification key material ("(n, e)") and the signature input <del> string ("M") re-created as described in verify.  The hash function SHA-512 RFC6234 is applied to the signature input 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 of the verification function are compared to the http message signature to determine if the signature presented is valid. </del> <ins> string ("M") re-created as described in verify.  The mask generation function is "MGF1" as specified in RFC8017 with a hash function of SHA-512 RFC6234.  The salt length ("sLen") is 64 bytes.  The hash function ("Hash") SHA-512 RFC6234 is applied to the signature input 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 of the verification function are compared to the http message signature to determine if the signature presented is valid. </ins> 3.3.2.
applied.  The resulting signed content byte array ("S") is the HTTP message signature output used in sign. <del> To verify using this algorithm, the verifier applies the "RSASSA-PSS- VERIFY ((n, e), M, S)" function RFC8017 using the public key portion of the verification key material ("(n, e)") and the signature input string ("M") re-created as described in verify.  The hash function SHA-256 RFC6234 is applied to the signature input 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 of the verification function are compared to the http message signature to determine if the signature presented is valid. </del> <ins> To verify using this algorithm, the verifier applies the "RSASSA- PKCS1-V1_5-VERIFY ((n, e), M, S)" function RFC8017 using the public key portion of the verification key material ("(n, e)") and the signature input string ("M") re-created as described in verify.  The hash function SHA-256 RFC6234 is applied to the signature input 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 of the verification function are compared to the http message signature to determine if the signature presented is valid. </ins> 3.3.3.
policy RFC8126 and shall follow the template presented in iana-hsa- template. <ins> Algorithms referenced by algorithm identifiers have to be fully defined with all parameters fixed.  Algorithm identifiers in this registry are to be interpreted as whole string values and not as a combination of parts.  That is to say, it is expected that implementors understand "rsa-pss-sha512" as referring to one specific algorithm with its hash, mask, and salt values set as defined here. Implementors do not parse out the "rsa", "pss", and "sha512" portions of the identifier to determine parameters of the signing algorithm from the string. </ins> 5.1.1.
2.3. <del> A prefix of a List Structured Field consisting of the first N members in the field's value (where N is an integer greater than 0 and less than or equal to the number of members in the List) is identified by the parameter "prefix" with the value of N as an integer. A list prefix value is canonicalized by applying the serialization algorithm described in RFC8941 on a List containing only the first N members as specified in the list prefix, in the order they appear in the original List. 2.3.1. This section contains non-normative examples of canonicalized values for list prefixes given the following example header fields, whose values are assumed to be Dictionaries: The following table shows example canonicalized values for different content identifiers, given those fields: 2.4. </del> Content not found in an HTTP header can be included in the signature base string by defining a content identifier and the canonicalization method for its content.
header in HTTP2, Section 8.1.2.3.  The resulting string is the canonicalized value. <del> 2.4.1.1. </del> <ins> 2.3.1.1. </ins> The following table contains non-normative example HTTP messages and their canonicalized "@request-target" values. <del> 2.4.2. </del> <ins> 2.3.2. </ins> HTTP Message Signatures have metadata properties that provide information regarding the signature's generation and/or verification.
header field that is not present in the message, is not a Dictionary Structured Field, or whose value is malformed. <del> The identifier is a List Prefix member identifier that references a header field that is not present in the message, is not a List Structured Field, or whose value is malformed. </del> The identifier is a Dictionary member identifier that references a member that is not present in the header field value, or whose value is malformed.  E.g., the identifier is ""x-dictionary";key=c" and the value of the "x-dictionary" header field is "a=1, b=2" <del> The identifier is a List Prefix member identifier that specifies more List members than are present the header field.  E.g., the identifier is ""x-list";prefix=3" and the value of the "x-list" header field is "(1, 2)". </del> In the following non-normative example, the HTTP message being signed is the following request:
MAY use a request body of any content type with the SEARCH method; however, for backwards compatibility with existing WebDAV implementations, SEARCH requests that use the text/xml or <del> application/xml media types MUST be processed per the requirements </del> <ins> application/xml media types with a root element (XML) in the "DAV:" XML namespace (XMLNS) MUST be processed per the requirements </ins> established by RFC5323. SEARCH requests are both safe and idempotent with regards to the
suboptimal, particularly if one endpoint operates in ignorance of the needs of its peer. <del> HTTP/2 introduced a complex prioritization signaling scheme that used a combination of dependencies and weights, formed into an unbalanced tree.  This scheme has suffered from poor deployment and </del> <ins> HTTP/2 introduced a complex prioritization scheme that uses a combination of stream dependencies and weights to describe an unbalanced tree.  This scheme has suffered from poor deployment and </ins> interoperability. <del> The rich flexibility of client-driven HTTP/2 prioritization tree building is rarely exercised.  Experience has shown that clients tend to choose a single model optimized for a web use case and experiment within the model constraints, or do nothing at all.  Furthermore, many clients build their prioritization tree in a unique way, which makes it difficult for servers to understand their intent and act or intervene accordingly. </del> <ins> Clients build an HTTP/2 prioritization tree through a series of individual stream relationships, which are transferred to the server using HTTP/2 priority signals in either of three forms.  First, a HEADERS frame with the PRIORITY flag set is an explicit signal that includes an Exclusive flag, Stream Dependency field, and Weight field.  Second, a HEADERS frame with no PRIORITY flag is an implicit signal to use the default priority.  Third, the PRIORITY frame, which is always explicit since it always contains an Exclusive flag, Stream Dependency field, and Weight field. The rich flexibility of tree building is rarely exercised. Experience has shown that clients tend to choose a single model optimized for a web use case and experiment within the model constraints, or do nothing at all.  Furthermore, many clients build their prioritization tree in a unique way, which makes it difficult for servers to understand their intent and act or intervene accordingly. </ins> Many HTTP/2 server implementations do not include support for the priority scheme.  Some instead favor custom server-driven schemes
as a connection error of type PROTOCOL_ERROR. Until the client receives the SETTINGS frame from the server, the <del> client SHOULD send both the priority signal defined in the HTTP/2 priority scheme and also that of this prioritization scheme.  When the client receives the first SETTINGS frame that contains the </del> <ins> client SHOULD send the signals of the HTTP/2 priority scheme (see motivation) and the signals of this prioritization scheme (see header-field and h2-update-frame).  When the client receives the first SETTINGS frame that contains the </ins> SETTINGS_DEPRECATE_HTTP2_PRIORITIES parameter with value of 1, it SHOULD stop sending the HTTP/2 priority signals.  If the value was 0 or if the settings parameter was absent, it SHOULD stop sending
A successful response to a SEARCH request is expected to provide some indication as to the final disposition of the search operation.  For instance, a successful search that yields no results can be <del> represented by a 204 No Content response.  If the response includes a </del> <ins> represented by a 204 No Content response.  If the response includes </ins> content, it is expected to describe the results of the search operation.  In some cases, the server may choose to respond indirectly to the SEARCH request by returning a 3xx Redirection with
the intended priority to the client by including the Priority field in a PUSH_PROMISE or HEADERS frame. <ins> 9.1. An intermediary serving an HTTP connection might split requests over multiple backend connections.  When it applies prioritization rules strictly, low priority requests cannot make progress while requests with higher priorities are inflight.  This blocking can propagate to backend connections, which the peer might interpret as a connection stall.  Endpoints often implement protections against stalls, such as abruptly closing connections after a certain time period.  To reduce the possibility of this occurring, intermediaries can avoid strictly following prioritization and instead allocate small amounts of bandwidth for all the requests that they are forwarding, so that every request can make some progress over time. Similarly, servers SHOULD allocate some amount of bandwidths to streams acting as tunnels. </ins> 10. Transport protocols such as TCP and QUIC provide reliability by
reject any RSA signatures, or a server expecting asymmetric cryptography should know to reject any symmetric cryptography. <ins> An application using signatures also has to ensure that the verifier will have access to all required information to re-create the signature input string.  For example, a server behind a reverse proxy would need to know the original request URI to make use of identifiers like "@target-uri".  Additionally, an application using signatures in responses would need to ensure that clients receiving signed responses have access to all the signed portions, including any portions of the request that were signed by the server. </ins> The details of this kind of profiling are the purview of the application and outside the scope of this specification.
covered by a signature, this document defines content identifiers for data items covered by an HTTP Message Signature as well as the means for combining these canonicalized values into a signature input <del> string. </del> <ins> string.  The values for these items MUST be accessible to both the sender and the receiver of the message, which means these are usually derived from aspects of the HTTP message or signature itself. </ins> Some content within HTTP messages can undergo transformations that change the bitwise value without altering meaning of the content (for
This specification defines the following specialty content identifiers: <del> The target request endpoint. (content-request-target) </del> The signature metadata parameters for this signature. (signature- params) <del> Additional specialty content identifiers MAY be defined and registered in the HTTP Signatures Specialty Content Identifier Registry. (content-registry) </del> <ins> The method used for a request. (content-request-method) </ins> <del> 2.3.1. </del> <ins> The full target URI for a request. (content-target-uri) </ins> <del> The request target endpoint, consisting of the request method and the path and query of the effective request URI, is identified by the "@request-target" identifier. </del> <ins> The authority of the target URI for a request. (content-request- authority) </ins> <del> Its value is canonicalized as follows: </del> <ins> The scheme of the target URI for a request. (content-request- scheme) </ins> <del> Take the lowercased HTTP method of the message. </del> <ins> The request target. (content-request-target) </ins> <del> Append a space " ". </del> <ins> The absolute path portion of the target URI for a request. (content-request-path) </ins> <del> Append the path and query of the request target of the message, formatted according to the rules defined for the :path pseudo- header in HTTP2, Section 8.1.2.3.  The resulting string is the canonicalized value. </del> <ins> The query portion of the target URI for a request. (content- request-query) </ins> <del> 2.3.1.1. </del> <ins> The parsed query parameters of the target URI for a request. (content-request-query-params) </ins> <del> The following table contains non-normative example HTTP messages and their canonicalized "@request-target" values. </del> <ins> The status code for a response. (content-status-code). </ins> <del> 2.3.2. </del> <ins> Additional specialty content identifiers MAY be defined and registered in the HTTP Signatures Specialty Content Identifier Registry. (content-registry) 2.3.1. </ins> HTTP Message Signatures have metadata properties that provide <del> information regarding the signature's generation and/or verification. </del> <ins> information regarding the signature's generation and/or verification, such as the list of covered content, a timestamp, identifiers for verification key material, and other utilities. </ins> The signature parameters specialty content is identified by the "@signature-params" identifier.
In the following non-normative example, the HTTP message being signed is the following request: <del> The covered content consists of the "@request-target" specialty content followed by the "Host", "Date", "Cache-Control", "X-Empty- Header", "X-Example" HTTP headers, in order.  The signature creation timestamp is "1618884475" and the key identifier is "test-key-rsa- pss".  The signature input string for this message with these </del> <ins> The covered content consists of the "@method", "@path", and "@authority" specialty content followed by the "Cache-Control", "X- Empty-Header", "X-Example" HTTP headers, in order.  The signature creation timestamp is "1618884475" and the key identifier is "test- key-rsa-pss".  The signature input string for this message with these </ins> parameters is: 3.
specialty content field listed in specialty-content or its associated registry. <del> Signers SHOULD include "@request-target" in the covered content list. </del> <ins> Signers of a request SHOULD include some or all of the control data in the covered content list, such as the "@method", "@authority", "@target-uri", or some combination thereof. </ins> <del> Signers SHOULD include a date stamp in some form, such as using the "date" header.  Alternatively, the "created" signature metadata parameter can fulfil this role. </del> <ins> Signers SHOULD include the "created" signature metadata parameter to indicate when the signature was created. </ins> Further guidance on what to include in this list and in what order is out of scope for this document.  However, note that
The "@status" identifier MUST NOT be used in a request message. <ins> 2.3.11. When a signed request message results in a signed response message, the "@request-response" identifier can be used to cryptographically link the request and the response to each other by including the identified request signature value in the response.  This identifier has a single REQUIRED parameter: Identifies which signature from the response to sign. The value is the "sf-binary" representation of the signature value of the referenced request identified by the "key" parameter. For example, when serving this signed request: This would result in the following unsigned response message: The server signs the response with its own key and includes the signature of "sig1" from the request in the signed content of the response.  The signature input string for this example is: The signed response message is: Since the request's signature value itself is not repeated in the response, the requester MUST keep the original signature value around long enough to validate the signature of the response. The "@request-response" identifier MUST NOT be used in a request message. </ins> 2.4. The signature input is a US-ASCII string containing the content that
manipulation of the HTTP/2 priority tree.  Extensible priorities does not use stream dependencies, which mitigates this vulnerability. <del> TBD: depending on the outcome of reprioritization discussions, following paragraphs may change or be removed. </del> HTTP2, Section 5.3.4 describes a scenario where closure of streams in the priority tree could cause suboptimal prioritization.  To avoid this, HTTP2 states that "an endpoint SHOULD retain stream
If the cookie-name or the cookie-value contains a %x00-1F / %x7F (CTL) character, abort these steps and ignore the cookie entirely. <ins> If the sum of the lengths of cookie-name and cookie-value is more than 4096 octets, abort these steps and ignore the cookie entirely. </ins> Create a new cookie with name cookie-name, value cookie-value. Set the creation-time and the last-access-time to the current date and time.
If the cookie-attribute-list contains an attribute with an attribute-name of "Path", set the cookie's path to attribute-value <del> of the last attribute in the cookie-attribute-list with an attribute-name of "Path".  Otherwise, set the cookie's path to the </del> <ins> of the last attribute in the cookie-attribute-list with both an attribute-name of "Path" and an attribute-value whose length is no more than 1024 octets.  Otherwise, set the cookie's path to the </ins> default-path of the request-uri. If the cookie-attribute-list contains an attribute with an
NOTE: As set-cookie-string may originate from a non-HTTP API, it is not guaranteed to be free of CTL characters, so this algorithm <del> handles them explicitly. </del> <ins> handles them explicitly.  Horizontal tab (%x09) is excluded from the CTL characters that lead to set-cookie-string rejection, as it is considered whitespace, which is handled separately. </ins> A user agent MUST use an algorithm equivalent to the following algorithm to parse a set-cookie-string: <del> If the set-cookie-string contains a %x00-1F / %x7F (CTL) character: Abort these steps and ignore the set-cookie-string entirely. </del> <ins> If the set-cookie-string contains a %x00-08 / %x0A-1F / %x7F character (CTL characters excluding HTAB): Abort these steps and ignore the set-cookie-string entirely. </ins> If the set-cookie-string contains a %x3B (";") character:
If cookie-name is empty and cookie-value is empty, abort these steps and ignore the cookie entirely. <del> If the cookie-name or the cookie-value contains a %x00-1F / %x7F (CTL) character, abort these steps and ignore the cookie entirely. </del> <ins> If the cookie-name or the cookie-value contains a %x00-08 / %x0A- 1F / %x7F character (CTL characters excluding HTAB), abort these steps and ignore the cookie entirely. </ins> If the sum of the lengths of cookie-name and cookie-value is more than 4096 octets, abort these steps and ignore the cookie
client's original signature values. The following is a non-normative example of header fields a reverse <del> proxy sets in addition to the examples in the previous sections.  The original signature is included under the identifier "sig1", and the reverse proxy's signature is included under "proxy_sig".  The proxy uses the key "rsa-test-key" to create its signature using the "rsa- v1_5-sha256" signature value.  This results in a signature input string of: </del> <ins> proxy sets in addition to the examples in the previous sections. The client's request includes a signature value under the label "sig1", which the proxy signs in addition to the "Forwarded" header defined in RFC7239.  Note that since the client's signature already covers the client's "Signature-Input" value for "sig1", this value is transitively covered by the proxy's signature and need not be added explicitly.  This results in a signature input string of: </ins> And a signature output value of: These values are added to the HTTP request message by the proxy.  The <del> different signature values are wrapped onto separate lines to increase human-readability of the result. </del> <ins> original signature is included under the identifier "sig1", and the reverse proxy's signature is included under the label "proxy_sig". The proxy uses the key "test-key-rsa" to create its signature using the "rsa-v1_5-sha256" signature algorithm, while the client's original signature was made using the key id of "test-key-rsa-pss" and an RSA PSS signature algorithm. </ins> The proxy's signature and the client's original signature can be <del> verified independently for the same message, depending on the needs of the application. </del> <ins> verified independently for the same message, based on the needs of the application.  Since the proxy's signature covers the client signature, the backend service fronted by the proxy can trust that the proxy has validated the incoming signature. </ins> 5.