jiebi/CodeConvo huggingface dataset:
following ways: Clients MUST NOT consult DNS to establish the connection's <del> authority for new requests.  The TLS certificate MUST stil be used to do so, as described in RFC7540 Section 9.1.1. </del> <ins> authority for new requests.  The TLS certificate MUST still be used to do so, as described in RFC7540 Section 9.1.1. </ins> Clients sending a new request SHOULD use an existing connection if the request's origin is in that connection's Origin Set, unless
over time, it is possible that a client might have more than one viable connection to an origin open at any time.  When this occurs, clients SHOULD not emit new requests on any connection whose Origin <del> Set is a subset of another connection's Origin Set, and SHOULD close it once all outstanding requests are satisfied. </del> <ins> Set is a proper subset of another connection's Origin Set, and SHOULD close it once all outstanding requests are satisfied. </ins> 3.
3. <ins> A server can notify its support for CACHE_DIGEST frame by sending the ACCEPT_CACHE_DIGEST (0x7) SETTINGS parameter.  If the server is tempted to making optimizations based on CACHE_DIGEST frames, it SHOULD send the SETTINGS parameter immediately after the connection is established. The value of the parameter is a bit-field of which the following bits are defined: FRESH (0x1): When set, it indicates that the server is willing to make use of a digest of freshly-cached responses. STALE (0x2): When set, it indicates that the server is willing to make use of a digest of stale-cached responses. Rest of the bits MUST be ignored and MUST be left unset when sending. The initial value of the parameter is zero (0x0) meaning that the server is not interested in seeing a CACHE_DIGEST frame. Some underlying transports allow the server's first flight of application data to reach the client at around the same time when the 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 ACCEPT_CACHE_DIGEST settings value. 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 previous connections to that origin RFC6454 to make assumptions. 4. </ins> This document registers the following entry in the Permanent Message Headers Registry, as per RFC3864:
Specification: [this document] <del> 4. </del> <ins> This document registers the following entry in the HTTP/2 Settings Registry, as per RFC7540: Code: 0x7 Name: ACCEPT_CACHE_DIGEST Initial Value: 0x0 Reference: [this document] 5. </ins> The contents of a User Agent's cache can be used to re-identify or "fingerprint" the user over time, even when other identifiers (e.g.,
The set of origins (as per RFC6454) that a given connection might be used for is known in this specification as the Origin Set. <del> By default, a connection's Origin Set is uninitialised.  When an ORIGIN frame is first received and successfully processed by a client, the connection's Origin Set is defined to contain a single origin, composed from: </del> <ins> By default, the Origin Set for a connection is uninitialised.  When an ORIGIN frame is first received and successfully processed by a client, the connection's Origin Set is defined to contain an initial origin.  The initial origin is composed from: </ins> Scheme: "https" <del> Host: the value sent in Server Name Indication (RFC6066 </del> <ins> Host: the value sent in Server Name Indication (SNI, RFC6066 </ins> Section 3), converted to lower case Port: the remote port of the connection (i.e., the server's port)
RFC6454, Section 6.2) and remove it from the connection's Origin Set, if present. <ins> When sending an ORIGIN frame to a connection that is initialised as an Alternative Service RFC7838, the initial origin set set will contain an origin with the appropriate scheme and hostname (since Alternative Services specifies that the origin's hostname be sent in SNI).  However, it is possible that the port will be different than that of the intended origin, since the initial origin set is calculated using the actual port in use, which can be different for the alternative service.  In this case, the intended origin needs to be sent in the ORIGIN frame explicitly. For example, a client making requests for "https://example.com" is directed to an alternative service at ("h2", "x.example.net", "8443").  If this alternative service sends an ORIGIN frame, the initial origin will be "https://example.com:8443".  The client will not be able to use the alternative service to make requests for "https://example.com" unless that origin is explicitly included in the ORIGIN frame. </ins> 2.4. RFC7540, Section 10.1 uses both DNS and the presented TLS certificate
3. <del> This draft currently has no requirements for IANA.  If the specification is standardised, the CACHE_DIGEST frame will need to be assigned a frame type and the Cache-Digest header will need to be registered. </del> <ins> This document registers the following entry in the Permanent Message Headers Registry, as per RFC3864: Header field name: Cache-Digest Applicable protocol: http Status: experimental Author/Change controller: IESG Specification document(s): [this document] This document registers the following entry in the HTTP/2 Frame Type Registry, as per RFC7540: Frame Type: CACHE_DIGEST Code: 0xd Specification: [this document] </ins> 4.
containing the relation type "preload" and start fetching the target resource. <del> However, this MUST NOT affect how the final response is processed; when handling it, the client MUST behave as if it had not seen the informational response.  In particular, a client MUST NOT process the header fields included in the final response as if they belonged to the informational response, or vice versa. </del> <ins> However, these header fields only provide hints to the client; they do not replace the header fields on the final response.  Aside from performance optimizations, such evaluation of the 103 (Early Hints) response's header fields MUST NOT affect how the final response is processed.  A client MUST NOT interpret the 103 (Early Hints) response header fields as if they applied to the informational response itself (e.g., as metadata about the 103 (Early Hints) response). </ins> An intermediary MAY drop the informational response.  It MAY send HTTP/2 (RFC7540) server pushes using the information found in the 103
client that the server is likely to send a final response with the header fields included in the informational response. <del> A server MUST NOT include Content-Length, Transfer-Encoding, or any hop-by-hop header fields (RFC7230, Section 6.1) in a 103 (Early Hints) response. </del> <ins> Typically, a server will include the header fields sent in a 103 (Early Hints) response in the final response as well.  However, there might be cases when this is not desirable, such as when the server learns that they are not correct before the final response is sent. </ins> A client can speculatively evaluate the header fields included in a 103 (Early Hints) response while waiting for the final response.  For example, a client might recognize a Link header field value containing the relation type "preload" and start fetching the target <del> resource. However, these header fields only provide hints to the client; they do not replace the header fields on the final response.  Aside from performance optimizations, such evaluation of the 103 (Early Hints) response's header fields MUST NOT affect how the final response is processed.  A client MUST NOT interpret the 103 (Early Hints) response header fields as if they applied to the informational </del> <ins> resource.  However, these header fields only provide hints to the client; they do not replace the header fields on the final response. Aside from performance optimizations, such evaluation of the 103 (Early Hints) response's header fields MUST NOT affect how the final response is processed.  A client MUST NOT interpret the 103 (Early Hints) response header fields as if they applied to the informational </ins> response itself (e.g., as metadata about the 103 (Early Hints) response). <del> An intermediary MAY drop the informational response.  It MAY send HTTP/2 (RFC7540) server pushes using the information found in the 103 (Early Hints) response. </del> The following example illustrates a typical message exchange that involves a 103 (Early Hints) response.
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
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.
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
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
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.
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
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.
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.
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.
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.
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
status code often leads to clients retrying requests, which could result in increased load. <ins> 6.4. In protocols that deliver data out of order (such as QUIC HQ) early 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. </ins> 7. This document registers the "Early-Data" header field in the "Message
capacity even then. This specification defines a HTTP/2 frame type to allow clients to <del> inform the server of their cache's contents using a Golomb-Rice Coded Set Rice.  Servers can then use this to inform their choices of what to push to clients. </del> <ins> inform the server of their cache's contents using a Cuckoo-filter Cuckoo based digest.  Servers can then use this to inform their choices of what to push to clients. </ins> 1.1.
representation of the cache's state regarding that origin, for the type of cached response indicated by the "STALE" flag. <del> *VALIDATORS* (0x4): When set, indicates that the "validators" boolean in computing is true. *STALE* (0x8): When set, indicates that all cached responses represented in the digest-value are stale RFC7234 at the point in them that the digest was generated; otherwise, all are fresh. </del> 2.1. A CACHE_DIGEST frame MUST be sent from a client to a server on stream
CACHE_DIGESTs received on a given connection to inform what it pushes to that client; <del> If a given URL has a match in a current CACHE_DIGEST with the STALE flag unset, it need not be pushed, because it is fresh in cache; </del> If a given URL and ETag combination has a match in a current <del> CACHE_DIGEST with the STALE flag set, the client has a stale copy in cache, and a validating response can be pushed; </del> <ins> CACHE_DIGEST, a complete response need not be pushed; The server MAY push a 304 response for that resource, indicating the client that it hasn't changed. </ins> <del> If a given URL has no match in any current CACHE_DIGEST, the client does not have a cached copy, and a complete response can be pushed. </del> <ins> If a given URL and ETag has no match in any current CACHE_DIGEST, the client does not have a cached copy, and a complete response can be pushed. </ins> Servers MAY use all CACHE_DIGESTs received for a given origin as current, as long as they do not have the RESET flag set; a
The value of the parameter is a bit-field of which the following bits are defined: <del> FRESH (0x1): When set, it indicates that the server is willing to make use of a digest of freshly-cached responses. STALE (0x2): When set, it indicates that the server is willing to make use of a digest of stale-cached responses. </del> <ins> ACCEPT (0x1): When set, it indicates that the server is willing to make use of a digest of cached responses. </ins> Rest of the bits MUST be ignored and MUST be left unset when sending.
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
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.
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.
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
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.
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.