jiebi/CodeConvo huggingface dataset:
Code change:
This was languishing in a PR within my repo, but since we've merged the actual draft, we can promote this to a PR in the main repo as well. (Yes, I'll rename the tag if we merge this as-is.)

Related discussion:
text: Working Group information can be found at http://httpwg.github.io/ [2]; source code and issues list for this draft can be found at <del> https://github.com/httpwg/http-extensions/labels/client-cert-header </del> <ins> https://github.com/httpwg/http-extensions/labels/client-cert-field </ins> [3]. 1.
Code change:
This was languishing in a PR within my repo, but since we've merged the actual draft, we can promote this to a PR in the main repo as well. (Yes, I'll rename the tag if we merge this as-is.)

Related discussion:
text: deployments to work in practice, the reverse proxy needs to convey information about the client certificate to the origin application server.  A common way this information is conveyed in practice today <del> is by using non-standard headers to carry the certificate (in some </del> <ins> is by using non-standard fields to carry the certificate (in some </ins> encoding) or individual parts thereof in the HTTP request that is dispatched to the origin server.  This solution works but interoperability between independently developed components can be cumbersome or even impossible depending on the implementation choices <del> respectively made (like what header names are used or are </del> <ins> respectively made (like what field names are used or are </ins> configurable, which parts of the certificate are exposed, or how the certificate is encoded).  A well-known predictable approach to this commonly occurring functionality could improve and simplify
Code change:
This was languishing in a PR within my repo, but since we've merged the actual draft, we can promote this to a PR in the main repo as well. (Yes, I'll rename the tag if we merge this as-is.)

Related discussion:
text: This document aspires to standardize an HTTP header field named "Client-Cert" that a TLS terminating reverse proxy (TTRP) adds to <del> requests that it sends to the backend origin servers.  The header </del> <ins> requests that it sends to the backend origin servers.  The field </ins> value contains the client certificate from the mutually-authenticated TLS connection between the originating client and the TTRP.  This enables the backend origin server to utilize the client certificate information in its application logic.  While there may be additional proxies or hops between the TTRP and the origin server (potentially even with mutually-authenticated TLS connections between them), the <del> scope of the "Client-Cert" header is intentionally limited to </del> <ins> scope of the "Client-Cert" header field is intentionally limited to </ins> exposing to the origin server the certificate that was presented by the originating client in its connection to the TTRP.
Code change:
This was languishing in a PR within my repo, but since we've merged the actual draft, we can promote this to a PR in the main repo as well. (Yes, I'll rename the tag if we merge this as-is.)

Related discussion:
text: 2.1. <del> The field-values of the HTTP header defined herein utilize the </del> <ins> The field-values of the HTTP header field defined herein utilize the </ins> following encoded form. A certificate is represented in text as an "EncodedCertificate",
Code change:
This was languishing in a PR within my repo, but since we've merged the actual draft, we can promote this to a PR in the main repo as well. (Yes, I'll rename the tag if we merge this as-is.)

Related discussion:
text: The "Client-Cert" header field defined herein is only for use in HTTP requests and MUST NOT be used in HTTP responses.  It is a single HTTP <del> header field-value as defined in Section 3.2 of RFC7230, which MUST </del> <ins> header field value as defined in Section 3.2 of RFC7230, which MUST </ins> NOT have a list of values or occur multiple times in a request. 2.3.
Code change:
This was languishing in a PR within my repo, but since we've merged the actual draft, we can promote this to a PR in the main repo as well. (Yes, I'll rename the tag if we merge this as-is.)

Related discussion:
text: 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
Code change:
This was languishing in a PR within my repo, but since we've merged the actual draft, we can promote this to a PR in the main repo as well. (Yes, I'll rename the tag if we merge this as-is.)

Related discussion:
text: [2] http://httpwg.github.io/ [3] https://github.com/httpwg/http-extensions/labels/client-cert- <del> header </del> <ins> field </ins>
Code change:
This text should be more precise about the definition of different signature parameters, including inputs to PSS. All examples have been updated. Examples for ECDSA and HMAC have been added.

Related discussion:
text: 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.
Code change:
This text should be more precise about the definition of different signature parameters, including inputs to PSS. All examples have been updated. Examples for ECDSA and HMAC have been added.

Related discussion:
text: 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.
Code change:
This text should be more precise about the definition of different signature parameters, including inputs to PSS. All examples have been updated. Examples for ECDSA and HMAC have been added.

Related discussion:
text: 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.
Code change:
Remove the list prefix parameter operation on structured headers. This was previously added to allow for signing of a subset of combined headers, but since the combined header value cannot be considered a structured header value, the prefix functionality did not ultimately serve this purpose. However, common cases such as adding additional headers to a request could still be covered by a different mechanism. Note that dictionary key indexing is still allowed and facilitates multi-signature use cases.
(emphasis added by me) That sounds as if a subset of a list is not a valid list? How so?

Related discussion:
text: 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.
Code change:
Remove the list prefix parameter operation on structured headers. This was previously added to allow for signing of a subset of combined headers, but since the combined header value cannot be considered a structured header value, the prefix functionality did not ultimately serve this purpose. However, common cases such as adding additional headers to a request could still be covered by a different mechanism. Note that dictionary key indexing is still allowed and facilitates multi-signature use cases.
(emphasis added by me) That sounds as if a subset of a list is not a valid list? How so?

Related discussion:
text: registered in the HTTP Signatures Specialty Content Identifier Registry. (content-registry) <del> 2.4.1. </del> <ins> 2.3.1. </ins> The request target endpoint, consisting of the request method and the path and query of the effective request URI, is identified by the
Code change:
Remove the list prefix parameter operation on structured headers. This was previously added to allow for signing of a subset of combined headers, but since the combined header value cannot be considered a structured header value, the prefix functionality did not ultimately serve this purpose. However, common cases such as adding additional headers to a request could still be covered by a different mechanism. Note that dictionary key indexing is still allowed and facilitates multi-signature use cases.
(emphasis added by me) That sounds as if a subset of a list is not a valid list? How so?

Related discussion:
text: 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.
Code change:
Remove the list prefix parameter operation on structured headers. This was previously added to allow for signing of a subset of combined headers, but since the combined header value cannot be considered a structured header value, the prefix functionality did not ultimately serve this purpose. However, common cases such as adding additional headers to a request could still be covered by a different mechanism. Note that dictionary key indexing is still allowed and facilitates multi-signature use cases.
(emphasis added by me) That sounds as if a subset of a list is not a valid list? How so?

Related discussion:
text: the signature parameters used for the current signature are included in this field. <del> 2.5. </del> <ins> 2.4. </ins> The signature input is a US-ASCII string containing the content that is covered by the signature.  To create the signature input string,
Code change:
Remove the list prefix parameter operation on structured headers. This was previously added to allow for signing of a subset of combined headers, but since the combined header value cannot be considered a structured header value, the prefix functionality did not ultimately serve this purpose. However, common cases such as adding additional headers to a request could still be covered by a different mechanism. Note that dictionary key indexing is still allowed and facilitates multi-signature use cases.
(emphasis added by me) That sounds as if a subset of a list is not a valid list? How so?

Related discussion:
text: 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:
Code change:
Remove the list prefix parameter operation on structured headers. This was previously added to allow for signing of a subset of combined headers, but since the combined header value cannot be considered a structured header value, the prefix functionality did not ultimately serve this purpose. However, common cases such as adding additional headers to a request could still be covered by a different mechanism. Note that dictionary key indexing is still allowed and facilitates multi-signature use cases.
(emphasis added by me) That sounds as if a subset of a list is not a valid list? How so?

Related discussion:
text: associated registry. Signers SHOULD include "@request-target" in the covered content <del> list list. </del> <ins> list. </ins> Signers SHOULD include a date stamp in some form, such as using the "date" header.  Alternatively, the "created" signature
Code change:
This can be relaxed to XML with a document element in the "DAV:" namespace, or even to the two element names mentioned in Section 2.2.2 of [RFC5323].

Related discussion:
text: 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
Code change:
This minor nit was the only thing that jumped out at me during a read-through before the interim.

Related discussion:
text: 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
Code change:
This PR talks about the server-side recommendation discussed in URL
This PR really just documents an existing consideration that was quielty overlooked, so I think it's good to merge whenever we feel like
Agreed. Let's merge and see.

Related discussion:
text: 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
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: 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.
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: 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
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: such a canonical form. Content identifiers are defined using production grammar defined by <del> RFC8941.  The content identifier is an "sf-string" value.  The </del> <ins> RFC8941.  The content identifier itself is an "sf-string" value.  The </ins> content identifier type MAY define parameters which are included using the "parameters" rule.