jiebi/CodeConvo huggingface dataset:
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: A gateway that forwards requests that were received in early data MUST only do so if it knows that the origin server that receives those requests understands the "Early-Data" header field and will <del> correctly generate a 425 (Too Early) status code.  A gateway that isn't certain about origin server support SHOULD either delay forwarding the request until the TLS handshake with its client completes, or send a 425 (Too Early) status code in response.  A gateway that is uncertain about whether an origin server supports the "Early-Data" header field SHOULD disable early data. </del> <ins> correctly generate a 425 (Too Early) status code.  A gateway that is uncertain about origin server support for a given request SHOULD either delay forwarding the request until the TLS handshake with its client completes, or send a 425 (Too Early) status code in response. A gateway without at least one potential origin server that supports "Early-Data" header field expends significant effort for what can at best be a modest performance benefit from enabling early data.  If no origin server supports early data, disabling early data entirely is more efficient. </ins> 6.2.
Code change:
Thanks NAME and NAME for pushing on this.
I think this is good and can even emphasize how to consistently disable 0-RTT across a cluster for any reason then consistently re-enable it.

Related discussion:
text: gateways) need to agree and either reject the request or delay processing. <ins> Disabling early data, delaying requests, or rejecting requests with the 425 (Too Early) status code are all equally good measures for mitigating replay attacks on requests that might be vulnerable to replay.  Server instances can implement any of these measures and be considered to be consistent, even if different instances use different methods.  Critically, this means that it is possible to employ different mitigations in reaction to other conditions, such as server load. </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.
Code change:
Thanks NAME and NAME for pushing on this.
I think this is good and can even emphasize how to consistently disable 0-RTT across a cluster for any reason then consistently re-enable it.

Related discussion:
text: 6.4. In protocols that deliver data out of order (such as QUIC HQ) early <del> data can arrive after the handshake completes.  This leads to potential ambiguity about the status of requests and could lead to inconsistent treatment (see be-consistent).  Implementations MUST either ensure that any early data that is delivered late is either discarded or consistently identified and processed. </del> <ins> data can arrive after the handshake completes.  A server MAY process requests received in early data after handshake completion if it can rely on other instances correctly handling replays of the same requests. </ins> 7.
Code change:
Note this was manually incorporated into draft-ietf-httpbis-rand-access-live-03

Related discussion:
text: that have indeterminate length representations. Two steps are necessary because of limitations with the Range request <del> header and the Content-Range response header fields.  A server cannot know from a range request that a client wishes to receive a response that does not have a definite end.  More critically, the header fields do not allow the server to signal that a resource has </del> <ins> header fields and the Content-Range response header fields.  A server cannot know from a range request that a client wishes to receive a response that does not have a definite end.  More critically, the header fields do not allow the server to signal that a resource has </ins> indeterminate length without also providing a fixed portion of the resource.
Code change:
Note this was manually incorporated into draft-ietf-httpbis-rand-access-live-03

Related discussion:
text: and leave last-byte-pos absent.  A server that receives a satisfiable byte-range request (with first-byte-pos smaller than the current representation length) may respond with a 206 status code (Partial <del> Content) with a Content-Range header indicating the currently </del> <ins> Content) with a Content-Range header field indicating the currently </ins> satisfiable byte range.  For example: returns a response of the form:
Code change:
Note this was manually incorporated into draft-ietf-httpbis-rand-access-live-03

Related discussion:
text: a live video stream. Unlike a byte-range Range request, a byte-range Content-Range <del> response header cannot be "open ended", per RFC7233: </del> <ins> response header field cannot be "open ended", per RFC7233: </ins> Specifically, last-byte-pos is required in byte-range.  So in order to preserve interoperability with existing HTTP clients, servers,
Code change:
Note this was manually incorporated into draft-ietf-httpbis-rand-access-live-03

Related discussion:
text: In response, a server may indicate that it is supplying a continuously aggregating ("live") response by supplying the client <del> request's last-byte-pos in the Content-Range response header. </del> <ins> request's last-byte-pos in the Content-Range response header field. </ins> For example:
Code change:
Note this was manually incorporated into draft-ietf-httpbis-rand-access-live-03

Related discussion:
text: A server that does return a continuously aggregating ("live") response should return data using chunked transfer coding and not <del> provide a Content-Length header.  A 0-length chunk indicates the end of the transfer, per RFC7230. </del> <ins> provide a Content-Length header field.  A 0-length chunk indicates the end of the transfer, per RFC7230. </ins> 3.
Code change:
Note this was manually incorporated into draft-ietf-httpbis-rand-access-live-03

Related discussion:
text: learn what range the server has currently available and initiate an indeterminate-length transfer.  For example: <del> With the Content-Range response header indicating the (or ranges) available.  For example: </del> <ins> With the Content-Range response header field indicating the (or ranges) available.  For example: </ins> The client can then issue a request for a range starting at the end value (using a very large value for the end of a range) and receive
Code change:
Note this was manually incorporated into draft-ietf-httpbis-rand-access-live-03

Related discussion:
text: learn what range the server has currently available and initiate an indeterminate-length transfer.  For example: <del> With the Content-Range response header field indicating the (or </del> <ins> With the Content-Range response header field indicating the range (or </ins> ranges) available.  For example: The client can then issue a request for a range starting at the end
Code change:
Add SETTINGS prefix to parameter name ENABLECONNECT_PROTOCOL. Fix one typo ("s/a entry/an entry/"). Remove "(type = 0x8)" which is ambigous (what is type?) and redundant with code listed in IANA Considerations section.
thanks

Related discussion:
text: This document adds a new SETTINGS Parameter to those defined by RFC7540, Section 6.5.2. <del> The new parameter is ENABLE_CONNECT_PROTOCOL (type = 0x8).  The value of the parameter MUST be 0 or 1. </del> <ins> The new parameter name is SETTINGS_ENABLE_CONNECT_PROTOCOL.  The value of the parameter MUST be 0 or 1. </ins> <del> Upon receipt of ENABLE_CONNECT_PROTOCOL with a value of 1 a client MAY use the Extended CONNECT definition of this document when </del> <ins> Upon receipt of SETTINGS_ENABLE_CONNECT_PROTOCOL with a value of 1 a client MAY use the Extended CONNECT definition of this document when </ins> creating new streams.  Receipt of this parameter by a server does not have any impact. <del> A sender MUST NOT send a ENABLE_CONNECT_PROTOCOL parameter with the value of 0 after previously sending a value of 1. </del> <ins> A sender MUST NOT send a SETTINGS_ENABLE_CONNECT_PROTOCOL parameter with the value of 0 after previously sending a value of 1. </ins> The use of a SETTINGS Parameter to opt-in to an otherwise incompatible protocol change is a use of "Extending HTTP/2" defined by Section 5.5 of RFC7540.  If a client were to use the provisions of the extended CONNECT method defined in this document without first <del> receiving a ENABLE_CONNECT_PROTOCOL parameter with the value of 1 it would be a protocol violation. </del> <ins> receiving a SETTINGS_ENABLE_CONNECT_PROTOCOL parameter with the value of 1 it would be a protocol violation. </ins> 4.
Code change:
Add SETTINGS prefix to parameter name ENABLECONNECT_PROTOCOL. Fix one typo ("s/a entry/an entry/"). Remove "(type = 0x8)" which is ambigous (what is type?) and redundant with code listed in IANA Considerations section.
thanks

Related discussion:
text: 9. <del> This document establishes a entry for the HTTP/2 Settings Registry </del> <ins> This document establishes an entry for the HTTP/2 Settings Registry </ins> that was established by Section 11.3 of RFC7540. <del> Name: ENABLE_CONNECT_PROTOCOL </del> <ins> Name: SETTINGS_ENABLE_CONNECT_PROTOCOL </ins> Code: 0x8
Code change:
Herve, could you please open an issue for this, so that we can assure that we track the underlying issue? It's OK to merge the proposal if the editor feels that it's helpful, but we need to make sure the WG gets consensus here. Thanks,
Linked to issue .

Related discussion:
text: This specification defines the "Authentication-Info" and "Proxy- Authentication-Info" response header fields for use in HTTP <del> authentication schemes which need to return additional information during or after authentication. </del> <ins> authentication schemes which need to return information once the client's authentication credentials have been accepted. </ins> Editorial Note (To be removed by RFC Editor)
Code change:
Herve, could you please open an issue for this, so that we can assure that we track the underlying issue? It's OK to merge the proposal if the editor feels that it's helpful, but we need to make sure the WG gets consensus here. Thanks,
Linked to issue .

Related discussion:
text: This specification defines the "Authentication-Info" and "Proxy- Authentication-Info" response header fields for use in HTTP <del> authentication schemes (RFC7235) which need to return additional information during or after authentication. </del> <ins> authentication schemes (RFC7235) which need to return information once the client's authentication credentials have been accepted. </ins> Both were previously defined in RFC2617, defining the HTTP "Digest" authentication scheme.  This document generalizes the description for
Code change:
Herve, could you please open an issue for this, so that we can assure that we track the underlying issue? It's OK to merge the proposal if the editor feels that it's helpful, but we need to make sure the WG gets consensus here. Thanks,
Linked to issue .

Related discussion:
text: 3. HTTP authentication schemes can use the Authentication-Info response <del> header field to communicate additional information regarding the successful authentication. </del> <ins> header field to communicate information after the client's authentication credentials have been accepted.  This information can include a finalization message from the server (e.g., it can contain the server authentication). </ins> The field value is a list of parameters (name/value pairs), using the "auth-param" syntax defined in RFC7235.  This specification only
Code change:
Port over of PR from mnot repo. Modified last sentence to avoid to much usage of the word "further".
Thanks!

Related discussion:
text: Furthermore, applications using HTTP MUST NOT re-specify the semantics of HTTP status codes, even if it is only by copying their <del> definition.  They MUST NOT require specific status phrases to be used; the status phrase has no function in HTTP, and is not guaranteed to be preserved by implementations. </del> <ins> definition.  They MUST NOT require specific reason phrases to be used; the reason phrase has no function in HTTP, and is not guaranteed to be preserved by implementations.  The reason phrase is not carried in the RFC7540 message format. </ins> Typically, applications using HTTP will convey application-specific information in the message body and/or HTTP header fields, not the
Code change:
Aligns with other SETTINGS parameter names defined in other docs.
NAME icymi
Thank you for the fix!

Related discussion:
text: 3. A Client SHOULD notify its support for CACHE_DIGEST frames by sending <del> the SENDING_CACHE_DIGEST (0xXXX) SETTINGS parameter. </del> <ins> the SETTINGS_SENDING_CACHE_DIGEST (0xXXX) SETTINGS parameter. </ins> The value of the parameter is a bit-field of which the following bits are defined:
Code change:
Aligns with other SETTINGS parameter names defined in other docs.
NAME icymi
Thank you for the fix!

Related discussion:
text: 4. A server can notify its support for CACHE_DIGEST frame by sending the <del> ACCEPT_CACHE_DIGEST (0x7) SETTINGS parameter.  If the server is tempted to making optimizations based on CACHE_DIGEST frames, it </del> <ins> SETTINGS_ACCEPT_CACHE_DIGEST (0x7) SETTINGS parameter.  If the server is tempted to making optimizations based on CACHE_DIGEST frames, it </ins> SHOULD send the SETTINGS parameter immediately after the connection is established.
Code change:
Aligns with other SETTINGS parameter names defined in other docs.
NAME icymi
Thank you for the fix!

Related discussion:
text: client sends it's first flight data.  When such transport (e.g., TLS 1.3 I-D.ietf-tls-tls13 in full-handshake mode) is used, a client can postpone sending the CACHE_DIGEST frame until it receives a <del> ACCEPT_CACHE_DIGEST settings value. </del> <ins> SETTINGS_ACCEPT_CACHE_DIGEST settings value. </ins> When the underlying transport does not have such property (e.g., TLS 1.3 in 0-RTT mode), a client can reuse the settings value found in
Code change:
This adds a section regarding falsification of Tunnel-Protocol. I didn't expand this to note that WebRTC won't suffer from this problem because the application won't be able to set the header field. That seemed like too much detail.

Related discussion:
text: support the Tunnel-Protocol header field. The value of the Tunnel-Protocol header field could be falsified by a <del> client.  The use of protocols like RFC5246 make it very difficult or impossible to verify that the header field is correct even after a connection is established.  A proxy therefore cannot rely on the value of the Tunnel-Protocol header field as a policy input in all cases. </del> <ins> client.  If the data being sent through the tunnel is encrypted (for example, with RFC5246), then the proxy might not be able to directly inspect the data to verify that the claimed protocol is the one which is actually being used, though a proxy might be able to perform traffic analysis TRAFFIC.  A proxy therefore cannot rely on the value of the Tunnel-Protocol header field as a policy input in all cases. </ins>
Code change:
for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.

Related discussion:
text: configuration of underlying encryption, allowing a "http" URI to be accessed using TLS RFC5246 opportunistically. <del> Currently, "https" URIs require acquiring and configuring a valid </del> <ins> Serving "https" URIs require acquiring and configuring a valid </ins> certificate, which means that some deployments find supporting TLS <del> difficult.  Therefore, this document describes a usage model whereby sites can serve "http" URIs over TLS without being required to support strong server authentication. </del> <ins> difficult.  This document describes a usage model whereby sites can serve "http" URIs over TLS without being required to support strong server authentication. </ins> Opportunistic Security RFC7435 does not provide the same guarantees as using TLS with "https" URIs; it is vulnerable to active attacks,
Code change:
for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.

Related discussion:
text: there will be no "lock icon"). By its nature, this technique is vulnerable to active attacks.  A <del> mechanism for partially mitigating them is described in http-tls.  It does not offer the same level of protection as afforded to "https" URIs, but increases the likelihood that an active attack be detected. </del> <ins> mechanism for partially mitigating them is described in http-tls. </ins> 1.1.
Code change:
for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.

Related discussion:
text: attack can be detected. A final (but significant) goal is to provide for ease of <del> implementation, deployment and operation.  This mechanism should have a minimal impact upon performance, and should not require extensive </del> <ins> implementation, deployment and operation.  This mechanism is expected to have a minimal impact upon performance, and a trivial </ins> administrative effort to configure. 1.2.
Code change:
for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.

Related discussion:
text: A client that places the importance of protection against passive attacks over performance might choose to withhold requests until an encrypted connection is available.  However, if such a connection <del> cannot be successfully established, the client MAY resume its use of </del> <ins> cannot be successfully established, the client can resume its use of </ins> the cleartext connection. A client can also explicitly probe for an alternative service
Code change:
for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.

Related discussion:
text: is proffered by the alternative service, is not necessarily checked for validity, expiration, issuance by a trusted certificate authority or matched against the name in the URI.  Therefore, the alternative <del> service MAY provide any certificate, or even select TLS cipher suites </del> <ins> service can provide any certificate, or even select TLS cipher suites </ins> that do not include authentication. A client MAY perform additional checks on the offered certificate if
Code change:
for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.

Related discussion:
text: 4. <del> When using alternative services, both "http" and "https" URIs might use the same connection, because HTTP/2 permits requests for multiple origins on the same connection. </del> <ins> When using alternative services, requests for resources identified by both "http" and "https" URIs might use the same connection, because HTTP/2 permits requests for multiple origins on the same connection. </ins> Since "https" URIs rely on server authentication, a connection that is initially created for "http" URIs without authenticating the
Code change:
for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.

Related discussion:
text: A client that doesn't perform authentication is an easy victim of server impersonation, through man-in-the-middle attacks. <del> A client that is willing to use cleartext to resolve the resource will do so if access to any TLS-enabled alternative services is blocked at the network layer. </del> <ins> A client that is willing to use HTTP over cleartext to resolve the resource will do so if access to any TLS-enabled alternative services is blocked at the network layer. </ins> Given that the primary goal of this specification is to prevent passive attacks, these are not critical failings (especially
Code change:
for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.

Related discussion:
text: 5.1. A alternative service can make this commitment by sending a "HTTP- <del> TLS" header field: </del> <ins> TLS" header field, described here using the '#' ABNF extension defined in Section 7 of RFC7230: </ins> When it appears in a HTTP response from a strongly authenticated alternative service, this header field indicates that the
Code change:
for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.

Related discussion:
text: creates some risks for clients (see pinrisks). Authentication for HTTP over TLS is described in Section 3.1 of <del> RFC2818, noting the additional requirements in I-D.ietf-httpbis-alt- svc.  The header field MUST be ignored if strong authentication fails; otherwise, an attacker could create a persistent denial of service by falsifying a commitment. </del> <ins> RFC2818, noting the additional requirements in Section 2.1 of I- D.ietf-httpbis-alt-svc.  The header field MUST be ignored if strong authentication fails; otherwise, an attacker could create a persistent denial of service by falsifying a commitment. </ins> The commitment to use authenticated TLS persists for a period determined by the value of the "ma" parameter.  See Section 4.2.3 of
Code change:
for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.

Related discussion:
text: The commitment made by the "HTTP-TLS" header field applies only to the origin of the resource that generates the "HTTP-TLS" header <del> field.  Requests for an origin that has a persisted, unexpired value for "HTTP-TLS" MUST fail if they cannot be made over an authenticated TLS connection. </del> <ins> field. Requests for an origin that has a persisted, unexpired value for "HTTP-TLS" MUST fail if they cannot be made over an authenticated TLS connection. </ins> Note that the commitment is not bound to a particular alternative service.  Clients SHOULD use alternative services that they become
Code change:
This algorithm automatically enforces the ABNF syntax, including length limits. It still punts on the actual strtoi/strtof part. ?
Much better, thanks!

Related discussion:
text: NOTE: This algorithm parses both Integers and Floats float, and returns the corresponding structure. <del> If the first character of input_string is not "-" or a DIGIT, fail parsing. </del> <ins> Let type be "integer". Let sign be 1. Let input_number be an empty string. If the first character of input_string is "-", remove it from input_string and set sign to -1. </ins> <del> Let input_number be the result of consuming input_string up to (but not including) the first character that is not in DIGIT, "-", and ".". </del> <ins> If input_string is empty, fail parsing. </ins> <del> If any character of input_number after the first is "-", fail </del> <ins> If the first character of input_string is not a DIGIT, fail </ins> parsing. <del> If input_number contains ".", parse it as a floating point number and let output_number be the result. </del> <ins> While input_string is not empty: Let char be the result of removing the first character of input_string. If char is a DIGIT, append it to input_number. Else, if type is "integer" and char is ".", append char to input_number and set type to "float". Otherwise, fail parsing. If type is "integer" and input_number contains more than 19 characters, fail parsing. If type is "float" and input_number contains more than 16 characters, fail parsing. If type is "integer", parse input_number as an integer and let output_number be the result. Otherwise: If the final character of input_number is ".", fail parsing. </ins> <del> Otherwise, parse input_number as an integer and let output_number be the result. </del> <ins> Parse input_number as a float and let output_number be the result. </ins> <del> Return output_number. </del> <ins> Return the product of output_number and sign. </ins> 4.6.