jiebi/CodeConvo huggingface dataset:
Append ";" to output. <del> Let name be the result of applying Serialising an Identifier (ser-identifier) to parameter's param-name. </del> <ins> Let name be the result of applying Serialising a Key (ser- key) to parameter's param-name. </ins> Append name to output. If parameter has a param-value: <del> Let value be the result of applying Serialising a Key (ser-key) to parameter's param-value. </del> <ins> Let value be the result of applying Serialising an Item (ser-item) to parameter's param-value. </ins> Append "=" to output.
Abstract <del> An increasing diversity of Web-connected devices and software capabilities has created a need to deliver optimized content for each device. </del> <ins> HTTP defines proactive content negotiation to allow servers to select the appropriate response for a given request, based upon the user agent's characteristics, as expressed in request headers.  In practice, clients are often unwilling to send those request headers, because it is not clear whether they will be used, and sending them impacts both performance and privacy. </ins> <del> This specification defines an extensible and configurable set of HTTP request header fields, colloquially known as Client Hints, to address this.  They are intended to be used as input to proactive content negotiation; just as the Accept header field allows user agents to indicate what formats they prefer, Client Hints allow user agents to indicate device and agent specific preferences. </del> <ins> This specification defines a response header, Accept-CH, that servers can use to advertise their use of request headers for proactive content negotiation, along with a set of guidelines for the creation of such headers, colloquially known as "Client Hints." It also defines an initial set of Client Hints. </ins> Note to Readers
A popular alternative strategy is to use HTTP cookies (RFC6265) to communicate some information about the user agent.  However, this approach is also not cache friendly, bound by same origin policy, and <del> imposes additional client-side latency by requiring JavaScript </del> <ins> often imposes additional client-side latency by requiring JavaScript </ins> execution to create and manage HTTP cookies. <del> This document defines a set of new request header fields that allow user agent to perform proactive content negotiation (Section 3.4.1 of RFC7231) by indicating device and agent specific preferences, through a mechanism similar to the Accept header field which is used to indicate preferred response formats. Client Hints does not supersede or replace the User-Agent header field.  Existing device detection mechanisms can continue to use both mechanisms if necessary.  By advertising its capabilities within a request header field, Client Hints allows for cache friendly and proactive content negotiation. </del> <ins> Proactive content negotiation (Section 3.4.1 of RFC7231) offers an alternative approach; user agents use specified, well-defined request headers to advertise their capabilities and characteristics, so that servers can select (or formulate) an appropriate response. However, proactive content negotiation requires clients to send these request headers prolifically.  This causes performance concerns (because it creates "bloat" in requests), as well as privacy issues (because these request headers can be used to "fingerprint" - i.e., uniquely identify - the user agent). This document defines a new response header, Accept-CH, that allows an origin server to explicitly ask that clients send these headers in requests, for a period of time bounded by the Accept-CH-Lifetime response header.  It also defines guidelines for content negotiation mechanisms that use it, colloquially referred to as Client Hints. Client Hints mitigate the performance concerns by assuring that clients will only send the request headers when they're actually going to be used, and the privacy concerns by creating positive evicence of their use (the use of the response header). This document also defines an initial set of Client Hints. It does not supersede or replace the User-Agent header field. Existing device detection mechanisms can continue to use both mechanisms if necessary.  By advertising user agent capabilities within a request header field, Client Hints allow for cache friendly and proactive content negotiation. </ins> 1.1.
field identified by a content negotiation mechanism that the implementation supports: <del> Let request-value be the field-value(s) associated with field-name in incoming-request. </del> <ins> Let request-value be the field-value associated with field-name in incoming-request (after being combined as allowed by Section 3.2.2 of RFC7230), or null if field- name is not in incoming-request. </ins> Let available-values be a list containing all available- value for variant.
MUST define an algorithm for selecting a result.  It MUST return a list of available-values that are suitable for the request, in order of preference, given the value of the request header <del> nominated above and an available-values list from the Variants header.  If the result is an empty list, it implies that the cache cannot satisfy the request. </del> <ins> nominated above (or null if the request header is absent) and an available-values list from the Variants header.  If the result is an empty list, it implies that the cache cannot satisfy the request. </ins> backports fulfils these requirements for some existing proactive content negotiation mechanisms in HTTP.
corresponding to the other keys could be returned, or the request could be forwarded towards the origin. <ins> 4.3.1. If the selected variants-header was: And a request comes in with the following headers: Then sorted-variants in cache is: If the cache contains responses with the following Variant-Keys: Then the cache needs to forward the request to the origin server, since Variants indicates that "de" is available, and that is acceptable to the client. 4.3.2. If the selected variants-header was: And a request comes in with the following headers: Then sorted-variants in cache are: This allows the cache to return a "Variant-Key: en" response even though it's not in the set the client prefers. </ins> 5. Origin servers that wish to take advantage of Variants will need to
as shown here. This specification uses the Augmented Backus-Naur Form (ABNF) <del> notation of RFC5234 with a list extension, defined in Section 7 of RFC7230, that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). </del> <ins> notation of RFC5234 but relies on Structured Headers from I-D.ietf- httpbis-header-structure for parsing. </ins> <del> Additionally, it uses the "field-name", "OWS" and "token" rules from RFC7230, and "type", "subtype", "content-coding" and "language-range" from RFC7231. </del> <ins> Additionally, it uses the "field-name" rule from RFC7230, and "type", "subtype", "content-coding" and "language-range" from RFC7231. </ins> 2.
the response is produced, by enumerating the request header fields that it varies on, along with the values that are available for each. <del> Each "variant-item" indicates a request header field that carries a value that clients might proactively negotiate for; each parameter on it indicates a value for which there is an available representation on the origin server. </del> <ins> Variants is a Structured Header I-D.ietf-httpbis-header-structure. Its value MUST be a list-of-lists (Section 3.3 of I-D.ietf-httpbis- header-structure) whose members are strings (Section 3.8 of I-D.ietf- httpbis-header-structure) or tokens (Section 3.9 of I-D.ietf-httpbis- header-structure).  Its ABNF is: If Structured Header parsing fails or a list-member has the wrong type, the client MUST treat the representation as having no Variants header field. The Variants header field represents an ordered list of "variant- axes", each of which consists of a request header "field-name" string and a list of "available-value" strings.  Each inner-list in the Variants header field value is parsed into a variant-axis.  The first list-member of the inner-list is interpreted as the field-name, and the remaining list-members are the available-values.  Any list-member that is a token (Section 3.9 of I-D.ietf-httpbis-header-structure) is interpreted as a string containing the same characters. Field-names in the Variants header field value MUST match the field- name production (Section 3.2 of RFC7230).  Clients receiving an invalid field-name MUST NOT match it to any content negotiating mechanism. </ins> So, given this example header field:
Here, recipients can infer that two content-codings in addition to "identity" are available, as well as two content languages.  Note <del> that, as with all HTTP header fields that use the "#" list rule (see RFC7230, Section 7), they might occur in the same header field or separately, like this: </del> <ins> that, as with all Structured Header lists, they might occur in the same header field or separately, like this: </ins> The ordering of available-values after the field-name is significant, as it might be used by the header's algorithm for selecting a
3. <del> The Variant-Key HTTP response header field is used to indicate the values from the Variants header field that identify the representation it occurs within. 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. 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. </del> <ins> The Variant-Key HTTP response header field identifies a set of variants provided by the representation it occurs within.  A variant is identified by a selection of one available-value from each variant-axis from the Variants header field. Variant-Key is a Structured Header I-D.ietf-httpbis-header-structure. Its value MUST be a list-of-lists (Section 3.3 of I-D.ietf-httpbis- header-structure) whose members are strings (Section 3.8 of I-D.ietf- httpbis-header-structure) or tokens (Section 3.9 of I-D.ietf-httpbis- header-structure).  Its ABNF is: If Structured Header parsing fails or a list-member has the wrong type, the client MUST treat the representation as having no Variant- Key header field. Each inner-list MUST have the same number of list-members as there are variant-axes in the representation's Variants header field.  If not, the client MUST treat the representation as having no Variant- Key header field. Each list-member is treated as identifying an available-value for the corresponding variant-axis' field-name.  Any list-member that is a token (Section 3.9 of I-D.ietf-httpbis-header-structure) is interpreted as a string containing the same characters.  These available-values do not need to explicitly appear in the Variants header field.  For example, Accept-Encoding defines an implicit "identity" available-value (content-encoding). </ins> For example:
gzip-compressed French representation. When more than one Variant-Key value is in a response, the first one <del> present MUST indicate the variant-key for the response it occurs within. 3.1. This algorithm generates a list of normalised strings from Variant- Key, suitable for comparison with values generated by cache. Given stored-headers (a set of headers from a stored response), a normalised list of variant-keys for that message can be generated by following this algorithm: Let variant-keys be an empty list. 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> <ins> present MUST correspond to the request that caused that response to be generated. </ins> <del> Let value-list be the result of splitting variant-key-header on commas (","). </del> <ins> Parsing is strict.  For example: </ins> <del> For each value in value-list: </del> <ins> is treated as if the Variant-Key header were completely absent, which will tend to disable caching for the representation that contains it. </ins> <del> Remove all whitespace from value. </del> <ins> Note that in </ins> <del> Append value to variant-keys. Return variant-keys. </del> <ins> The whitespace after "gzip" in the first header field value is excluded by the token parsing algorithm, but the whitespace in the second header field value is included by the string parsing algorithm.  This will likely cause the second header field value to fail to match client requests. </ins> 4. Caches that implement the Variants header field and the relevant <del> semantics of the field-name it contains can use that knowledge to </del> <ins> semantics of the field-names it contains can use that knowledge to </ins> either select an appropriate stored representation, or forward the request if no appropriate representation is stored.
Let sorted-variants be an empty list. If the freshest member of stored-responses (as per RFC7234, <del> Section 4.2) has one or more "Variants" header field(s): </del> <ins> Section 4.2) has one or more "Variants" header field(s) that successfully parse according to variants: </ins> <del> Select one member of stored-responses and let variants-header be its "Variants" header field-value(s).  This SHOULD be the most recent response, but MAY be from an older one as long as it is still fresh. </del> <ins> Select one member of stored-responses with a "Variants" header field-value(s) that successfully parses according to variants and let variants-header be this parsed value.  This SHOULD be the most recent response, but MAY be from an older one as long as it is still fresh. </ins> <del> For each variant in variants-header, parsed according to the ABNF: </del> <ins> For each variant-axis in variants-header: </ins> <del> If variant's field-name corresponds to the request header field identified by a content negotiation mechanism that the implementation supports: </del> <ins> If variant-axis' field-name corresponds to the request header field identified by a content negotiation mechanism that the implementation supports: </ins> Let request-value be the field-value associated with field-name in incoming-request (after being combined as allowed by Section 3.2.2 of RFC7230), or null if field- name is not in incoming-request. <del> Let available-values be a list containing all available- value for variant. </del> Let sorted-values be the result of running the algorithm defined by the content negotiation mechanism with <del> request-value and available-values. </del> <ins> request-value and variant-axis' available-values. </ins> Append sorted-values to sorted-variants. At this point, sorted-variants will be a list of lists, each <del> member of the top-level list corresponding to a variant-item in </del> <ins> member of the top-level list corresponding to a variant-axis in </ins> the Variants header field-value, containing zero or more items indicating available-values that are acceptable to the client, in order of preference, greatest to least. Return result of running Compute Possible Keys (find) on sorted- <del> variants, an empty string and an empty list. </del> <ins> variants, an empty list and an empty list. </ins> <del> This returns a list of strings suitable for comparing to normalised Variant-Keys (gen-variant-key) that represent possible responses on the server that can be used to satisfy the request, in preference </del> <ins> This returns a list of lists of strings suitable for comparing to the parsed Variant-Keys (variant-key) that represent possible responses on the server that can be used to satisfy the request, in preference </ins> order, provided that their secondary cache key (after removing the headers covered by Variants) matches. check_vary illustrates one way to do this.
This algorithm computes the cross-product of the elements of key- facets. <del> Given key-facets (a list of lists), and key-stub (a string representing a partial key), and possible-keys (a list): </del> <ins> Given key-facets (a list of lists of strings), and key-stub (a list of strings representing a partial key), and possible-keys (a list of lists of strings): </ins> Let values be the first member of key-facets. <del> For each value in values: If key-stub is an empty string, let this-key be a copy of value. </del> <ins> Let remaining-facets be a copy of all of the members of key-facets except the first. </ins> <del> Otherwise: Let this-key be a copy of key-stub. Append a semicolon (";") to this-key. </del> <ins> For each value in values: </ins> <del> Append value to this-key. </del> <ins> Let this-key be a copy of key-stub. </ins> <del> Let remaining-facets be a copy of all of the members of key- facets except the first. </del> <ins> Append value to this-key. </ins> If remaining-facets is empty, append this-key to possible-keys.
Instead, applications are encouraged to ensure that URLs are discovered at runtime, allowing HTTP-based services to describe their own capabilities.  One way to do this is to use typed links RFC8288 <del> to convey the URIs that are in use, as well as the semantics of the </del> <ins> to convey the URLs that are in use, as well as the semantics of the </ins> resources that they identify.  See resource for details. 4.4.1.
4.4.2. Applications that use HTTP will typically employ the "http" and/or <del> "https" URL schemes. "https" is RECOMMENDED to provide </del> <ins> "https" URI schemes. "https" is RECOMMENDED to provide </ins> authentication, integrity and confidentiality, as well as mitigate pervasive monitoring attacks RFC7258. However, application-specific schemes can also be defined.  When <del> defining an URL scheme for an application using HTTP, there are a </del> <ins> defining an URI scheme for an application using HTTP, there are a </ins> number of tradeoffs and caveats to keep in mind: Unmodified Web browsers will not support the new scheme.  While it <del> is possible to register new URL schemes with Web browsers (e.g. </del> <ins> is possible to register new URI schemes with Web browsers (e.g. </ins> registerProtocolHandler() in HTML5, as well as several proprietary approaches), support for these mechanisms is not shared by all browsers, and their capabilities vary.
expensive process. In some cases, however, GET might be unwieldy for expressing queries, <del> because of the limited syntax of the URL; in particular, if binary </del> <ins> because of the limited syntax of the URI; in particular, if binary </ins> data forms part of the query terms, it needs to be encoded to conform <del> to URL syntax. </del> <ins> to URI syntax. </ins> While this is not an issue for short queries, it can become one for larger query terms, or ones which need to sustain a high rate of
to identify clients.  The Basic authentication scheme RFC7617 MUST NOT be used unless the underlying transport is authenticated, integrity-protected and confidential (e.g., as provided the "HTTPS" <del> URL scheme, or another using TLS).  The Digest scheme RFC7616 MUST </del> <ins> URI scheme, or another using TLS).  The Digest scheme RFC7616 MUST </ins> NOT be used unless the underlying transport is similarly secure, or the chosen hash algorithm is not "MD5".
Dictionaries are ordered maps of key-value pairs, where the keys are short, textual strings and the values are items (item) or arrays of <del> items.  There can be one or more members, and keys are required to be unique. </del> <ins> items.  There can be zero or more members, and keys are required to be unique. </ins> Implementations MUST provide access to dictionaries both by index and by key.  Specifications MAY use either means of accessing the
This section specifies the algorithm for doing so. Given an array of bytes input_bytes that represents the chosen <del> header's field-value, and header_type (one of "dictionary", "list", "param-list", or "item"), return the parsed header value. </del> <ins> header's field-value (which is an empty string if that header is not present), and header_type (one of "dictionary", "list", "param-list", or "item"), return the parsed header value. </ins> Convert input_bytes into an ASCII string input_string; if conversion fails, fail parsing.
3.3. <del> Parameterized Lists are arrays of parameterized identifiers, with one or more members. </del> <ins> Parameterized Lists are arrays of parameterized items, with one or more members. </ins> <del> A parameterized identifier is a primary identifier (a token}) with associated parameters, an ordered map of key-value pairs where the keys are short, textual strings and the values are items (item). There can be zero or more parameters, and keys are required to be unique. </del> <ins> A parameterized item is an item (item) with associated parameters, an ordered map of key-value pairs where the keys are short, textual strings and the values are items (item).  There can be zero or more parameters, and keys are required to be unique. </ins> The ABNF for parameterized lists in HTTP/1 headers is: <del> In HTTP/1, each param-id is separated by a comma and optional </del> <ins> In HTTP/1, each param-item is separated by a comma and optional </ins> whitespace (as in Lists), and the parameters are separated by semicolons.  For example:
4.2.4. Given an ASCII string input_string, return a list of parameterized <del> identifiers. input_string is modified to remove the parsed value. </del> <ins> items. input_string is modified to remove the parsed value. </ins> Let items be an empty array. While input_string is not empty: <del> Let item be the result of running Parse Parameterized Identifier from Text (parse-param-id) with input_string. </del> <ins> Let item be the result of running Parse Parameterized Item from Text (parse-param-item) with input_string. </ins> Append item to items.
additional response header fields to convey related values to aid client processing. <del> 2.2.1. </del> <ins> 3. Servers can advertise support for Client Hints using the mechnisms described below. 3.1. </ins> <del> Servers can advertise support for Client Hints using the Accept-CH header field or an equivalent HTML meta element with http-equiv attribute (HTML5).  Accept-CH is a Structured Header I-D.ietf- httpbis-header-structure.  Its value MUST be an sh-list (Section 3.1 of I-D.ietf-httpbis-header-structure) whose members are tokens (Section 3.7 of I-D.ietf-httpbis-header-structure).  Its ABNF is: </del> <ins> The Accept-CH response header field or the equivalent HTML meta element with http-equiv attribute (HTML5) indicate server support for particular hints indicated in its value.  Accept-CH is a Structured Header I-D.ietf-httpbis-header-structure.  Its value MUST be an sh- list (Section 3.1 of I-D.ietf-httpbis-header-structure) whose members are tokens (Section 3.7 of I-D.ietf-httpbis-header-structure).  Its ABNF is: </ins> For example:
clear persisted opt-in preferences when any one of site data, browsing history, browsing cache, or similar, are cleared. <del> 4. </del> <ins> 5. </ins> This document defines the "Accept-CH" and "Accept-CH-Lifetime" HTTP response fields, and registers them in the Permanent Message Header Fields registry. <del> 4.1. </del> <ins> 5.1. </ins> Header field name: Accept-CH Applicable protocol: HTTP
Servers can advertise support for Client Hints using the Accept-CH header field or an equivalent HTML meta element with http-equiv <del> attribute (HTML5). </del> <ins> attribute (HTML5).  Accept-CH is a Structured Header I-D.ietf- httpbis-header-structure.  Its value MUST be an sh-list (Section 3.1 of I-D.ietf-httpbis-header-structure) whose members are tokens (Section 3.7 of I-D.ietf-httpbis-header-structure).  Its ABNF is: </ins> For example:
delivery of Client Hints on subsequent requests to the server's origin (RFC6454). <ins> Accept-CH-Lifetime is a Structured Header I-D.ietf-httpbis-header- structure.  Its value MUST be sh-integer (Section 3.4 of I-D.ietf- httpbis-header-structure).  Its ABNF is: </ins> When a client receives an HTTP response that contains Accept-CH- Lifetime header field, the field-value indicates that the Accept-CH preference SHOULD be persisted and bound to the origin, and be