jiebi/CodeConvo huggingface dataset:
2.1.3. <del> The "ttl" value of the Use-As-Dictionary header is a sf-integer value that provides the time in seconds that the dictionary is valid for (time to live). The "ttl" is independent of the cache lifetime of the resource being used for the dictionary.  If the underlying resource is evicted from cache then it is also removed but this allows for setting an explicit time to live for use as a dictionary independent of the underlying resource in cache.  Expired resources can still be useful as dictionaries while they are in cache and can be used for fetching updates of the expired resource.  It can also be useful to artificially limit the life of a dictionary in cases where the dictionary is updated frequently which can help limit the number of possible incoming dictionary variations. The "ttl" value is optional and defaults to 1209600 (14 days). 2.1.4. </del> The "id" value of the Use-As-Dictionary header is a sf-string value that specifies a server identifier for the dictionary.  If an "id" value is present then it MUST be sent to the server in a "Dictionary-
The "type" value is optional and defaults to "raw". <del> 2.1.6. </del> <ins> 2.1.5. </ins> <del> 2.1.6.1. </del> <ins> 2.1.5.1. </ins> A response that contained a response header: Would specify matching any document request for a URL with a path <del> prefix of /product/ on the same Origin as the original request, and expiring as a dictionary in 7 days independent of the cache lifetime of the resource. </del> <ins> prefix of /product/ on the same Origin as the original request. </ins> <del> 2.1.6.2. </del> <ins> 2.1.5.2. </ins> A response that contained a response header:
2.2.1. <del> To be considered as a match, the dictionary must not yet be expired as a dictionary.  When iterating through dictionaries looking for a match, the expiration time of the dictionary is calculated by taking the last time the dictionary was fetched and adding the "ttl" seconds from the "Use-As-Dictionary" response.  If the current time is beyond the expiration time of the dictionary, it MUST be ignored. </del> <ins> To be considered as a match, the dictionary resource MUST be either fresh HTTP-CACHING or allowed to be served stale (see eg RFC5861). </ins> 2.2.2.
confirms receipt of a request at the proxy without waiting for the proxy-destination TCP handshake to succeed or fail.  This might be particularly helpful when the destination host is not responding, as <del> TCP handshakes can hang for several minutes before failing. Implementation of "100 (Continue)" support is OPTIONAL for clients and REQUIRED for proxies. </del> <ins> TCP handshakes can hang for several minutes before failing.  Clients MAY send "Expect: 100-continue", and proxies MUST respect it by returning "100 (Continue)" if the request is not immediately rejected. </ins> Proxies implementing this specification SHOULD include a "Proxy- Status" response header RFC9209 in any success or failure response
The "id" value of the Use-As-Dictionary header is a sf-string value that specifies a server identifier for the dictionary.  If an "id" <del> value is present then it MUST be sent to the server in a "Dictionary- ID" request header when the dictionary is advertised as being available. </del> <ins> value is present and has a string length longer than zero then it MUST be sent to the server in a "Dictionary-ID" request header when the dictionary is advertised as being available. </ins> The server identifier MUST be treated as an opaque string by the client.
2.1.2. <del> The "match-dest" value of the Use-As-Dictionary header is a sf-string value that provides a request destination (https://fetch.spec.whatwg.org/#concept-request-destination). </del> <ins> The "match-dest" value of the Use-As-Dictionary header is an inner list of sf-string values that provides a list of request destinations for the dictionary to match (https://fetch.spec.whatwg.org/#concept- request-destination). </ins> <del> An empty string for "match-dest" MUST match all destinations. </del> <ins> An empty list for "match-dest" MUST match all destinations. </ins> <del> For clients that do not support request destinations or if the value of "match-dest" is a value that is not supported by the client then the client MUST treat it as an empty string and match all destinations. </del> <ins> For clients that do not support request destinations, the client MUST treat it as an empty list and match all destinations. </ins> <del> The "match-dest" value is optional and defaults to the empty string. </del> <ins> The "match-dest" value is optional and defaults to an empty list. </ins> 2.1.3.
dictionary usage and registers media types for content encoding Brotli and Zstandard using a negotiated dictionary. <ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. This document uses the following terminology from STRUCTURED-FIELDS to specify syntax and parsing: Dictionary, String, Inner List, Token, and Byte Sequence. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. </ins> This document uses the line folding strategies described in FOLDING. <ins> This document also uses terminology from HTTP and HTTP-CACHING. </ins> 2. 2.1.
header. The Use-As-Dictionary response header is a Structured Field <del> STRUCTURED-FIELDS with values for "match", "match-dest", "id", and "type". </del> <ins> STRUCTURED-FIELDS Dictionary with values for "match", "match-dest", "id", and "type". </ins> 2.1.1. <del> The "match" value of the Use-As-Dictionary header is a sf-string value that provides the URLPattern to use for request matching </del> <ins> The "match" value of the Use-As-Dictionary header is a String value that provides the URLPattern to use for request matching </ins> (https://urlpattern.spec.whatwg.org/). The URLPattern used for matching does not support using Regular
Return True. The "match" value is required and MUST be included in the Use-As- <del> Dictionary sf-dictionary for the dictionary to be considered valid. </del> <ins> Dictionary Dictionary for the dictionary to be considered valid. </ins> 2.1.2. <del> The "match-dest" value of the Use-As-Dictionary header is an inner list of sf-string values that provides a list of request destinations </del> <ins> The "match-dest" value of the Use-As-Dictionary header is an Inner List of String values that provides a list of request destinations </ins> for the dictionary to match (https://fetch.spec.whatwg.org/#concept- request-destination).
2.1.3. <del> The "id" value of the Use-As-Dictionary header is a sf-string value that specifies a server identifier for the dictionary.  If an "id" value is present and has a string length longer than zero then it MUST be sent to the server in a "Dictionary-ID" request header when the dictionary is advertised as being available. </del> <ins> The "id" value of the Use-As-Dictionary header is a String value that specifies a server identifier for the dictionary.  If an "id" value is present and has a string length longer than zero then it MUST be sent to the server in a "Dictionary-ID" request header when the dictionary is advertised as being available. </ins> The server identifier MUST be treated as an opaque string by the client.
dictionary available to use for compression. The "Available-Dictionary" request header is a Structured Field <del> STRUCTURED-FIELDS sf-binary SHA-256 hash of the contents of a single available dictionary. </del> <ins> STRUCTURED-FIELDS Byte Sequence containing the SHA-256 hash of the contents of a single available dictionary. </ins> The client MUST only send a single "Available-Dictionary" request header with a single hash value for the best available match that it
echo the stored "id" in a "Dictionary-ID" request header. The "Dictionary-ID" request header is a Structured Field STRUCTURED- <del> FIELDS sf-string of up to 1024 characters (after any decoding) and MUST be identical to the server-provided "id". </del> <ins> FIELDS String of up to 1024 characters (after any decoding) and MUST be identical to the server-provided "id". </ins> For example:
used in the "Content-Dictionary" response header. The "Content-Dictionary" response header is a Structured Field <del> STRUCTURED-FIELDS sf-dictionary SHA-256 hash of the contents of the dictionary that was used to encode the response. </del> <ins> STRUCTURED-FIELDS Byte Sequence containing the SHA-256 hash of the contents of the dictionary that was used to encode the response. </ins> If the HTTP response contains a "Content-Dictionary" response header with the hash of a dictionary that the client does not have available
HTTP clients can be configured to use proxies by selecting a proxy hostname, a port, and whether to use a security protocol.  However, <del> CONNECT requests using the proxy do not carry this configuration information.  Instead, they only indicate the hostname and port of the target.  This prevents any HTTP server from hosting multiple distinct proxy services, as the server cannot distinguish them by path (as with distinct resources) or by origin (as in "virtual hosting"). </del> <ins> Classic HTTP CONNECT requests using the proxy do not carry this configuration information.  Instead, they only indicate the hostname and port of the target.  This prevents any HTTP server from hosting multiple distinct proxy services, as the server cannot distinguish them by path (as with distinct resources) or by origin (as in "virtual hosting"). </ins> The absence of an explicit origin for the proxy also rules out the usual defenses against server port misdirection attacks (see RFC9110)
fields (e.g., "Alt-Svc" RFC7838, "Strict-Transport-Security" RFC6797). <del> Classic HTTP CONNECT proxies can be used to reach a target host that is specified as a domain name or an IP address.  However, because only a single target host can be specified, proxy-driven Happy Eyeballs and cross-IP fallback can only be used when the host is a domain name.  For IP-targeted requests to succeed, the client must know which address families are supported by the proxy via some out- of-band mechanism, or open multiple independent CONNECT requests and abandon any that prove unnecessary. </del> 1.3. This specification describes an alternative mechanism for proxying
A template-driven TCP transport proxy for HTTP is identified by a URI Template RFC6570 containing variables named "target_host" and <del> "tcp_port".  The client substitutes the destination host and port number into these variables to produce the request URI. The "target_host" variable MUST be a domain name, an IP address literal, or a list of IP addresses.  The "tcp_port" variable MUST be a single integer.  If "target_host" is a list (as in RFC6570), the server SHOULD perform the same connection procedure as if these IP addresses had been returned in response to A and AAAA queries for a domain name. </del> <ins> "target_port".  This URI Template and its variable values MUST meet all the same requirements as for UDP proxying (RFC9298), and are subject to the same validation rules.  The client MUST substitute the destination host and port number into this template to produce the request URI. </ins> 3.1.
expansion of the proxy's URI Template. If the request is well-formed and permissible, the proxy MUST attempt <del> the TCP connection before sending any response status code other than "100 (Continue)" (see conveying-metadata).  If the TCP connection is successful, the response SHALL be as follows: </del> <ins> to establish the TCP connection before sending any response status code other than "100 (Continue)" (see conveying-metadata).  If the TCP connection is successful, the response SHALL be as follows: </ins> The HTTP status code SHALL be "101 (Switching Protocols)".
SHOULD send a TCP RST to the target.  If the proxy observes a connection error from the target, it SHOULD send a TLS "internal_error" alert to the client, or set the TCP RST bit if TLS <del> is not in use. </del> <ins> is not in use.  These behaviors avoid truncation of transfers between the client and the target on vulnerable protocols (e.g., HTTP/1.1 without TLS) while preserving the confidentiality and integrity guarantees of the "https" scheme. </ins> 3.2. <del> In HTTP/2 and HTTP/3, the client uses the proxy by issuing an "extended CONNECT" request as follows: </del> <ins> In HTTP/2 and HTTP/3, the proxy MUST include SETTINGS_ENABLE_CONNECT_PROTOCOL in its SETTINGS frame RFC9220.  The client uses the proxy by issuing an "extended CONNECT" request as follows: </ins> The :method pseudo-header field SHALL be "CONNECT".
waiting for a "401 (Unauthorized)" response before each new connection through the proxy. <ins> 3.4. Unlike the datagram-oriented templated HTTP proxying specifications CONNECT-IP, this specification does not make use of the Capsule Protocol RFC9297.  A future specification could define a procedure for performing TCP proxying using the Capsule Protocol, but no such procedure is defined here. When implementing this specification, clients and servers MUST NOT send a "Capsule-Protocol: ?1" header field. </ins> 4. This section discusses some behaviors that are permitted or
sending TCP stream content optimistically, subject to flow control limits (RFC9113 or RFC9000).  Proxies MUST buffer this "optimistic" content until the TCP stream becomes writable, and discard it if the <del> TCP connection fails.  (This "optimistic" behavior is not permitted in HTTP/1.1 because it would interfere with reuse of the connection after an error response such as "401 (Unauthorized)".) </del> <ins> TCP connection fails.  (Clients MUST NOT use "optimistic" behavior in HTTP/1.1, as this would interfere with reuse of the connection after an error response such as "401 (Unauthorized)".) </ins> Servers that host a proxy under this specification MAY offer support for TLS early data in accordance with RFC8470.  Clients MAY send
If this request succeeds, the client SHOULD record a preference for "connect-tcp" to avoid further retry delays. <del> 5.3. The names of the variables in the URI Template uniquely identify the capabilities of the proxy.  Undefined variables are permitted in URI Templates, so a single template can be used for multiple purposes. Multipurpose templates can be useful when a single client may benefit from access to multiple complementary services (e.g., TCP and UDP), or when the proxy is used by a variety of clients with different needs. </del> 6. Template-driven TCP proxying is largely subject to the same security
upload's final size is the "Content-Length" field value and the server MUST record it to ensure its consistency. <ins> The following example shows an upload creation.  The client transfers the entire 100 bytes in the first request.  The server generates two informational responses to transmit the upload resource's URL and progress information, and one final response to acknowledge the completed upload: The next example shows an upload creation, where only the first 25 bytes are transferred.  The server acknowledges the received data and that the upload is not complete yet: </ins> If the client received an informational response with the upload URL in the Location field value, it MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a
upload's final size.  If they do not match, the server MUST reject the request with a "400 (Bad Request)" status code. <ins> The following example shows an upload append.  The client transfers the next 100 bytes at an offset of 100 and does not indicate that the upload is then completed.  The server acknowledges the new offset: </ins> The client MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a server error status code between 500 and 599 (inclusive) is received.  The client SHOULD
upload's final size is the "Content-Length" field value and the server MUST record it to ensure its consistency. <ins> The request content MAY be empty.  If the "Upload-Complete" header field is then set to true, the client intends to upload an empty entity.  An "Upload-Complete" header field is set to false is also valid.  This can be used to create an upload resource URL before transferring data, which can save client or server resources.  Since informational responses are optional, this technique provides another mechanism to learn the URL, at the cost of an additional round-trip before data upload can commence. The following example shows an upload creation.  The client transfers the entire 100 bytes in the first request.  The server generates two informational responses to transmit the upload resource's URL and progress information, and one final response to acknowledge the completed upload: The next example shows an upload creation, where only the first 25 bytes are transferred.  The server acknowledges the received data and that the upload is not complete yet: </ins> If the client received an informational response with the upload URL in the Location field value, it MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a
upload's final size.  If they do not match, the server MUST reject the request with a "400 (Bad Request)" status code. <ins> The request content MAY be empty.  If the "Upload-Complete" field is then set to true, the client wants to complete the upload without appending additional data. The following example shows an upload append.  The client transfers the next 100 bytes at an offset of 100 and does not indicate that the upload is then completed.  The server acknowledges the new offset: </ins> The client MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a server error status code between 500 and 599 (inclusive) is received.  The client SHOULD
waiting for the upload to complete before scanning a full file, or disabling resumable uploads. <ins> Resumable uploads are vulnerable to Slowloris-style attacks SLOWLORIS.  A malicious client may create upload resources and keep them alive by regularly sending "PATCH" requests with no or small content to the upload resources.  This could be abused to exhaust server resources by creating and holding open uploads indefinately with minimal work. Servers SHOULD provide mitigations for Slowloris attacks, such as increasing the maximum number of clients the server will allow, limiting the number of uploads a single client is allowed to make, imposing restrictions on the minimum transfer speed an uploads is allowed to have, and restricting the length of time an upload resource can exist. </ins> 11. IANA is asked to register the following entries in the "Hypertext
fields by responding with a "400 (Bad Request)" status code. If the server considers the upload resource to be active, it MUST <del> respond with a "204 (No Content)" status code.  The response MUST include the "Upload-Offset" header field, with the value set to the current resumption offset for the target resource.  The response MUST include the "Upload-Complete" header field; the value is set to true only if the upload is complete. </del> <ins> respond with a "204 (No Content)" or "200 (OK)" status code.  The response MUST include the "Upload-Offset" header field, with the value set to the current resumption offset for the target resource. The response MUST include the "Upload-Complete" header field; the value is set to true only if the upload is complete. </ins> An upload is considered complete only if the server completely and successfully received a corresponding creation request (upload-
cookie when sending it to the user agent.  The scope indicates the maximum amount of time in which the user agent should return the cookie, the servers to which the user agent should return the cookie, <del> and the URI schemes for which the cookie is applicable. </del> <ins> and the connection types for which the cookie is applicable. </ins> For historical reasons, cookies contain a number of security and privacy infelicities.  For example, a server can indicate that a
defined in SAMESITE.  A request is "same-site" if the following criteria are true: <del> The request is not the result of a cross-site redirect.  That is, the origin of every url in the request's url list is same-site with the request's current url's origin. </del> The request is not the result of a reload navigation triggered through a user interface element (as defined by the user agent; e.g., a request triggered by the user clicking a refresh button on
attribute-name of "Secure", set the cookie's secure-only-flag to true.  Otherwise, set the cookie's secure-only-flag to false. <del> If the scheme component of the request-uri does not denote a "secure" protocol (as defined by the user agent), and the cookie's secure-only-flag is true, then abort these steps and ignore the cookie entirely. </del> <ins> If the request-uri does not denote a "secure" connection (as defined by the user agent), and the cookie's secure-only-flag is true, then abort these steps and ignore the cookie entirely. </ins> If the cookie-attribute-list contains an attribute with an attribute-name of "HttpOnly", set the cookie's http-only-flag to
http-only-flag is true, abort these steps and ignore the cookie entirely. <del> If the cookie's secure-only-flag is false, and the scheme component of request-uri does not denote a "secure" protocol, then abort these steps and ignore the cookie entirely if the cookie store contains one or more cookies that meet all of the following criteria: </del> <ins> If the cookie's secure-only-flag is false, and the request-uri does not denote a "secure" connection, then abort these steps and ignore the cookie entirely if the cookie store contains one or more cookies that meet all of the following criteria: </ins> Their name matches the name of the newly-created cookie.
The user agent includes stored cookies in the Cookie HTTP request header field. <del> When the user agent generates an HTTP request, the user agent MUST NOT attach more than one Cookie header field. </del> A user agent MAY omit the Cookie header field in its entirety.  For example, the user agent might wish to block sending cookies during "third-party" requests from setting cookies (see third-party- cookies). If the user agent does attach a Cookie header field to an HTTP <del> request, the user agent MUST compute the cookie-string following the algorithm defined in retrieval-algorithm, where the retrieval's URI is the request-uri, the retrieval's same-site status is computed for the HTTP request as defined in same-site-requests, and the retrieval's type is "HTTP". </del> <ins> request, the user agent MUST generate a single cookie-string and the user agent MUST compute the cookie-string following the algorithm defined in retrieval-algorithm, where the retrieval's URI is the request-uri, the retrieval's same-site status is computed for the HTTP request as defined in same-site-requests, and the retrieval's type is "HTTP". </ins> 5.7.2.
The retrieval's URI's path path-matches the cookie's path. If the cookie's secure-only-flag is true, then the retrieval's <del> URI's scheme must denote a "secure" protocol (as defined by the user agent). </del> <ins> URI must denote a "secure" connection (as defined by the user agent). </ins> <del> NOTE: The notion of a "secure" protocol is not defined by this document.  Typically, user agents consider a protocol secure if the protocol makes use of transport-layer security, such as SSL or TLS.  For example, most user agents consider "https" to be a scheme that denotes a secure protocol. </del> <ins> NOTE: The notion of a "secure" connection is not defined by this document.  Typically, user agents consider a connection secure if the connection makes use of transport-layer security, such as SSL or TLS, or if host is trusted.  For example, most user agents consider "https" to be a scheme that denotes a secure protocol and "localhost" to be trusted host. </ins> If the cookie's http-only-flag is true, then exclude the cookie if the retrieval's type is "non-HTTP".