jiebi/CodeConvo huggingface dataset:
Code change:
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!

Related discussion:
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
Code change:
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!

Related discussion:
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> <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
Code change:
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.

Related discussion:
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.
Code change:
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.

Related discussion:
text: and a final response that were sent from the origin server in response to a revalidation request. <ins> A server MAY emit multiple 103 (Early Hints) responses with additional header fields as new information becomes available while the request is being processed.  It does not need to repeat the fields that were already emitted, though it doesn't have to exclude them either.  The client can consider any combination of header fields received in multiple 103 (Early Hints) responses when anticipating the list of header fields expected in the final response. The following example illustrates a series of responses that a server might emit.  In the example, the server uses two 103 (Early Hints) responses to notify the client that it is likely to send three Link header fields in the final response.  Two of the three expected header fields are found in the final response.  The other header field is replaced by another Link header field that contains a different value. </ins> 3. Some clients might have issues handling 103 (Early Hints), since
Code change:
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!

Related discussion:
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> <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). <del> The term request-uri is defined in Section 5.1.2 of RFC2616. </del> <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
Code change:
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!

Related discussion:
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> <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.
Code change:
(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

Related discussion:
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> <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
Code change:
(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

Related discussion:
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> <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
Code change:
(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

Related discussion:
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> <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
Code change:
(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

Related discussion:
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> <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.
Code change:
(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

Related discussion:
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> <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:
Code change:
(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

Related discussion:
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> <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.
Code change:
(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

Related discussion:
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> <ins> be safely processed MUST be rejected using the 425 (Too Early) status </ins> code. 5.2. <del> A 4NN (Too Early) status code indicates that the server is unwilling </del> <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 <del> early data MUST automatically retry the request when receiving a 4NN </del> <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. <del> Intermediaries that receive a 4NN (Too Early) status code MAY </del> <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 <del> 4NN (Too Early) status code. </del> <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" <del> header field is set to "1".  A server SHOULD NOT emit the 4NN status </del> <ins> header field is set to "1".  A server SHOULD NOT emit the 425 status </ins> code unless one of these conditions is met. <del> The 4NN (Too Early) status code is not cacheable by default.  Its </del> <ins> The 425 (Too Early) status code is not cacheable by default.  Its </ins> payload is not the representation of any identified resource. 6.
Code change:
(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

Related discussion:
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> <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 <del> the TLS handshake completes, or send a 4NN (Too Early) status code in </del> <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.
Code change:
(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

Related discussion:
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> <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.
Code change:
(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

Related discussion:
text: (empty) <del> This document registers the 4NN (Too Early) status code in the </del> <ins> This document registers the 425 (Too Early) status code in the </ins> "Hypertext Transfer Protocol (HTTP) Status Code" registry established in RFC7231. <del> 4NN </del> <ins> 425 </ins> Too Early
Code change:
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.

Related discussion:
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> <ins> early data. </ins> Intermediaries that receive a 4NN (Too Early) status code MAY automatically retry requests after allowing the handshake to complete
Code change:
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

Related discussion:
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
Code change:
mention the syntax update the reference type the citations consistently
1) It should be RFC 5234, not RFC 4234 2) If it's there, it should actually be mentioned somewhere in the spec.

Related discussion:
text: "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. <ins> 1.2. This document cites productions in Augmented Backus-Naur Form (ABNF) productions from RFC7233, using the notation defined in RFC5234. </ins> 2. This document recommends a two-step process for accessing resources
Code change:
This makes mitigation mandatory. Either receive a signal that early data is safe for the given resource, or apply the mitigations. That's consistent with the other text.
LGTM

Related discussion:
text: It is RECOMMENDED that origin servers allow resources to explicitly configure whether early data is appropriate in requests.  Absent such <del> explicit information, they SHOULD mitigate against early data in requests that have unsafe methods, using the techniques outlined above. </del> <ins> explicit information, origin servers MUST either reject early data or implement the techniques described in this document for ensuring that requests are not processed prior to TLS handshake completion. </ins> A request might be sent partially in early data with the remainder of the request being sent after the handshake completes.  This does not
Code change:
I think that these are the main places where we weren't clear enough about the relevant TLS role.
LGTM

Related discussion:
text: The "Early-Data" header field is included in requests that might have been forwarded by an intermediary prior to the TLS handshake <del> completing. </del> <ins> with its client completing. </ins> The 425 (Too Early) status code is defined for a server to indicate that a request could not be processed due to the
Code change:
I think that these are the main places where we weren't clear enough about the relevant TLS role.
LGTM

Related discussion:
text: For example: An intermediary that forwards a request prior to the completion of <del> the TLS handshake MUST send it with the "Early-Data" header field set to "1" (i.e., it adds it if not present in the request).  An intermediary MUST use the "Early-Data" header field if it might have forwarded the request prior to handshake completion (see be- consistent for details). </del> <ins> the TLS handshake with its client MUST send it with the "Early-Data" header field set to "1" (i.e., it adds it if not present in the request).  An intermediary MUST use the "Early-Data" header field if it might have forwarded the request prior to handshake completion (see be-consistent for details). </ins> An intermediary MUST NOT remove this header field if it is present in a request.
Code change:
John Mattsson pointed out that we didn't really discuss the risks of use of early data. That's fair, but we don't need to. This rewrites the abstract.
Just one fix : s/mechanisms that allows/mechanisms that allow/ Nice overall.

Related discussion:
text: Abstract <del> This document explains the risks of using early data for HTTP and describes techniques for reducing them.  In particular, it defines a mechanism that enables clients to communicate with servers about early data, to assure correct operation. </del> <ins> Using TLS early data creates an exposure to the possibility of a replay attack.  This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data.  Techniques are described that use these mechanisms to mitigate the risk of replay. </ins> 1.
Code change:
Hopefully none of this collides with other PRs in flight.
I think it's fine with this. Adding a bit of pragmatism as you did in the last commit also reminds that the low cost of retrying is not worth a lot of trouble :-)

Related discussion:
text: If the server receives multiple requests in early data, it can determine whether to defer HTTP processing on a per-request basis. <del> This may require buffering the responses to preserve ordering in HTTP/1.1. </del> The server can cause a client to retry a request and not use early data by responding with the 425 (Too Early) status code (status),
Code change:
Hopefully none of this collides with other PRs in flight.
I think it's fine with this. Adding a bit of pragmatism as you did in the last commit also reminds that the low cost of retrying is not worth a lot of trouble :-)

Related discussion:
text: If the server rejects early data at the TLS layer, a client MUST start sending again as though the connection was new.  This could entail using a different negotiated protocol ALPN than the one <del> optimistically used for the early data.  If HTTP/2 is selected after early data is rejected, a client sends another connection preface. Any requests sent in early data MUST be sent again, unless the client decides to abandon those requests. </del> <ins> optimistically used for the early data.  Any requests sent in early data MUST be sent again, unless the client decides to abandon those requests. </ins> This automatic retry exposes the request to a potential replay attack.  An attacker sends early data to one server instance that