jiebi/CodeConvo huggingface dataset:
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.
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.
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
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.
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
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
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
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.
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
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>
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,
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
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
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
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
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.
syntactically, this is done only to allow parsers to be generic; as per RFC7231, Section 4.3.1, a body on a GET has no meaning, and will be either ignored or rejected by generic HTTP software.  As a result, <del> applications that use HTTP SHOULD NOT define GET to have any sde </del> <ins> applications that use HTTP SHOULD NOT define GET to have any side </ins> effects upon their resources. 4.6.
cache or by forwarding the request towards the origin - by following the algorithm defined in cache. <del> Its companion the Variant-Key response header field (variant-key) indicates which representation was selected, so that it can be reliably reused in the future.  When this specification is in use, the example above might become: </del> <ins> Its companion Variant-Key response header field (variant-key) indicates the applicable key(s) that the response is associated with, so that it can be reliably reused in the future.  When this specification is in use, the example above might become: </ins> Proactive content negotiation mechanisms that wish to be used with Variants need to define how to do so explicitly; see define.  As a
3. The Variant-Key HTTP response header field is used to indicate the <del> value(s) from the Variants header field that identify the </del> <ins> values from the Variants header field that identify the </ins> representation it occurs within. <del> Each value indicates the selected available-value, in the same order as the variants listed in the Variants header field. </del> <ins> Each member of the list contains the selected available-value(s), in the same order as the variants listed in the Variants header field. </ins> Therefore, Variant-Key MUST be the same length (in comma-separated members) as Variants, and each member MUST correspond in position to
This header pair indicates that the representation has a "gzip" content-coding and "fr" content-language. <del> Note that Variant-Key is only used to indicate what request attributes are associated with the response containing it; this is different from headers like Content-Encoding, which indicate attributes of the response itself.  In the example above, it might be that a gzip'd version of the French content is not available, in which case the response will include: </del> <ins> A more complex example involves listing multiple available-values in a list member, to indicate that the response can be used to satisfy requests with any of those values.  For example: </ins> <del> even though Content-Encoding does not contain "gzip". </del> <ins> indicates that this response can be used for requests whose Content- Encoding algorithm selects "gzip" or "identity", as long as the Content-Language algorithm selects "fr" - perhaps because there is no gzip-compressed French representation. This highlights an important aspect of Variant-Key; it is only used to indicate what request attributes are associated with the response containing it; this is different from headers like Content-Encoding, which indicate attributes of the response itself. </ins> 3.1. <del> This algorithm generates a normalised string for Variant-Key, suitable for comparison with values generated by cache. </del> <ins> This algorithm generates a list of normalised strings from Variant- Key, suitable for comparison with values generated by cache. </ins> Given stored-headers, a set of headers from a stored response, a <del> normalised variant-key for that message can be generated by: </del> <ins> normalised list of variant-keys for that message can be generated by: Let variant-keys be an empty list. </ins> Let variant-key-header be a string, the result of selecting all field-values of stored-headers whose field-name is "Variant-Key" and joining them with a comma (","). <del> Remove all whitespace from variant-key-header. </del> <ins> Let value-list be the result of splitting variant-key-header on commas (","). For each value in value-list: Remove all whitespace from value. Let items be the result of splitting value on ";". append items to variant-keys. </ins> <del> Return variant-key-header. </del> <ins> Return the result of running Compute Possible Keys (find) on variant-keys, an empty string and an empty list. </ins> 4.
4.1. <del> Given sorted-variants, a list of lists, and key-stub, a string </del> <ins> Given key-facets, a list of lists, and key-stub, a string </ins> representing a partial key, and possible-keys, a list: <del> Let sorted-values be the first member of sorted-variants. </del> <ins> Let values be the first member of key-facets. </ins> <del> For each sorted-value in sorted-values: </del> <ins> For each value in values: </ins> If key-stub is an empty string, let this-key be a copy of <del> sorted-value. </del> <ins> value. </ins> Otherwise:
Append a comma (",") to this-key. <del> Append sorted-value to this-key. </del> <ins> Append value to this-key. </ins> <del> Let remaining-variants be a copy of all of the members of sorted-variants except the first. </del> <ins> Let remaining-facets be a copy of all of the members of key- facets except the first. </ins> <del> If remaining-variants is empty, append this-key to possible- keys. </del> <ins> If remaining-facets is empty, append this-key to possible-keys. </ins> <del> Otherwise, run Find Available Keys on remaining-variants, this- </del> <ins> Otherwise, run Find Available Keys on remaining-facets, this- </ins> key and possible-keys. Return possible-keys.
be sent along with "same-site" requests.  If the value is "Lax", the cookie will be sent with same-site requests, and with "cross-site" top-level navigations, as described in strict-lax.  If the "SameSite" <del> attribute's value is neither of these, the cookie will be ignored. </del> <ins> attribute's value is neither of these, the attribute will be ignored. </ins> 4.1.3.
where the last-byte-pos in the Request is much larger than the last- byte-pos returned in response to an open-ended byte-range HEAD <del> request, as described above. </del> <ins> request, as described above, and much larger than the expected maximum size of the representation.  See Security for range value considerations. </ins> In response, a server may indicate that it is supplying a continuously aggregating ("live") response by supplying the client
be safely processed MUST be rejected using the 425 (Too Early) status code. <ins> The "Early-Data" header field carries a single bit of information and clients MUST include at most one instance.  Multiple instances MUST be treated as equivalent to a single instance by a server. A "Early-Data" header field MUST NOT be included in responses or request trailers. </ins> 5.2. A 425 (Too Early) status code indicates that the server is unwilling
eliminate the chance of data being replayed and ensure a fixed upper limit to the number of replays. <del> The server can choose whether it will process early data before the TLS handshake completes.  By deferring processing, it can ensure that only a successfully completed connection is used for the request(s) therein.  This provides the server with some </del> <ins> The server can reject early data.  A server cannot selectively reject early data, so this results in all requests sent in early data being discarded. The server can choose to delay processing of early data until after the TLS handshake completes.  By deferring processing, it can ensure that only a successfully completed connection is used for the request(s) therein.  This provides the server with some </ins> assurance that the early data was not replayed. If the server receives multiple requests in early data, it can
data MUST be sent again, unless the client decides to abandon those requests. <del> This automatic retry exposes the request to a potential replay attack.  An attacker sends early data to one server instance that accepts and processes the early data, but allows that connection to proceed no further.  The attacker then forwards the same messages from the client to another server instance that will reject early data.  The client then retries the request, resulting in the request being processed twice.  Replays are also possible if there are multiple server instances that will accept early data, or if the same server accepts early data multiple times (though this would be in violation of requirements in Section 8 of TLS13). </del> <ins> Automatic retry creates the potential for a replay attack.  An attacker intercepts a connection that uses early data and copies the early data to another server instance.  The second server instance accepts and processes the early data.  The attacker then allows the original connection to complete.  Even if the early data is detected as a duplicate and rejected, the first server instance might allow the connection to complete.  If the client then retries requests that were sent in early data, the request will be processed twice. Replays are also possible if there are multiple server instances that will accept early data, or if the same server accepts early data multiple times (though this would be in violation of requirements in Section 8 of TLS13). </ins> Clients that use early data MUST retry requests upon receipt of a 425 (Too Early) status code; see status.
Such tunnels are commonly used to create end-to-end virtual connections, through one or more proxies. <del> The HTTP Tunnel-Protocol header field identifies the protocol that will be spoken within the tunnel, using the Application Layer Protocol Negotiation identifier (ALPN, RFC7301). </del> <ins> The HTTP ALPN header field identifies the protocol that will be spoken within the tunnel, using the Application Layer Protocol Negotiation identifier (ALPN, RFC7301). </ins> <del> When the CONNECT method is used to establish a tunnel, the Tunnel- Protocol header field can be used to identify the protocol that the client intends to use with that tunnel.  For a tunnel that is then secured using RFC5246, the header field carries the same application protocol label as will be carried within the TLS handshake.  If there are multiple possible application protocols, all of those application </del> <ins> When the CONNECT method is used to establish a tunnel, the ALPN header field can be used to identify the protocol that the client intends to use with that tunnel.  For a tunnel that is then secured using RFC5246, the header field carries the same application protocol label as will be carried within the TLS handshake.  If there are multiple possible application protocols, all of those application </ins> protocols are indicated. <del> The Tunnel-Protocol header field carries an indication of client intent only.  In TLS, the final choice of application protocol is made by the server from the set of choices presented by the client. Other protocols could negotiate protocols differently. </del> <ins> The ALPN header field carries an indication of client intent only. In TLS, the final choice of application protocol is made by the server from the set of choices presented by the client.  Other protocols could negotiate protocols differently. </ins> Proxies do not implement the tunneled protocol, though they might choose to make policy decisions based on the value of the header
2. <del> Clients include the Tunnel-Protocol header field in an HTTP CONNECT request to indicate the application layer protocol that will be used within the tunnel, or the set of protocols that might be used within the tunnel. </del> <ins> Clients include the ALPN header field in an HTTP CONNECT request to indicate the application layer protocol that will be used within the tunnel, or the set of protocols that might be used within the tunnel. </ins> 2.1.
2.2. <del> The ABNF (Augmented Backus-Naur Form) syntax for the Tunnel-Protocol header field is given below.  It is based on the Generic Grammar defined in RFC7230. </del> <ins> The ABNF (Augmented Backus-Naur Form) syntax for the ALPN header field is given below.  It is based on the Generic Grammar defined in RFC7230. </ins> ALPN protocol names are octet sequences with no additional constraints on format.  Octets not allowed in tokens (RFC7230) MUST
HTTP header fields are registered within the "Message Headers" registry maintained at <https://www.iana.org/assignments/message- <del> headers>.  This document defines and registers the Tunnel-Protocol header field, according to RFC3864 as follows: </del> <ins> headers>.  This document defines and registers the ALPN header field, according to RFC3864 as follows: </ins> <del> Tunnel-Protocol </del> <ins> ALPN </ins> http