jiebi/CodeConvo huggingface dataset:
Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable whitelist of safe request targets." <del> The Tunnel-Protocol header field described in this document is an OPTIONAL header field.  Clients and HTTP proxies could choose to not support the header and therefore fail to provide it, or ignore it when present.  If the header is not available or ignored, a proxy cannot identify the purpose of the tunnel and use this as input to any authorization decision regarding the tunnel.  This is </del> <ins> The ALPN header field described in this document is an OPTIONAL header field.  Clients and HTTP proxies could choose to not support the header and therefore fail to provide it, or ignore it when present.  If the header is not available or ignored, a proxy cannot identify the purpose of the tunnel and use this as input to any authorization decision regarding the tunnel.  This is </ins> indistinguishable from the case where either client or proxy does not <del> support the Tunnel-Protocol header field. The value of the Tunnel-Protocol header field could be falsified by a 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. </del> <ins> support the ALPN header field. The value of the ALPN header field could be falsified by a 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 ALPN header field as a policy input in all cases. </ins>
HTTP clients need to know that the content they receive on a connection comes from the origin that they intended to retrieve in from.  The traditional form of server authentication in HTTP has been <del> in the form of a single X.509 certificate provided during the TLS I- D.ietf-tls-tls13 handshake. </del> <ins> in the form of a single X.509 certificate provided during the TLS (RFC5246, I-D.ietf-tls-tls13) handshake. </ins> Many existing HTTP RFC7230 servers also have authentication requirements for the resources they serve.  Of the bountiful
TLS 1.3 TLS13 introduces the concept of early data (also known as zero round trip data or 0-RTT data).  Early data allows a client to send data to a server in the first round trip of a connection, <del> without waiting for the TLS handshake to complete if the client has </del> <ins> without waiting for the TLS handshake to complete, if the client has </ins> spoken to the same server recently. When used with HTTP HTTP, early data allows clients to send requests
request routing is likely to be safe from side-effects, but other actions might not be. <del> Intermediary servers do not have sufficient information to make this determination, so status describes a way for the origin to signal to them that a particular request isn't appropriate for early data. Intermediaries that accept early data MUST implement that mechanism. </del> <ins> Intermediary servers do not have sufficient information to decide whether early data can be processed, so status describes a way for the origin to signal to them that a particular request isn't appropriate for early data.  Intermediaries that accept early data MUST implement that mechanism. </ins> Note that a server cannot choose to selectively reject early data at the TLS layer.  TLS only permits a server to accept all early data,
sent in early data - thereby giving the client control over risk of replay.  Absent other information, clients MAY send requests with safe HTTP methods (see RFC7231, Section 4.2.1) in early data when it <del> is available, and SHOULD NOT send unsafe methods (or methods whose </del> <ins> is available, and MUST NOT send unsafe methods (or methods whose </ins> safety is not known) in early data. If the server rejects early data at the TLS layer, a client MUST
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 <del> 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 </del> <ins> accepts and processes the early data, even though it will not complete the TLS handshake.  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 </ins> were sent in early data, the request will be processed twice. Replays are also possible if there are multiple server instances that
replayed.  A retried or replayed request can produce different side effects on the server.  In addition to those side effects, replays and retries might be used for traffic analysis to recover information <del> about requests or the resources those requests target. </del> <ins> about requests or the resources those requests target.  In particular, a request that is replayed might result in a different response, which might be observable from the length of protected data even if the content remains confidential. </ins> 6.1.
eliminate the chance of data being replayed and ensure a fixed upper limit to the number of replays. <del> 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. </del> <ins> The server can reject early data at the TLS layer.  A server cannot selectively reject early data, so this results in all requests sent in early data being discarded. </ins> The server can choose to delay processing of early data until after the TLS handshake completes.  By deferring processing, it
If the server receives multiple requests in early data, it can determine whether to defer HTTP processing on a per-request basis. <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), in cases where the risk of replay is judged too great. </del> <ins> The server can cause a client to retry individual requests and not use early data by responding with the 425 (Too Early) status code (status), in cases where the risk of replay is judged too great. </ins> For a given request, the level of tolerance to replay risk is specific to the resource it operates upon (and therefore only known <del> to the origin server).  In general, if processing a request does not have state-changing side effects, the consequences of replay are not significant. </del> <ins> to the origin server).  The primary risk associated with using early data is in the actions a server takes when processing a request; processing a duplicated request might result in duplicated effects and side effects.  Appendix E.5 of TLS13 also describes other effects produced by processing duplicated requests. </ins> The request method's safety (RFC7231, Section 4.2.1) is one way to <del> determine this.  However, some resources do elect to associate side effects with safe methods, so this cannot be universally relied upon. </del> <ins> determine if a request is free from side effects.  However, some resources do elect to associate side effects with safe methods, so this cannot be universally relied upon. </ins> It is RECOMMENDED that origin servers allow resources to explicitly configure whether early data is appropriate in requests.  Absent such
A server can limit the amount of early data with the "max_early_data_size" field of the "early_data" TLS extension.  This can be used to avoid committing an arbitrary amount of memory for <del> deferred requests.  A server SHOULD ensure that when it accepts early data, it can defer processing of requests until after the TLS handshake completes. </del> <ins> requests that it might defer until the handshake completes. </ins> 4.
start sending again as though the connection was new.  This could entail using a different negotiated protocol ALPN than the one optimistically used for the early data.  Any requests sent in early <del> data MUST be sent again, unless the client decides to abandon those requests. </del> <ins> data will need to be sent again, unless the client decides to abandon those requests. </ins> Automatic retry creates the potential for a replay attack.  An attacker intercepts a connection that uses early data and copies the
Replays are also possible if there are multiple server instances that will accept early data, or if the same server accepts early data <del> multiple times (though this would be in violation of requirements in Section 8 of TLS13). </del> <ins> multiple times (though the latter 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.
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 <del> (see be-consistent for details). </del> <ins> (be-consistent describes considerations for clusters of servers). </ins> An intermediary MUST NOT remove this header field if it is present in a request.  "Early-Data" MUST NOT appear in a "Connection" header
A server decides whether or not to offer a client the ability to send early data on future connections when sending the TLS session ticket. <ins> TLS TLS13 mandates the use of replay detection strategies that reduce the ability of an attacker to successfully replay early data.  These anti-replay techniques reduce but don't completely eliminate the chance of data being replayed and ensure a fixed upper limit to the number of replays. </ins> When a server enables early data, there are a number of techniques it can use to mitigate the risks of replay: <del> TLS TLS13 mandates the use of replay detection strategies that reduce the ability of an attacker to successfully replay early data.  These anti-replay techniques reduce but don't completely eliminate the chance of data being replayed and ensure a fixed upper limit to the number of replays. </del> The server can reject early data at the TLS layer.  A server cannot selectively reject early data, so this results in all requests sent in early data being discarded.
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 <del> assurance that the early data was not replayed. If the server receives multiple requests in early data, it can determine whether to defer HTTP processing on a per-request basis. </del> <ins> assurance that the early data was not replayed.  If the server receives multiple requests in early data, it can determine whether to defer HTTP processing on a per-request basis. </ins> The server can cause a client to retry individual requests and not use early data by responding with the 425 (Too Early) status code (status), in cases where the risk of replay is judged too great. <ins> Any of these techniques is equally effective and a server can use the method that best suits it. </ins> For a given request, the level of tolerance to replay risk is specific to the resource it operates upon (and therefore only known to the origin server).  The primary risk associated with using early
Because HTTP requests can span multiple "hops", it is necessary to explicitly communicate whether a request has been sent in early data <del> on a previous connection.  Likewise, some means of explicitly triggering a retry when early data is not desirable is necessary. Finally, it is necessary to know whether the client will actually perform such a retry. </del> <ins> on a previous hop.  Likewise, some means of explicitly triggering a retry when early data is not desirable is necessary.  Finally, it is necessary to know whether the client will actually perform such a retry. </ins> To meet these needs, two signalling mechanisms are defined:
A 425 (Too Early) status code indicates that the server is unwilling to risk processing a request that might be replayed. <del> User agents that send a request in early data MUST automatically retry the request when receiving a 425 (Too Early) response status code.  Such retries MUST NOT be sent in early data. </del> <ins> User agents that send a request in early data are expected to retry the request when receiving a 425 (Too Early) response status code.  A user agent MAY do so automatically, but any retries MUST NOT be sent in early data. </ins> In all cases, an intermediary can forward a 425 (Too Early) status code.  Intermediaries MUST forward a 425 (Too Early) status code if
In protocols that deliver data out of order (such as QUIC HQ) early data can arrive after the handshake completes.  A server MAY process <del> requests received in early data after handshake completion if it can rely on other instances correctly handling replays of the same </del> <ins> requests received in early data after handshake completion only if it can rely on other instances correctly handling replays of the same </ins> requests. 7.
certificate are not already available, they will need to be sent as described in cert-available as part of this exchange. <ins> If the client does not have the desired certificate, it instead sends an Empty Authenticator, as described in Section 5 of I-D.ietf-tls- exported-authenticator, in a "CERTIFICATE" frame in response to the request, followed by a "USE_CERTIFICATE" frame which references the Empty Authenticator.  In this case, or if the client has not advertised support for HTTP-layer certificates, the server processes the request based solely on the certificate provided during the TLS handshake, if any.  This might result in an error response via HTTP, such as a status code 403 (Not Authorized). </ins> 3. The "CERTIFICATE_REQUEST" and "CERTIFICATE_NEEDED" frames are
origin that isn't HTTPS. For example, based on the Accept-CH and Accept-CH-Lifetime example <del> above, which is received from "https://bar.example.com" in response to a resource request initiated by "https://foo.example.com", both delivered over a secure transport: a user agent SHOULD persist an Accept-CH preference bound to "https://foo.example.com", for requests initiated to "https://bar.example.com" from "https://foo.example.com", for up to 86400 seconds (1 day).  This preference SHOULD NOT extend to requests initiated to "https://bar.example.com" from other origins. </del> <ins> above, which is received in response to a user agent navigating to "https://example.com", and delivered over a secure transport: a user agent SHOULD persist an Accept-CH preference bound to "https://example.com" for up to 86400 seconds (1 day), and use it for user agent navigations to "https://example.com" and any same-origin resource requests initiated by the page constructed from the navigation's response.  This preference SHOULD NOT extend to resource requests initiated to "https://example.com" from other origins. </ins> If Accept-CH-Lifetime occurs in a message more than once, the last value overrides all previous occurrences.
as shown here. This document uses the Augmented Backus-Naur Form (ABNF) notation of <del> RFC5234, including the VCHAR, DIGIT, ALPHA and DQUOTE rules from that document.  It also includes the OWS rule from RFC7230. </del> <ins> RFC5234, including the VCHAR, SP, DIGIT, ALPHA and DQUOTE rules from that document.  It also includes the OWS rule from RFC7230. </ins> This document uses algorithms to specify parsing and serialisation behaviours, and ABNF to illustrate expected syntax.
If input is a type other than an integer, float, string or binary content, fail serialisation. <del> Let output be an empty string. If input is an integer, let value be the result of applying Serialising an Integer ser-integer to input. </del> <ins> If input is an integer, return the result of applying Serialising an Integer ser-integer to input. </ins> <del> If input is a float, let value be the result of applying Serialising a Float ser-float to input. </del> <ins> If input is a float, return the result of applying Serialising a Float ser-float to input. </ins> <del> If input is a string, let value be the result of applying Serialising a String ser-string to input. </del> <ins> If input is a string, return the result of applying Serialising a String ser-string to input. </ins> <del> If input is binary content, let value be the result of applying Serialising Binary Content ser-binary to input. Return output. </del> <ins> Otherwise, return the result of applying Serialising Binary Content ser-binary to input. </ins> 4.1.5.
attribute-name of "Path", and the cookie's path is "/". If the cookie store contains a cookie with the same name, domain, <del> and path as the newly-created cookie: </del> <ins> host-only-flag, and path as the newly-created cookie: </ins> Let old-cookie be the existing cookie with the same name, <del> domain, and path as the newly-created cookie.  (Notice that this algorithm maintains the invariant that there is at most one such cookie.) </del> <ins> domain, host-only-flag, and path as the newly-created cookie. (Notice that this algorithm maintains the invariant that there is at most one such cookie.) </ins> If the newly-created cookie was received from a "non-HTTP" API and the old-cookie's http-only-flag is true, abort these steps
values from the Variants header field that identify the representation it occurs within. <del> Each member of the list contains the selected available-value(s), in the same order as the variants listed in the Variants header field. </del> <ins> Each member of the list contains a set of selected available-value(s) that identify this representation, in the same order as the variants listed in the Variants header field. </ins> <del> Therefore, Variant-Key MUST be the same length (in comma-separated members) as Variants, and each member MUST correspond in position to its companion in Variants. </del> <ins> Therefore, each member of Variant-Key MUST be the same length (in semicolon-separated members) as Variants, and each member's available-values MUST correspond in position to their companions in Variants. </ins> For example: This header pair indicates that the representation has a "gzip" content-coding and "fr" content-language. <del> 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: </del> <ins> If the response can be used to satisfy more than one request), they can be listed in additional members.  For example: </ins> indicates that this response can be used for requests whose Accept- Encoding algorithm selects "gzip" or "identity", as long as the Accept-Language algorithm selects "fr" - perhaps because there is no gzip-compressed French representation. <del> 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. </del> <ins> When more than one Variant-Key value is in a response, the first one present MUST indicate the variant-key for the response it occurs within. </ins> 3.1.
both the two-octet Request-ID as well as at least 96 bits of additional entropy. <ins> Upon receipt of a "CERTIFICATE_REQUEST" frame, the recipient MUST verify that the first two octets of the authenticator's "certificate_request_context" matches the Request-ID presented in the frame. </ins> The TLS library on the authenticating peer will provide mechanisms to select an appropriate certificate to respond to the transported request.  TLS libraries on servers MUST be able to recognize the
Indicates that the exported authenticator spans more than one frame. <ins> Indicates that the exported authenticator does not contain a Request-ID. </ins> The frame contains the following fields: "Cert-ID" is a 16-bit opaque identifier used to correlate other certificate- related frames with this exported authenticator fragment. <ins> "Request-ID" is an optional 16-bit opaque identifier used to correlate this exported authenticator with the request which triggered it, if any.  This field is present only if the "UNSOLICITED" flag is not set. </ins> A portion of the opaque data returned from the TLS connection exported authenticator "authenticate" API.  See exp-auth for more details on the input to this API.
frame with "TO_BE_CONTINUED" unset MUST be treated as a connection error of type "PROTOCOL_ERROR". <ins> If the "UNSOLICITED" flag is not set, the "CERTIFICATE" frame also contains a Request-ID indicating the certificate request which caused this exported authenticator to be generated.  The value of this flag and the contents of the Request-ID field MUST NOT differ between frames with the same Cert-ID. </ins> Upon receiving a complete series of "CERTIFICATE" frames, the receiver may validate the Exported Authenticator value by using the exported authenticator API.  This returns either an error indicating
Upon receipt of a "CERTIFICATE" frame, an endpoint MUST perform the following steps to validate the token it contains: <ins> Verify that either the "UNSOLICITED" flag is set (clients only) or that the Request-ID field contains the Request-ID of a previously- sent "CERTIFICATE_REQUEST" frame. </ins> Using the "get context" API, retrieve the "certificate_request_context" used to generate the authenticator, <del> if any. Verify that the "certificate_request_context" is either empty (clients only) or contains the Request-ID of a previously-sent "CERTIFICATE_REQUEST" frame. </del> <ins> if any.  Verify that the "certificate_request_context" begins with the supplied Request-ID, if any. </ins> Use the "validate" API to confirm the validity of the authenticator with regard to the generated request (if any).
6.4. <ins> CNAME records in the DNS are frequently used to delegate authority for an origin to a third-party provider.  This delegation can be changed without notice, even to the third-party provider, simply by modifying the CNAME record in question. After the owner of the domain has redirected traffic elsewhere by changing the CNAME, new connections will not arrive for that origin, but connections which are properly directed to this provider for other origins would continue to claim control of this origin (via ORIGIN frame and Secondary Certificates).  This is proper behavior based on the third-party provider's configuration, but would likely not be what is intended by the owner of the origin. This is not an issue which can be mitigated by the protocol, but something about which third-party providers SHOULD educate their customers before using the features described in this document. 6.5. </ins> Implementations need to be aware of the potential for confusion about the state of a connection.  The presence or absence of a validated certificate can change during the processing of a request,
For each member mem of input: <del> Let name be the result of applying Serialising an Identifier (ser-identifier) to mem's member-name. </del> <ins> Let name be the result of applying Serialising an Key (ser-key) to mem's member-name. </ins> Append name to output. Append "=" to output. <del> Let value be the result of applying Serialising a Key (ser-key) to mem's member-value. </del> <ins> Let value be the result of applying Serialising an Item (ser- item) to mem's member-value. </ins> Append value to output.