jiebi/CodeConvo huggingface dataset:
Code change:
This adds several new specialty identifiers for requests and responses to cover the method, authority, scheme, origin, path, query, and status code values of the HTTP message. It also edits the identifier's associated value to remove the verb and the string construction rules and instead align with HTTP Semantics.
NAME I haven't added references in yet but I tried to move the language in the direction you are suggesting. NAME I added the target-uri field we discussed, please review the text.
Responded to comments and updated normalization rules, please re-review.
Folding in this PR to the main document, discussion can continue on specifics of identifiers and their values as needed.

Related discussion:
text: 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.
Code change:
This adds several new specialty identifiers for requests and responses to cover the method, authority, scheme, origin, path, query, and status code values of the HTTP message. It also edits the identifier's associated value to remove the verb and the string construction rules and instead align with HTTP Semantics.
NAME I haven't added references in yet but I tried to move the language in the direction you are suggesting. NAME I added the target-uri field we discussed, please review the text.
Responded to comments and updated normalization rules, please re-review.
Folding in this PR to the main document, discussion can continue on specifics of identifiers and their values as needed.

Related discussion:
text: parameters for this signature, including the covered content list with all associated parameters. <del> "alg": The HTTP message signature algorithm from the HTTP Message Signature Algorithm Registry, as an "sf-string" value. "keyid": The identifier for the key material as an "sf-string" value. </del> "created": Creation time as an "sf-integer" UNIX timestamp value. Sub-second precision is not supported.
Code change:
This adds several new specialty identifiers for requests and responses to cover the method, authority, scheme, origin, path, query, and status code values of the HTTP message. It also edits the identifier's associated value to remove the verb and the string construction rules and instead align with HTTP Semantics.
NAME I haven't added references in yet but I tried to move the language in the direction you are suggesting. NAME I added the target-uri field we discussed, please review the text.
Responded to comments and updated normalization rules, please re-review.
Folding in this PR to the main document, discussion can continue on specifics of identifiers and their values as needed.

Related discussion:
text: "nonce": A random unique value generated for this signature. <ins> "alg": The HTTP message signature algorithm from the HTTP Message Signature Algorithm Registry, as an "sf-string" value. "keyid": The identifier for the key material as an "sf-string" value. </ins> Additional parameters can be defined in the iana-param-contents. The signature parameters are serialized using the rules in RFC8941 as
Code change:
This adds several new specialty identifiers for requests and responses to cover the method, authority, scheme, origin, path, query, and status code values of the HTTP message. It also edits the identifier's associated value to remove the verb and the string construction rules and instead align with HTTP Semantics.
NAME I haven't added references in yet but I tried to move the language in the direction you are suggesting. NAME I added the target-uri field we discussed, please review the text.
Responded to comments and updated normalization rules, please re-review.
Folding in this PR to the main document, discussion can continue on specifics of identifiers and their values as needed.

Related discussion:
text: 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.
Code change:
This adds several new specialty identifiers for requests and responses to cover the method, authority, scheme, origin, path, query, and status code values of the HTTP message. It also edits the identifier's associated value to remove the verb and the string construction rules and instead align with HTTP Semantics.
NAME I haven't added references in yet but I tried to move the language in the direction you are suggesting. NAME I added the target-uri field we discussed, please review the text.
Responded to comments and updated normalization rules, please re-review.
Folding in this PR to the main document, discussion can continue on specifics of identifiers and their values as needed.

Related discussion:
text: 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
Code change:
This creates a mechanism to cryptographically bind a response to its associated request by letting the responder sign the signature value of the request, and the requester validate the signature based on their original request's signature.

Related discussion:
text: The status code for a response. (content-status-code). <ins> A signature from a request message that resulted in this response message. (content-request-response) </ins> Additional specialty content identifiers MAY be defined and registered in the HTTP Signatures Specialty Content Identifier Registry. (content-registry)
Code change:
This creates a mechanism to cryptographically bind a response to its associated request by letting the responder sign the signature value of the request, and the requester validate the signature based on their original request's signature.

Related discussion:
text: 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
Code change:
We're keeing reprioritization, no need for this TBD any longer.
Thank you for noticing it.

Related discussion:
text: 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
Code change:
Addresses
NAME NAME PTAL
RFC6265bis mentions the cookie length constraints in relation to parsing the Set-Cookie headers but doesn't in the more general Storage Model section. From chatting with NAME about this, it'd be desirable to have these constraints be listed in that section as well. Since there are other ways cookies can come in to the cookie store (Ex: Cookie Store API), having these constraints be enforced when adding cookies from any source to the cookie store would better ensure cookie format consistency.

Related discussion:
text: and the value string. If the sum of the lengths of the name string and the value string <del> is more than 4096 bytes, abort these steps and ignore the set- </del> <ins> is more than 4096 octets, abort these steps and ignore the set- </ins> cookie-string entirely. The cookie-name is the name string, and the cookie-value is the
Code change:
Addresses
NAME NAME PTAL
RFC6265bis mentions the cookie length constraints in relation to parsing the Set-Cookie headers but doesn't in the more general Storage Model section. From chatting with NAME about this, it'd be desirable to have these constraints be listed in that section as well. Since there are other ways cookies can come in to the cookie store (Ex: Cookie Store API), having these constraints be enforced when adding cookies from any source to the cookie store would better ensure cookie format consistency.

Related discussion:
text: Remove any leading or trailing WSP characters from the attribute- name string and the attribute-value string. <del> If the attribute-value is longer than 1024 bytes, ignore the </del> <ins> If the attribute-value is longer than 1024 octets, ignore the </ins> cookie-av string and return to Step 1 of this algorithm. Process the attribute-name and attribute-value according to the
Code change:
Addresses
NAME NAME PTAL
RFC6265bis mentions the cookie length constraints in relation to parsing the Set-Cookie headers but doesn't in the more general Storage Model section. From chatting with NAME about this, it'd be desirable to have these constraints be listed in that section as well. Since there are other ways cookies can come in to the cookie store (Ex: Cookie Store API), having these constraints be enforced when adding cookies from any source to the cookie store would better ensure cookie format consistency.

Related discussion:
text: 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.
Code change:
Addresses
NAME NAME PTAL
RFC6265bis mentions the cookie length constraints in relation to parsing the Set-Cookie headers but doesn't in the more general Storage Model section. From chatting with NAME about this, it'd be desirable to have these constraints be listed in that section as well. Since there are other ways cookies can come in to the cookie store (Ex: Cookie Store API), having these constraints be enforced when adding cookies from any source to the cookie store would better ensure cookie format consistency.

Related discussion:
text: attribute-name of "Domain": Let the domain-attribute be the attribute-value of the last <del> attribute in the cookie-attribute-list with an attribute-name of "Domain". </del> <ins> attribute in the cookie-attribute-list with both an attribute- name of "Domain" and an attribute-value whose length is no more than 1024 octets. </ins> Otherwise:
Code change:
Addresses
NAME NAME PTAL
RFC6265bis mentions the cookie length constraints in relation to parsing the Set-Cookie headers but doesn't in the more general Storage Model section. From chatting with NAME about this, it'd be desirable to have these constraints be listed in that section as well. Since there are other ways cookies can come in to the cookie store (Ex: Cookie Store API), having these constraints be enforced when adding cookies from any source to the cookie store would better ensure cookie format consistency.

Related discussion:
text: 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
Code change:
Thank you for the fix.
FWIW, I would prefer s/MAY/can/ - there is no normative effect of a choice. Originally posted by NAME in URL

Related discussion:
text: server-scheduling, and connect-scheduling. Where HTTP extensions change stream behavior or define new data <del> carriage mechanisms, they MAY also define how this priority scheme </del> <ins> carriage mechanisms, they can also define how this priority scheme </ins> can be applied. 4.
Code change:
This excludes HTAB (%x09) from the CTL characters that normally cause cookie rejection. HTAB is considered whitespace and is handled separately at a later step in the algorithm. Related to
NAME NAME PTAL.
LGTM
In URL, RFC 6265bis was modified to specify truncation of set-cookie-lines at the first {CR, LF, NUL} byte. This is consistent with Chrome's current behavior. NAME that this may enable an attack where an attacker may inject a CR, LF, or NUL byte into a cookie value to cause its truncation, thus changing the value of the cookie. Investigate interop/web compatibility and consider rejecting all cookies containing any control character (rather than truncating).
Addressed by and .
Thanks NAME Do you know if tests have been updated as well and implementations bugs have been filed against browsers that do not do this (yet)?
NAME I just submitted for review an update to the tests, and will soon file bugs based on the findings from running those. I'll post back here with links to any tickets I open. Thanks for asking about this For reference: URL
NAME FYI, here are the corresponding bugs: URL ​​URL URL
Thanks NAME for your work on this!
lgtm, thanks

Related discussion:
text: 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:
Code change:
This excludes HTAB (%x09) from the CTL characters that normally cause cookie rejection. HTAB is considered whitespace and is handled separately at a later step in the algorithm. Related to
NAME NAME PTAL.
LGTM
In URL, RFC 6265bis was modified to specify truncation of set-cookie-lines at the first {CR, LF, NUL} byte. This is consistent with Chrome's current behavior. NAME that this may enable an attack where an attacker may inject a CR, LF, or NUL byte into a cookie value to cause its truncation, thus changing the value of the cookie. Investigate interop/web compatibility and consider rejecting all cookies containing any control character (rather than truncating).
Addressed by and .
Thanks NAME Do you know if tests have been updated as well and implementations bugs have been filed against browsers that do not do this (yet)?
NAME I just submitted for review an update to the tests, and will soon file bugs based on the findings from running those. I'll post back here with links to any tickets I open. Thanks for asking about this For reference: URL
NAME FYI, here are the corresponding bugs: URL ​​URL URL
Thanks NAME for your work on this!
lgtm, thanks

Related discussion:
text: 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
Code change:
Minor editorial cleanups, including: added client cert example updated multiple signature example prepare for next revision

Related discussion:
text: 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.
Code change:
wouldn't the "Proxy-Status" header field require an action in the IANA considerations section to register the header field itself? currently, the only things in this section are the creation of new registries required for the header field.
a la rewriting, invalidation controls, etc. See

Related discussion:
text: with the types defined in params and error-types respectively; see register-param and register-error for its associated procedures. <ins> Additionally, please register the following entry in the Hypertext Transfer Protocol (HTTP) Field Name Registry: Field name: Proxy-Status Status: permanent Specification document(s): [this document] Comments: </ins> 4. One of the primary security concerns when using Proxy-Status is