jiebi/CodeConvo huggingface dataset:
Code change:
WIP.
NAME NAME quick once over before I merge?
NAME thanks, updated, squashed.. merging.
:
: The and rules are not used in the document. The rule is not used in the document, unless you accept . The rule is not used in the document, but I think it can be useful to clarify the definition of , i.e.:
I agree that using "field-name" over there makes this a bit clearer.
Addressed in: URL

Related discussion:
text: This document uses the Augmented Backus-Naur Form (ABNF) notation of RFC5234 with the list rule extension defined in RFC7230, Appendix B. <del> It includes by reference the DIGIT rule from RFC5234; the OWS, field- name and quoted-string rules from RFC7230; and the parameter rule from RFC7231. </del> <ins> It includes by reference the DIGIT rule from RFC5234 and the OWS and field-name rules from RFC7230. </ins> 2.
Code change:
WIP.
NAME NAME quick once over before I merge?
NAME thanks, updated, squashed.. merging.
:
: The and rules are not used in the document. The rule is not used in the document, unless you accept . The rule is not used in the document, but I think it can be useful to clarify the definition of , i.e.:
I agree that using "field-name" over there makes this a bit clearer.
Addressed in: URL

Related discussion:
text: received hints from the client.  When doing so, and if the resource is cacheable, the server MUST also emit a Vary response header field (Section 7.1.4 of RFC7231), and optionally Key (I-D.ietf-httpbis- <del> key), to indicate which hints were used and whether the selected response is appropriate for a later request. </del> <ins> key), to indicate which hints can affect the selected response and whether the selected response is appropriate for a later request. </ins> Further, depending on the used hint, the server can emit additional response header fields to confirm the property of the response, such
Code change:
WIP.
NAME NAME quick once over before I merge?
NAME thanks, updated, squashed.. merging.
:
: The and rules are not used in the document. The rule is not used in the document, unless you accept . The rule is not used in the document, but I think it can be useful to clarify the definition of , i.e.:
I agree that using "field-name" over there makes this a bit clearer.
Addressed in: URL

Related discussion:
text: For example: <del> When a client receives Accept-CH, it SHOULD append the Client Hint header fields that match the advertised field-values.  For example, based on Accept-CH example above, the client would append DPR, Width, Viewport-Width, and Downlink header fields to all subsequent requests. </del> <ins> When a client receives Accept-CH, or if it is capable of processing the HTML response and finds an equivalent HTML meta element, it SHOULD append the Client-Hint header fields that match the advertised field-values to the header list of all subsequent requests.  For example, based on Accept-CH example above, a user agent could append DPR, Width, Viewport-Width, and Downlink header fields to all subresource requests initiated by the page constructed from the response.  Alternatively, a client can treat advertised support as a persistent origin preference and append same header fields on all future requests initiated to and by the resources associated with that origin. </ins> 2.2.2. When selecting an optimized response based on one or more Client Hints, and if the resource is cacheable, the server needs to emit a <del> Vary response header field (RFC7234) to indicate which hints were used and whether the selected response is appropriate for a later request. </del> <ins> Vary response header field (RFC7234) to indicate which hints can affect the selected response and whether the selected response is appropriate for a later request. </ins> Above example indicates that the cache key needs to include the DPR header field.
Code change:
WIP.
NAME NAME quick once over before I merge?
NAME thanks, updated, squashed.. merging.
:
: The and rules are not used in the document. The rule is not used in the document, unless you accept . The rule is not used in the document, but I think it can be useful to clarify the definition of , i.e.:
I agree that using "field-name" over there makes this a bit clearer.
Addressed in: URL

Related discussion:
text: The "Width" request header field is a number that indicates the desired resource width in physical px (i.e. intrinsic size of an image).  The provided physical px value is a number rounded to the <del> largest smallest following integer (i.e. ceiling value). </del> <ins> smallest following integer (i.e. ceiling value). </ins> If the desired resource width is not known at the time of the request or the resource does not have a display width, the Width header field
Code change:
WIP.
NAME NAME quick once over before I merge?
NAME thanks, updated, squashed.. merging.
:
: The and rules are not used in the document. The rule is not used in the document, unless you accept . The rule is not used in the document, but I think it can be useful to clarify the definition of , i.e.:
I agree that using "field-name" over there makes this a bit clearer.
Addressed in: URL

Related discussion:
text: The "Viewport-Width" request header field is a number that indicates the layout viewport width in CSS px.  The provided CSS px value is a <del> number rounded to the largest smallest following integer (i.e. ceiling value). </del> <ins> number rounded to the smallest following integer (i.e. ceiling value). </ins> If Viewport-Width occurs in a message more than once, the last value overrides all previous occurrences.
Code change:
WIP.
NAME NAME quick once over before I merge?
NAME thanks, updated, squashed.. merging.
:
: The and rules are not used in the document. The rule is not used in the document, unless you accept . The rule is not used in the document, but I think it can be useful to clarify the definition of , i.e.:
I agree that using "field-name" over there makes this a bit clearer.
Addressed in: URL

Related discussion:
text: 7. <del> The "Save-Data" request header field is a token that indicates client's preference for reduced data usage, due to high transfer costs, slow connection speeds, or other reasons. </del> <ins> The "Save-Data" request header field consists of one or more tokens that indicate client's preference for reduced data usage, due to high transfer costs, slow connection speeds, or other reasons. </ins> This document defines the "on" sd-token value, which is used as a signal indicating explicit user opt-in into a reduced data usage mode
Code change:
~~
Thanks! This Lgtm but I'll let Steven take a look too
This looks to me as well, thanks!
UAs should not decode any URL-encoded (or otherwise encoded) characters while storing a cookie, e.g. a cookie such as should not be interpreted as a cookie. I landed some WPTs for this in URL Chrome, Edge, Firefox, and Safari do the right thing. I think this could just be a clarifying note in the parsing algorithm section.
I'll take this one
Let's make sure we are consistent for names and attributes.

Related discussion:
text: CTL characters that lead to set-cookie-string rejection, as it is considered whitespace, which is handled separately. <ins> NOTE: The set-cookie-string may contain octet sequences that appear percent-encoded as per Section 2.1 of RFC3986.  However, a user agent MUST NOT decode these sequences and instead parse the individual octets as specified in this algorithm. </ins> A user agent MUST use an algorithm equivalent to the following algorithm to parse a set-cookie-string:
Code change:
update canonicalization rules, remove weird headers from examples changed dictionaries and messages. updated crypto primative functions regenerate examples

Related discussion:
text: An individual member in the value of a Dictionary Structured Field is canonicalized by applying the serialization algorithm described in <del> RFC8941 on a Dictionary containing only that item. </del> <ins> RFC8941 on the member value and its parameters, without the dictionary key. </ins> Each parameterized key for a given field MUST NOT appear more than once in the signature input.  Parameterized keys MAY appear in any
Code change:
update canonicalization rules, remove weird headers from examples changed dictionaries and messages. updated crypto primative functions regenerate examples

Related discussion:
text: This would result in the following unsigned response message: <del> The server signs the response with its own key and includes the signature of "sig1" from the request in the covered components of the response.  The signature input string for this example is: </del> <ins> To cryptographically link the response to the request, the server signs the response with its own key and includes the signature of "sig1" from the request in the covered components of the response. The signature input string for this example is: </ins> The signed response message is:
Code change:
update canonicalization rules, remove weird headers from examples changed dictionaries and messages. updated crypto primative functions regenerate examples

Related discussion:
text: long enough to validate the signature of the response that uses this component identifier. <ins> Note that the ECDSA algorithm in use here is non-deterministic, meaning a different signature value will be created every time the algorithm is run.  The signature value provided here can be validated against the given keys, but newly-generated signature values are not expected to match the example.  See security-nondeterministic. </ins> The "@request-response" component identifier MUST NOT be used in a request message.
Code change:
update canonicalization rules, remove weird headers from examples changed dictionaries and messages. updated crypto primative functions regenerate examples

Related discussion:
text: produce an error and not create an input string.  Such situations are included but not limited to: <del> The signer or verifier does not understand the component </del> <ins> The signer or verifier does not understand the derived component </ins> identifier. The component identifier identifies a field that is not present in the message or whose value is malformed. The component identifier indicates that a structured field <del> serialization is used, but the field in question is known to not be a structured field or the type of structured field is not known to the verifier. </del> <ins> serialization is used (via the "sf" parameter), but the field in question is known to not be a structured field or the type of structured field is not known to the implementation. </ins> The component identifier is a dictionary member identifier that references a field that is not present in the message, is not a
Code change:
update canonicalization rules, remove weird headers from examples changed dictionaries and messages. updated crypto primative functions regenerate examples

Related discussion:
text: The component identifier is a dictionary member identifier or a named query parameter identifier that references a member that is not present in the component value, or whose value is malformed. <del> E.g., the identifier is ""x-dictionary";key="c"" and the value of the "x-dictionary" header field is "a=1, b=2" </del> <ins> E.g., the identifier is ""example-dictionary";key="c"" and the value of the "Example-Dictionary" header field is "a=1, b=2", which does not have the "c" value. </ins> In the following non-normative example, the HTTP message being signed is the following request: The covered components consist of the "@method", "@path", and <del> "@authority" derived component identifiers followed by the "Cache- Control", "X-Empty-Header", "X-Example" HTTP headers, in order.  The signature parameters consist of a creation timestamp is "1618884475" and the key identifier is "test-key-rsa-pss".  The signature input string for this message with these parameters is: </del> <ins> "@authority" derived component identifiers followed by the "Content- Digest", "Content-Length", and "Content-Type" HTTP header fields, in order.  The signature parameters consist of a creation timestamp of "1618884473" and a key identifier of "test-key-rsa-pss".  Note that no explicit "alg" parameter is given here since the verifier is assumed by the application to correctly use the RSA PSS algorithm based on the identified key.  The signature input string for this message with these parameters is: Note that the example signature input here, or anywhere else within this specification, does not include the final newline that ends the example. </ins> 3.
Code change:
update canonicalization rules, remove weird headers from examples changed dictionaries and messages. updated crypto primative functions regenerate examples

Related discussion:
text: HTTP Message signatures MAY use any cryptographic digital signature or MAC method that is appropriate for the key material, environment, <del> and needs of the signer and verifier.  All signatures are generated from and verified against the byte values of the signature input string defined in create-sig-input. </del> <ins> and needs of the signer and verifier. </ins> Each signature algorithm method takes as its input the signature <del> input string as a set of byte values ("I"), the signing key material ("Ks"), and outputs the signature output as a set of byte values ("S"): </del> <ins> input string defined in create-sig-input as a byte array ("M"), the signing key material ("Ks"), and outputs the signature output as a byte array ("S"): </ins> Each verification algorithm method takes as its input the <del> recalculated signature input string as a set of byte values ("I"), the verification key material ("Kv"), and the presented signature to be verified as a set of byte values ("S") and outputs the verification result ("V") as a boolean: </del> <ins> recalculated signature input string defined in create-sig-input as a byte array ("M"), the verification key material ("Kv"), and the presented signature to be verified as a byte array ("S") and outputs the verification result ("V") as a boolean: </ins> This section contains several common algorithm methods.  The method to use can be communicated through the algorithm signature parameter
Code change:
update canonicalization rules, remove weird headers from examples changed dictionaries and messages. updated crypto primative functions regenerate examples

Related discussion:
text: client in fields when forwarding the request to a service host, including a signature over the client's original signature values. <del> The following is a non-normative example of header fields a reverse proxy sets in addition to the examples in the previous sections. </del> <ins> The following is a non-normative example starts with a signed request from the client.  The proxy takes this request validates the client's signature. </ins> <del> 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: </del> <ins> The proxy then alters the message before forwarding it on to the origin server, changing the target host and adding the "Forwarded" header defined in RFC7239. The proxy includes the client's signature value under the label "sig1", which the proxy signs in addition to the "Forwarded" header. 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. The proxy identifies its own key and algorithm and, in this example, includes an expiration for the signature to indicate to downstream systems that the proxy will not vouch for this signed message past this short time window.  This results in a signature input string of: </ins> And a signature output value of:
Code change:
pseudo-header is hyphenated per [HTTP3], and expand out a "headers" straggler.
Thanks, this is great!

Related discussion:
text: RFC8441 defines a mechanism for running the WebSocket Protocol RFC6455 over a single stream of an HTTP/2 connection.  It defines an <del> Extended CONNECT method which specifies a new ":protocol" pseudo </del> <ins> Extended CONNECT method which specifies a new ":protocol" pseudo- </ins> header field and new semantics for the ":path" and ":authority" <del> pseudo header fields.  It also defines a new HTTP/2 setting sent by a </del> <ins> pseudo-header fields.  It also defines a new HTTP/2 setting sent by a </ins> server to allow the client to use Extended CONNECT. The HTTP/3 stream closure is also analogous to the TCP connection
Code change:
pseudo-header is hyphenated per [HTTP3], and expand out a "headers" straggler.
Thanks, this is great!

Related discussion:
text: FIN bit on the stream (HTTP3).  RST exceptions are represented with an stream error (HTTP3) of type H3_REQUEST_CANCELLED (HTTP3). <del> The semantics of the headers and setting are identical to those in HTTP/2 as defined RFC8441.  HTTP3 requires that HTTP/3 settings be registered separately for HTTP/3.  The </del> <ins> The semantics of the pseudo-header fields and setting are identical to those in HTTP/2 as defined RFC8441.  HTTP3 requires that HTTP/3 settings be registered separately for HTTP/3.  The </ins> SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2.
Code change:
Update query parameter generation in examples,
I verified that B.2.3 is fixed, but did not implement the "ttrp" example.
The Example from uses the following request defined in B.2 The signing string is meant to be But that does not work because in the request we have and the date in the signing string is one minute later
Thanks, all the examples need to get re-generated and I'll work on that soon. The current generation script is at URL ... it's very manual right now but I'm thinking of reworking it to do actual HTTP message parsing under the hood like we have at URL instead, so we don't end up with inconsistencies like this in the results.
I am also developing a test suite for the examples in the spec, which is why I am reporting the bugs I find here :-) That can help you later verify that your new setup is correct. I just found a last error in the Signing String. The Signing string given there is my test tells me that the diff should be: But the implementation having is correct I think.
Examples have been regenerated by , please check the new example for consistency.
Just saw this other comment, yes it looks like there's a bug in the query value generator that drops the question mark!
Btw. My EU project just ended, so I am looking for extension projects. But perhaps someone here knows companies that need me to work on the implementation? (Ie,Java or JS or Scala)... I don't really know where one can ask this. A bit of a specialized thing :-)
NAME please check the updated examples in -- I re-ran the script with some bugfixes in place which should fix both B.2.3 and the TTRP example in the appendix.

Related discussion:
text: The component identifier is a dictionary member identifier or a named query parameter identifier that references a member that is not present in the component value, or whose value is malformed. <del> E.g., the identifier is ""example-dictionary";key="c"" and the value of the "Example-Dictionary" header field is "a=1, b=2", which does not have the "c" value. </del> <ins> E.g., the identifier is ""example-dict";key="c"" and the value of the "Example-Dict" header field is "a=1, b=2", which does not have the "c" value. </ins> In the following non-normative example, the HTTP message being signed is the following request:
Code change:
This spec uses 'body' and 'payload' a lot; I think most should be 'content'.

Related discussion:
text: As an alternative to using GET, many implementations make use of the HTTP POST method to perform queries, as illustrated in the example below.  In this case, the input parameters to the search operation <del> are passed along within the request payload as opposed to using the </del> <ins> are passed along within the request content as opposed to using the </ins> request URI. A typical use of HTTP POST for requesting a search
Code change:
This spec uses 'body' and 'payload' a lot; I think most should be 'content'.

Related discussion:
text: The QUERY method provides a solution that spans the gap between the use of GET and POST.  As with POST, the input to the query operation <del> is passed along within the payload of the request rather than as part </del> <ins> is passed along within the content of the request rather than as part </ins> of the request URI.  Unlike POST, however, the method is explicitly safe and idempotent, allowing functions like caching and automatic retries to operate.
Code change:
This spec uses 'body' and 'payload' a lot; I think most should be 'content'.

Related discussion:
text: HTTP GET method, which requests that a server return a representation of the resource identified by the target URI (as defined by RFCHTTP), the QUERY method is used to ask the server to perform a query <del> operation (described by the request payload) over some set of data scoped to the effective request URI.  The payload returned in </del> <ins> operation (described by the request content) over some set of data scoped to the effective request URI.  The content returned in </ins> response to a QUERY cannot be assumed to be a representation of the resource identified by the effective request URI. <del> The body payload of the request defines the query.  Implementations MAY use a request body of any content type with the QUERY method, </del> <ins> The content of the request defines the query.  Implementations MAY use a request content of any media type with the QUERY method, </ins> provided that it has appropriate query semantics. QUERY requests are both safe and idempotent with regards to the
Code change:
Sounds like a good idea to me.
from the editor's copy >7. "message/bhttp" Media Type The message/http media type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and encodings. is this a typo and it should be >The message/bhttp media type ? Also defining this type at section 7 seems quite late. The first instance of is in examples in section 5, easily missed due to the similarity and prevalence of that is mentioned as a contrasting type. I think it would help a bit to talk about the bhttp type earlier. Probably in the introduction, just after you talk about the old type.
LGTM thank you

Related discussion:
text: including either header compression (HPACK, QPACK) or a generic framing layer. <del> This format provides an alternative to the "message/http" content type defined in MESSAGING.  A binary format permits more efficient encoding and processing of messages.  A binary format also reduces exposure to security problems related to processing of HTTP messages. </del> <ins> This format defines "message/bhttp", a binary alternative to the "message/http" content type defined in MESSAGING.  A binary format permits more efficient encoding and processing of messages.  A binary format also reduces exposure to security problems related to processing of HTTP messages. </ins> Two modes for encoding are described: