jiebi/TextFlow huggingface dataset:
Original 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>  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>  3.

Reviewer comments:
update canonicalization rules, remove weird headers from examples changed dictionaries and messages. updated crypto primative functions regenerate examples

Revised 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.  <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  <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.
Original 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>  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>  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>  This section contains several common algorithm methods.  The method to use can be communicated through the algorithm signature parameter

Reviewer comments:
update canonicalization rules, remove weird headers from examples changed dictionaries and messages. updated crypto primative functions regenerate examples

Revised text:
HTTP Message signatures MAY use any cryptographic digital signature or MAC method that is appropriate for the key material, environment,  <ins> and needs of the signer and verifier. </ins> Each signature algorithm method takes as its input the signature  <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  <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
Original 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>  <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>  And a signature output value of:

Reviewer comments:
update canonicalization rules, remove weird headers from examples changed dictionaries and messages. updated crypto primative functions regenerate examples

Revised text:
client in fields when forwarding the request to a service host, including a signature over the client's original signature values.  <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>  <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:
Original 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>  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>  server to allow the client to use Extended CONNECT. The HTTP/3 stream closure is also analogous to the TCP connection

Reviewer comments:
pseudo-header is hyphenated per [HTTP3], and expand out a "headers" straggler.
Thanks, this is great!

Revised text:
RFC8441 defines a mechanism for running the WebSocket Protocol RFC6455 over a single stream of an HTTP/2 connection.  It defines an  <ins> Extended CONNECT method which specifies a new ":protocol" pseudo- </ins> header field and new semantics for the ":path" and ":authority"  <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
Original 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>  SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2.

Reviewer comments:
pseudo-header is hyphenated per [HTTP3], and expand out a "headers" straggler.
Thanks, this is great!

Revised text:
FIN bit on the stream (HTTP3).  RST exceptions are represented with an stream error (HTTP3) of type H3_REQUEST_CANCELLED (HTTP3).  <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.
Original 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>  In the following non-normative example, the HTTP message being signed is the following request:

Reviewer comments:
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.

Revised 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.  <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:
Original 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>  request URI. A typical use of HTTP POST for requesting a search

Reviewer comments:
This spec uses 'body' and 'payload' a lot; I think most should be 'content'.

Revised 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  <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
Original 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>  of the request URI.  Unlike POST, however, the method is explicitly safe and idempotent, allowing functions like caching and automatic retries to operate.

Reviewer comments:
This spec uses 'body' and 'payload' a lot; I think most should be 'content'.

Revised 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  <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.
Original 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>  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>  provided that it has appropriate query semantics. QUERY requests are both safe and idempotent with regards to the

Reviewer comments:
This spec uses 'body' and 'payload' a lot; I think most should be 'content'.

Revised 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  <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.  <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
Original 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>  Two modes for encoding are described:

Reviewer comments:
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

Revised text:
including either header compression (HPACK, QPACK) or a generic framing layer.  <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:
Original text:
5.1. <del> The example HTTP/1.1 message in ex-request shows the content of a "message/http". </del>  Valid HTTP/1.1 messages require lines terminated with CRLF (the two bytes 0x0a and 0x0d).  For simplicity and consistency, the content of

Reviewer comments:
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

Revised text:
5.1.  <ins> The example HTTP/1.1 message in ex-request shows the content in the "message/http" format. </ins> Valid HTTP/1.1 messages require lines terminated with CRLF (the two bytes 0x0a and 0x0d).  For simplicity and consistency, the content of
Original text:
7. <del> The message/http media type can be used to enclose a single HTTP </del>  request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and encodings.

Reviewer comments:
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

Revised text:
7.  <ins> The "message/bhttp" media type can be used to enclose a single HTTP </ins> request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and encodings.
Original text:
A commitment is not bound to a particular alternative service. Clients are able to use alternative services that they become aware of.  However, once a valid and authenticated commitment has been <del> received, clients SHOULD NOT use an unauthenticated alternative service.  Where there is an active commitment, clients SHOULD ignore advertisements for unsecured alternative services.  A client MAY send requests to an unauthenticated origin in an attempt to discover potential alternative services, but these requests SHOULD be entirely generic and avoid including credentials. </del>  5.3.

Reviewer comments:
…ng authentication if Erik is cool with it.
NAME
ETIMEDOUT NAME if you object please reopen.

Revised text:
A commitment is not bound to a particular alternative service. Clients are able to use alternative services that they become aware of.  However, once a valid and authenticated commitment has been  <ins> received, clients SHOULD NOT use an alternative service without both reasonable assurances (see auth) and strong authentication.  Where there is an active commitment, clients SHOULD ignore advertisements for unsecured alternative services. A client MAY send requests to an unauthenticated origin in an attempt to discover potential alternative services, but these requests SHOULD be entirely generic and avoid including credentials. </ins> 5.3.
Original text:
Many of these same restrictions are shared by HTTP/2 H2 and HTTP/3 H3.  7. The "message/bhttp" media type can be used to enclose a single HTTP

Reviewer comments:
What does it mean for a client to send, for example, a CONNECT request in the binary message. Is that permitted or prohibited?
I don't think that it needs to be prohibited. It's just not going to do anything that makes any sense. Worth a note perhaps.
I guess it could work if the thing you're delivering the binary message to actually actions the CONNECT, exchanging tunneled bytes would just look like content.
You would need somewhere for those bytes to go. A valid CONNECT request doesn't include a body. It's nonsensical basically.

Revised text:
Many of these same restrictions are shared by HTTP/2 H2 and HTTP/3 H3. <ins> Note that while some messages - CONNECT or upgrade requests in particular - can be represented using this format, doing so serves no purpose as these requests are used to affect protocol behavior, which this format cannot do without additional mechanisms. </ins> 7. The "message/bhttp" media type can be used to enclose a single HTTP
Original text:
For field names, byte values that are not permitted in an HTTP field name cause the message to be invalid; see HTTP for a definition of <del> what is valid and invalid for handling of invalid messages. Field names and values MUST be constructed and validated according to the rules of H2.  A recipient MUST treat a message that contains field values that would cause an HTTP/2 message to be malformed (H2) as invalid; see invalid. </del>  The same field name can be repeated in multiple field lines; see HTTP for the semantics of repeated field names and rules for combining values.  Like HTTP/2, this format has an exception for the combination of multiple instances of the "Cookie" field.  Instances of fields with the ASCII-encoded value of "cookie" are combined using a semicolon

Reviewer comments:
The HTTP/2 rules are related to field value validation, so move them there. The rules about Connection fields are not necessary, but it won't hurt to be clearer.
the rules of Section 8.2.1 of [H2]. A recipient MUST treat a message that contains field values that would cause an HTTP/2 message to be malformed (Section 8.1.1 of [H2]) as invalid; see Section 4. Those references are doing a lot of work -- but does it also include 8.2.2? I.e., are and friends allowed? It's ambiguous, because the text implies all things that make it malformed, but only points to one source.
No point duplicating that work, but I agree that it might be unclear as stated. Does this split make it clearer? I'll make a PR with those changes in context. (I think that the latter is consistent with what you and NAME are discussing on-list, though I need to spend a bit more time on understanding that.)
I think it does the job, indeed!

Revised text:
For field names, byte values that are not permitted in an HTTP field name cause the message to be invalid; see HTTP for a definition of  <ins> what is valid and invalid for handling of invalid messages.  A recipient MUST treat a message that contains field values that would cause an HTTP/2 message to be malformed according to H2 as invalid; see invalid. </ins> The same field name can be repeated in multiple field lines; see HTTP for the semantics of repeated field names and rules for combining values. <ins> Fields that relate to connections (HTTP) cannot be used to produce the effect on a connection in this context.  These fields SHOULD be removed when constructing a binary message.  However, they do not cause a message to be invalid (invalid); permitting these fields allows a binary message to capture the content of a messages that are exchanged in a protocol context. </ins> Like HTTP/2, this format has an exception for the combination of multiple instances of the "Cookie" field.  Instances of fields with the ASCII-encoded value of "cookie" are combined using a semicolon