jiebi/TextFlow huggingface dataset:
Original text:
client that the server is likely to send a final response with the header fields included in the informational response. <del> A server MUST NOT include Content-Length, Transfer-Encoding, or any hop-by-hop header fields (RFC7230, Section 6.1) in a 103 (Early Hints) response. </del>  A client can speculatively evaluate the header fields included in a 103 (Early Hints) response while waiting for the final response.  For example, a client might recognize a Link header field value containing the relation type "preload" and start fetching the target <del> resource. However, these header fields only provide hints to the client; they do not replace the header fields on the final response.  Aside from performance optimizations, such evaluation of the 103 (Early Hints) response's header fields MUST NOT affect how the final response is processed.  A client MUST NOT interpret the 103 (Early Hints) response header fields as if they applied to the informational </del>  response itself (e.g., as metadata about the 103 (Early Hints) response). <del> An intermediary MAY drop the informational response.  It MAY send HTTP/2 (RFC7540) server pushes using the information found in the 103 (Early Hints) response. </del> The following example illustrates a typical message exchange that involves a 103 (Early Hints) response.

Reviewer comments:
removes statements that are either redundant or contradicts with RFC 7230, 7231 clarifies how a server is expected to do when generating a response
While it is not required to specify how an intermediary might behave, doing so might be beneficial as suggested in URL We could possibly have something like the following below the example.
works for me.
NAME Thank you for the answer. Adopted the text (with nits) in d0903d6.
NAME Thank you for the review!
Looks good to me!

Revised text:
client that the server is likely to send a final response with the header fields included in the informational response.  <ins> Typically, a server will include the header fields sent in a 103 (Early Hints) response in the final response as well.  However, there might be cases when this is not desirable, such as when the server learns that they are not correct before the final response is sent. </ins> A client can speculatively evaluate the header fields included in a 103 (Early Hints) response while waiting for the final response.  For example, a client might recognize a Link header field value containing the relation type "preload" and start fetching the target  <ins> resource.  However, these header fields only provide hints to the client; they do not replace the header fields on the final response. Aside from performance optimizations, such evaluation of the 103 (Early Hints) response's header fields MUST NOT affect how the final response is processed.  A client MUST NOT interpret the 103 (Early Hints) response header fields as if they applied to the informational </ins> response itself (e.g., as metadata about the 103 (Early Hints) response).  The following example illustrates a typical message exchange that involves a 103 (Early Hints) response.
Original text:
Server response:  3. Some clients might have issues handling 103 (Early Hints), since

Reviewer comments:
removes statements that are either redundant or contradicts with RFC 7230, 7231 clarifies how a server is expected to do when generating a response
While it is not required to specify how an intermediary might behave, doing so might be beneficial as suggested in URL We could possibly have something like the following below the example.
works for me.
NAME Thank you for the answer. Adopted the text (with nits) in d0903d6.
NAME Thank you for the review!
Looks good to me!

Revised text:
Server response: <ins> As is the case with any informational response, a server might emit more than one 103 (Early Hints) response prior to sending a final response.  This can happen for example when a caching intermediary generates a 103 (Early Hints) response based on the header fields of a stale-cached response, then forwards a 103 (Early Hints) response and a final response that were sent from the origin server in response to a revalidation request. </ins> 3. Some clients might have issues handling 103 (Early Hints), since
Original text:
requests to different origins onto a single persistent connection. Therefore, a server might refrain from sending Early Hints over <del> HTTP/1.1 unless when the client is known to handle informational responses correctly. </del>  HTTP/2 clients are less likely to suffer from incorrect framing since handling of the response header fields does not affect how the end of

Reviewer comments:
removes statements that are either redundant or contradicts with RFC 7230, 7231 clarifies how a server is expected to do when generating a response
While it is not required to specify how an intermediary might behave, doing so might be beneficial as suggested in URL We could possibly have something like the following below the example.
works for me.
NAME Thank you for the answer. Adopted the text (with nits) in d0903d6.
NAME Thank you for the review!
Looks good to me!

Revised text:
requests to different origins onto a single persistent connection. Therefore, a server might refrain from sending Early Hints over  <ins> HTTP/1.1 unless the client is known to handle informational responses correctly. </ins> HTTP/2 clients are less likely to suffer from incorrect framing since handling of the response header fields does not affect how the end of
Original text:
response itself (e.g., as metadata about the 103 (Early Hints) response).  The following example illustrates a typical message exchange that involves a 103 (Early Hints) response.

Reviewer comments:
Clarify that the disappearance of a header field (that once existed in a 103 response) from the following 103 responses does not indicate the retraction of the expectation that the header field will be included in the final response.
ecb2c7e clarifies the general rule that this PR relies on (i.e. the nonexistence of a header field in the 103 response cannot be used as a signal that the header field will be absent in the final response), at the same time addressing Spencer Dawkins' suggestion to clarify that "the server can add header fields in the 200 that were not present in the 103."
In section 2. "103 Early Hints" the last paragraph describes that 103 can be send multiple time. The given example reads as if a server may correct its previous 103 that is made from a cached resource. So the following 103 are correcting the older ones, they are only adding headers to the previous ones or are they replacing them completely? Maybe sentence clarifying this would be good.
This is an interesting question. I think that we should agree on what the expected behavior is before discussing how (or if) we should update the text. Regarding the question, I think that we should consider two (or more) Early Hints responses as expectations from different sources, rather than considering the following one to update the earlier ones. The reason I think so is because nonexistence of a header field in the 103 response does not imply that the header field will not exist in the final response, since we are not required to include in 103 response all the headers that are expected to be included in the final response. So consider the following example: a caching intermediary might generate an Early Hints response from a stale-cached response. That Early Hints response could contain a header field that will never be included within an Early Hints response sent from the origin. In such case, considering both of the Early Hints responses as genuine makes the most sense.

Revised text:
response itself (e.g., as metadata about the 103 (Early Hints) response). <ins> A server MAY use a 103 (Early Hints) response to indicate only some of the header fields that are expected to be found in the final response.  A client SHOULD NOT interpret the nonexistence of a header field in a 103 (Early Hints) response as a speculation that the header field is unlikely to be part of the final response. </ins> The following example illustrates a typical message exchange that involves a 103 (Early Hints) response.
Original text:
The terms "user agent", "client", "server", "proxy", and "origin server" have the same meaning as in the HTTP/1.1 specification <del> (RFC2616, Section 1.3). </del>  The request-host is the name of the host, as known by the user agent, to which the user agent is sending an HTTP request or from which it is receiving an HTTP response (i.e., the name of the host to which it sent the corresponding HTTP request). <del> The term request-uri is defined in Section 5.1.2 of RFC2616. </del>  Two sequences of octets are said to case-insensitively match each other if and only if they are equivalent under the i;ascii-casemap

Reviewer comments:
I left the term "request-uri" untouched (it was renamed in the base spec because it's not always a URI). We may want to change that separately, or even refer to the effective request URI (URL)
NAME - ping?
LGTM, thank you for the patch, and for the ping!

Revised text:
The terms "user agent", "client", "server", "proxy", and "origin server" have the same meaning as in the HTTP/1.1 specification  <ins> (RFC7230, Section 2). </ins> The request-host is the name of the host, as known by the user agent, to which the user agent is sending an HTTP request or from which it is receiving an HTTP response (i.e., the name of the host to which it sent the corresponding HTTP request).  <ins> The term request-uri refers to "request-target" as defined in Section 5.3 of RFC7230. </ins> Two sequences of octets are said to case-insensitively match each other if and only if they are equivalent under the i;ascii-casemap
Original text:
Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field.  The usual mechanism for folding HTTP headers <del> fields (i.e., as defined in RFC2616) might change the semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such folding. </del>  3.1.

Reviewer comments:
I left the term "request-uri" untouched (it was renamed in the base spec because it's not always a URI). We may want to change that separately, or even refer to the effective request URI (URL)
NAME - ping?
LGTM, thank you for the patch, and for the ping!

Revised text:
Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field.  The usual mechanism for folding HTTP headers  <ins> fields (i.e., as defined in Section 3.2.2 of RFC7230) might change the semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such folding. </ins> 3.1.
Original text:
HTTP/1.1. The server can cause a client to retry a request and not use early <del> data by responding with the 4NN (Too Early) status code (status), </del>  in cases where the risk of replay is judged too great. For a given request, the level of tolerance to replay risk is

Reviewer comments:
(I accidentally put this on master without noticing earlier, sorry.)
Can we just have 425 now that it's official-ish? From martinthomson/http-replay

Revised text:
HTTP/1.1. The server can cause a client to retry a request and not use early  <ins> data by responding with the 425 (Too Early) status code (status), </ins> in cases where the risk of replay is judged too great. For a given request, the level of tolerance to replay risk is
Original text:
the TLS layer.  TLS only permits a server to accept all early data, or none of it.  Once a server has decided to accept early data, it MUST process all requests in early data, even if the server rejects <del> the request by sending a 4NN (Too Early) response. </del>  A server can limit the amount of early data with the "max_early_data_size" field of the "early_data" TLS extension.  This

Reviewer comments:
(I accidentally put this on master without noticing earlier, sorry.)
Can we just have 425 now that it's official-ish? From martinthomson/http-replay

Revised text:
the TLS layer.  TLS only permits a server to accept all early data, or none of it.  Once a server has decided to accept early data, it MUST process all requests in early data, even if the server rejects  <ins> the request by sending a 425 (Too Early) response. </ins> A server can limit the amount of early data with the "max_early_data_size" field of the "early_data" TLS extension.  This
Original text:
server accepts early data multiple times (though this would be in violation of requirements in TLS). <del> Clients that use early data MUST retry requests upon receipt of a 4NN </del>  (Too Early) status code; see status. An intermediary MUST NOT use early data when forwarding a request

Reviewer comments:
(I accidentally put this on master without noticing earlier, sorry.)
Can we just have 425 now that it's official-ish? From martinthomson/http-replay

Revised text:
server accepts early data multiple times (though this would be in violation of requirements in TLS).  <ins> Clients that use early data MUST retry requests upon receipt of a 425 </ins> (Too Early) status code; see status. An intermediary MUST NOT use early data when forwarding a request
Original text:
The "Early-Data" header field is included in requests that are received in early data. <del> The 4NN (Too Early) status code is defined for a server to </del>  indicate that a request could not be processed due to the consequences of a possible replay attack.

Reviewer comments:
(I accidentally put this on master without noticing earlier, sorry.)
Can we just have 425 now that it's official-ish? From martinthomson/http-replay

Revised text:
The "Early-Data" header field is included in requests that are received in early data.  <ins> The 425 (Too Early) status code is defined for a server to </ins> indicate that a request could not be processed due to the consequences of a possible replay attack.
Original text:
The "Early-Data" request header field indicates that the request has been conveyed in early data, and additionally indicates that a client <del> understands the 4NN (Too Early) status code. </del>  It has just one valid value: "1".  Its syntax is defined by the following ABNF ABNF:

Reviewer comments:
(I accidentally put this on master without noticing earlier, sorry.)
Can we just have 425 now that it's official-ish? From martinthomson/http-replay

Revised text:
The "Early-Data" request header field indicates that the request has been conveyed in early data, and additionally indicates that a client  <ins> understands the 425 (Too Early) status code. </ins> It has just one valid value: "1".  Its syntax is defined by the following ABNF ABNF:
Original text:
The "Early-Data" header field is not intended for use by user agents (that is, the original initiator of a request).  Sending a request in early data implies that the client understands this specification and <del> is willing to retry a request in response to a 4NN (Too Early) status </del>  code.  A user agent that sends a request in early data does not need to include the "Early-Data" header field.

Reviewer comments:
(I accidentally put this on master without noticing earlier, sorry.)
Can we just have 425 now that it's official-ish? From martinthomson/http-replay

Revised text:
The "Early-Data" header field is not intended for use by user agents (that is, the original initiator of a request).  Sending a request in early data implies that the client understands this specification and  <ins> is willing to retry a request in response to a 425 (Too Early) status </ins> code.  A user agent that sends a request in early data does not need to include the "Early-Data" header field.
Original text:
field safe for processing by waiting for the handshake to complete. A request that is marked with Early-Data was sent in early data on a previous hop.  Requests that contain the Early-Data field and cannot <del> be safely processed MUST be rejected using the 4NN (Too Early) status </del>  code. 5.2. <del> A 4NN (Too Early) status code indicates that the server is unwilling </del>  to risk processing a request that might be replayed. Clients (user-agents and intermediaries) that sent the request in <del> early data MUST automatically retry the request when receiving a 4NN </del>  (Too Early) response status code.  Such retries MUST NOT be sent in early data. <del> Intermediaries that receive a 4NN (Too Early) status code MAY </del>  automatically retry requests after allowing the handshake to complete unless the original request contained the "Early-Data" header field when it was received.  Otherwise, an intermediary MUST forward the <del> 4NN (Too Early) status code. </del>  The server cannot assume that a client is able to retry a request unless the request is received in early data or the "Early-Data" <del> header field is set to "1".  A server SHOULD NOT emit the 4NN status </del>  code unless one of these conditions is met. <del> The 4NN (Too Early) status code is not cacheable by default.  Its </del>  payload is not the representation of any identified resource. 6.

Reviewer comments:
(I accidentally put this on master without noticing earlier, sorry.)
Can we just have 425 now that it's official-ish? From martinthomson/http-replay

Revised text:
field safe for processing by waiting for the handshake to complete. A request that is marked with Early-Data was sent in early data on a previous hop.  Requests that contain the Early-Data field and cannot  <ins> be safely processed MUST be rejected using the 425 (Too Early) status </ins> code. 5.2.  <ins> A 425 (Too Early) status code indicates that the server is unwilling </ins> to risk processing a request that might be replayed. Clients (user-agents and intermediaries) that sent the request in  <ins> early data MUST automatically retry the request when receiving a 425 </ins> (Too Early) response status code.  Such retries MUST NOT be sent in early data.  <ins> Intermediaries that receive a 425 (Too Early) status code MAY </ins> automatically retry requests after allowing the handshake to complete unless the original request contained the "Early-Data" header field when it was received.  Otherwise, an intermediary MUST forward the  <ins> 425 (Too Early) status code. </ins> The server cannot assume that a client is able to retry a request unless the request is received in early data or the "Early-Data"  <ins> header field is set to "1".  A server SHOULD NOT emit the 425 status </ins> code unless one of these conditions is met.  <ins> The 425 (Too Early) status code is not cacheable by default.  Its </ins> payload is not the representation of any identified resource. 6.
Original text:
A gateway that forwards requests that were received in early data MUST only do so if it knows that the server that receives those requests understands the "Early-Data" header field and will correctly <del> generate a 4NN (Too Early) status code.  A gateway that isn't certain </del>  about server support SHOULD either delay forwarding the request until <del> the TLS handshake completes, or send a 4NN (Too Early) status code in </del>  response.  A gateway that is uncertain about whether an origin server supports the "Early-Data" header field SHOULD disable early data.

Reviewer comments:
(I accidentally put this on master without noticing earlier, sorry.)
Can we just have 425 now that it's official-ish? From martinthomson/http-replay

Revised text:
A gateway that forwards requests that were received in early data MUST only do so if it knows that the server that receives those requests understands the "Early-Data" header field and will correctly  <ins> generate a 425 (Too Early) status code.  A gateway that isn't certain </ins> about server support SHOULD either delay forwarding the request until  <ins> the TLS handshake completes, or send a 425 (Too Early) status code in </ins> response.  A gateway that is uncertain about whether an origin server supports the "Early-Data" header field SHOULD disable early data.
Original text:
through the replay of requests that are expensive to handle.  A server that is under load SHOULD prefer rejecting TLS early data as a whole rather than accepting early data and selectively processing <del> requests.  Generating a 503 (Service Unavailable) or 4NN (Too Early) </del>  status code often leads to clients retrying requests, which could result in increased load.

Reviewer comments:
(I accidentally put this on master without noticing earlier, sorry.)
Can we just have 425 now that it's official-ish? From martinthomson/http-replay

Revised text:
through the replay of requests that are expensive to handle.  A server that is under load SHOULD prefer rejecting TLS early data as a whole rather than accepting early data and selectively processing  <ins> requests.  Generating a 503 (Service Unavailable) or 425 (Too Early) </ins> status code often leads to clients retrying requests, which could result in increased load.
Original text:
(empty) <del> This document registers the 4NN (Too Early) status code in the </del>  "Hypertext Transfer Protocol (HTTP) Status Code" registry established in RFC7231. <del> 4NN </del>  Too Early

Reviewer comments:
(I accidentally put this on master without noticing earlier, sorry.)
Can we just have 425 now that it's official-ish? From martinthomson/http-replay

Revised text:
(empty)  <ins> This document registers the 425 (Too Early) status code in the </ins> "Hypertext Transfer Protocol (HTTP) Status Code" registry established in RFC7231.  <ins> 425 </ins> Too Early
Original text:
Clients (user-agents and intermediaries) that sent the request in early data MUST automatically retry the request when receiving a 4NN (Too Early) response status code.  Such retries MUST NOT be sent in <del> early data, and SHOULD NOT be sent if the TLS handshake on the original connection does not successfully complete. </del>  Intermediaries that receive a 4NN (Too Early) status code MAY automatically retry requests after allowing the handshake to complete

Reviewer comments:
NAME was confused by the text here and I confess that I don't remember why it was added. There are actually esoteric cases where you get server data that you can read before the handshake is complete (QUIC tends to enable that sort of mess), but there is no circumstance where the client can read the 425 but can't also determine whether that the handshake is not done to its satisfaction. The client might decide that it wants to abort and not provide a certificate or something, but most implementations don't really allow that sort of messing around.

Revised text:
Clients (user-agents and intermediaries) that sent the request in early data MUST automatically retry the request when receiving a 4NN (Too Early) response status code.  Such retries MUST NOT be sent in  <ins> early data. </ins> Intermediaries that receive a 4NN (Too Early) status code MAY automatically retry requests after allowing the handshake to complete
Original text:
TLS handshake completes, then all instances of the server need to agree and either reject the request or delay processing.  6.3. Accepting early data exposes a server to potential denial of service

Reviewer comments:
This text from Kyle Rose highlights the decision process. If any node might make a different decision about processing early data, then this node has to wait.
I like it, +1

Revised text:
TLS handshake completes, then all instances of the server need to agree and either reject the request or delay processing. <ins> A server MUST NOT act on early data before the handshake completes if it and any other server instance could make a different decision about how to handle the same data. </ins> 6.3. Accepting early data exposes a server to potential denial of service