jiebi/CodeConvo huggingface dataset:
in which omission of a priority parameter implies the use of their default values (see #parameters). <del> For example, when the client sends an HTTP request with </del> <ins> As a non-normative example, when the client sends an HTTP request with </ins> and the origin responds with the intermediary might alter its understanding of the urgency from <del> "5" to "1", because the server-provided value overrides the value provided by the client.  The incremental value continues to be "1", the value specified by the client, as the server did not specify the </del> <ins> "5" to "1", because it prefers the server-provided value over the client's.  The incremental value continues to be "1", the value specified by the client, as the server did not specify the </ins> incremental("i") parameter. 7.
than needing to subvert DNS or IP routing in order to use a compromised certificate, a malicious server now only needs a client to connect to _some_ HTTPS site under its control in order to present <del> the compromised certificate.  As recommended in RFC8336, clients opting not to consult DNS ought to employ some alternative means to increase confidence that the certificate is legitimate. </del> <ins> the compromised certificate.  Clients SHOULD consult DNS for hostnames presented in secondary certificates if they would have done so for the same hostname if it were present in the primary certificate. As recommended in RFC8336, clients opting not to consult DNS ought to employ some alternative means to increase confidence that the certificate is legitimate. </ins> One such means is the Required Domain certificate extension defined in {extension}. Clients MUST require that server certificates
way that is backwards compatible for peers that are unaware of the extended meaning. <ins> For example, if there is a need to provide more granularity than eight urgency levels, it would be possible to subdivide the range using an additional parameter.  Implementations that do not recognize the parameter can safely continue to use the less granular eight levels. Alternatively, the urgency can be augmented.  For example, a graphical user-agent could send a "visible" parameter to indicate if the resource being requested is within the viewport. </ins> 4. The Priority HTTP header field can appear in requests and responses.
6. It is not always the case that the client has the best understanding <del> of how the HTTP responses deserve to be prioritized.  For example, use of an HTML document might depend heavily on one of the inline images.  Existence of such dependencies is typically best known to the server. </del> <ins> of how the HTTP responses deserve to be prioritized.  The server might have additional information that can be combined with the client's indicated priority in order to improve the prioritization of the response.  For example, use of an HTML document might depend heavily on one of the inline images; existence of such dependencies is typically best known to the server.  Or, a server that receives requests for a font RFC8081 and images with the same urgency might give higher precedence to the font, so that a visual client can render textual information at an early moment. </ins> An origin can use the Priority response header field to indicate its view on how an HTTP response should be prioritized.  An intermediary
textual value makes the prioritization scheme extensible; see the discussion below. <del> 8.2. One of the aims of this specification is to define a mechanism for merging client- and server-provided hints for prioritizing the responses.  For that to work, each urgency level needs to have a well-defined meaning.  As an example, a server can assign the highest precedence among the supplementary responses to an HTTP response carrying an icon, because the meaning of "u=2" is shared among the endpoints. This specification restricts itself to defining a minimum set of urgency levels in order to provide sufficient granularity for prioritizing responses for ordinary web browsing, at minimal complexity. However, that does not mean that the prioritization scheme would forever be stuck to the eight levels.  The design provides extensibility.  If deemed necessary, it would be possible to subdivide any of the eight urgency levels that are currently defined. Or, a graphical user-agent could send a "visible" parameter to indicate if the resource being requested is within the viewport. A server can combine the hints provided in the Priority header field with other information in order to improve the prioritization of responses.  For example, a server that receives requests for a font RFC8081 and images with the same urgency might give higher precedence to the font, so that a visual client can render textual information at an early moment. </del> 9. This specification registers the following entry in the Permanent
set of parameters when a request or a response is issued.  In order to reprioritize a request, HTTP-version-specific frames are used by clients to transmit the same information on a single hop.  If <del> intermediaries want to specify prioritizaton on a multiplexed HTTP </del> <ins> intermediaries want to specify prioritization on a multiplexed HTTP </ins> connection, it SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT change the Priority header field.
server's disinterest in changing the client-provided value.  This is different from the logic being defined for the request header field, in which omission of a priority parameter implies the use of their <del> default values (see #parameters). </del> <ins> default values (see parameters). </ins> As a non-normative example, when the client sends an HTTP request <del> with </del> <ins> with the urgency parameter set to "5" and the incremental parameter set to "true" </ins> and the origin responds with the intermediary might alter its understanding of the urgency from "5" to "1", because it prefers the server-provided value over the <del> client's.  The incremental value continues to be "1", the value </del> <ins> client's.  The incremental value continues to be "true", the value </ins> specified by the client, as the server did not specify the incremental("i") parameter.
In order to mitigate this fairness problem, when a server responds to a request that is known to have come through an intermediary, the server SHOULD prioritize the response as if it was assigned the <del> priority of "u=1, i=?1" (i.e. round-robin) regardless of the value of </del> <ins> priority of "u=1, i" (i.e. round-robin) regardless of the value of </ins> the Priority header field being transmitted, unless the server knows the intermediary is not coalescing requests from multiple clients.
Status: standard <del> Description: The sha-256 digest of the representation-data of the resource when no content coding is applied (eg.  "Content- Encoding: identity") Reference: RFC6234, RFC4648, this document. Status: standard </del> <ins> ID-SHA-256: : * Description: The sha-256 digest of the representation-data of the resource when no content coding is applied (eg.  "Content-Encoding: identity") * Reference: RFC6234, RFC4648, this document.  * Status: standard </ins> If other digest-algorithm values are defined, the associated encoding MUST either be represented as a quoted string, or MUST NOT include
example: Members whose value is Boolean true MUST omit that value when <del> serialised, unless it has Parameters.  For example, here both "b" and "c" are true, but "c"'s value is serialised because it has Parameters: </del> <ins> serialised.  For example, here both "b" and "c" are true: </ins> Note that this requirement is only on serialisation; parsers are <del> still required to correctly handle the true value when it appears in Dictionary values. </del> <ins> still required to correctly handle the true Boolean value when it appears in Dictionary values. </ins> A Dictionary with a member whose value is an Inner List of tokens:
Append the result of running Serializing a Key (ser-key) with member's member_name to output. <del> If member_value is not Boolean true or parameters is not empty: </del> <ins> If member_value is Boolean true: Append the result of running Serializing Parameters (ser- params) with parameters to output. Otherwise: </ins> Append "=" to output. <del> If member_value is an array, append the result of running Serialising an Inner List (ser-innerlist) with (member_value, parameters) to output. </del> <ins> If member_value is an array, append the result of running Serialising an Inner List (ser-innerlist) with (member_value, parameters) to output. </ins> <del> Otherwise, append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output. </del> <ins> Otherwise, append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output. </ins> If more members remain in input_dictionary:
There are thousands of different devices accessing the web, each with different device capabilities and preference information.  These device capabilities include hardware and software characteristics, as <del> well as dynamic user and client preferences.  Applications that want to allow the server to optimize content delivery and user experience based on such capabilities have, historically, had to rely on passive identification (e.g., by matching User-Agent (Section 5.5.3 of RFC7231) header field against an established database of client signatures), used HTTP cookies RFC6265 and URL parameters, or use some combination of these and similar mechanisms to enable ad hoc content negotiation. Such techniques are expensive to setup and maintain, are not portable across both applications and servers, and make it hard to reason for both client and server about which data is required and is in use during the negotiation: </del> <ins> well as dynamic user and client preferences.  Historically, applications that wanted to allow the server to optimize content delivery and user experience based on such capabilities had to rely on passive identification (e.g., by matching User-Agent (Section 5.5.3 of RFC7231) header field against an established database of client signatures), used HTTP cookies RFC6265 and URL parameters, or use some combination of these and similar mechanisms to enable ad hoc content negotiation. Such techniques are expensive to setup and maintain, and are not portable across both applications and servers.  They also make it hard for both client and server to reason about which data is required and is in use during the negotiation: </ins> User agent detection cannot reliably identify all static variables, cannot infer dynamic client preferences, requires
requests.  It also defines guidelines for content negotiation mechanisms that use it, colloquially referred to as Client Hints. <del> 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 of passive fingerprinting by requiring explicit opt-in and disclosure of required headers by the server through the use of the Accept-CH response header. </del> <ins> Client Hints mitigate performance concerns by assuring that clients will only send the request headers when they're actually going to be used, and privacy concerns of passive fingerprinting by requiring explicit opt-in and disclosure of required headers by the server through the use of the Accept-CH response header. </ins> <del> This document defines the Client Hints infrastructure, a framework that enables servers to opt-in to specific proactive content negotiation features, which will enable them to adapt their content accordingly.  However, it does not define any specific features that will use that infrastructure.  Those features will be defined in their respective specifications. </del> <ins> This document defines Client Hints, a framework that enables servers to opt-in to specific proactive content negotiation features, adapting their content accordingly.  However, it does not define any specific features that will use that infrastructure.  Those features will be defined in their respective specifications. </ins> One example of such a feature is the User Agent Client Hints feature UA-CH.
2.1. <del> Clients control which Client Hints are sent in requests, based on their default settings, user configuration, and server preferences. The client and server can use an opt-in mechanism outlined below to negotiate which header fields need to be sent to allow for efficient content adaption, and optionally use additional mechanisms to negotiate delegation policies that control access of third parties to same header fields. </del> <ins> Clients choose what Client Hints to send in a request based on their default settings, user configuration, and server preferences expressed in "Accept-CH".  The client and server can use an opt-in mechanism outlined below to negotiate which header fields need to be sent to allow for efficient content adaption, and optionally use additional mechanisms to negotiate delegation policies that control access of third parties to same header fields. </ins> Implementers SHOULD be aware of the passive fingerprinting implications when implementing support for Client Hints, and follow
3.1. <del> The Accept-CH response header field or the equivalent HTML meta element with http-equiv attribute (Section 4.2.5.3 of HTML) indicate server support for particular hints indicated in its value. </del> <ins> The Accept-CH response header field indicates server support for the hints indicated in its value. </ins> 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-
For example: <del> When a client receives an HTTP response advertising support for provided list of Clients Hints, it SHOULD process it as origin (RFC6454) opt-in to receive Client Hint header fields advertised in the field-value, for subsequent same-origin requests. The opt-in MUST be delivered over a secure transport. The opt-in SHOULD be persisted and bound to the origin to enable delivery of Client Hints on subsequent requests to the server's origin, and MUST NOT be persisted for an origin that isn't HTTPS. For example, based on the Accept-CH example above, which is received in response to a user agent navigating to "https://example.com", and delivered over a secure transport: a user agent will have to persist an Accept-CH preference bound to "https://example.com" and use it for user agent navigations to "https://example.com" and any same-origin </del> <ins> When a client receives an HTTP response containing "Accept-CH", it indicates that the origin opts-in to receive the indicated request header fields for subsequent same-origin requests.  The opt-in MUST be ignored if delivered over non-secure transport or for an origin with a scheme different from HTTPS.  It SHOULD be persisted and bound to the origin to enable delivery of Client Hints on subsequent requests to the server's origin. For example: Based on the Accept-CH example above, which is received in response to a user agent navigating to "https://example.com", and delivered over a secure transport: a user agent will have to persist an Accept- CH preference bound to "https://example.com" and use it for user agent navigations to "https://example.com" and any same-origin </ins> resource requests initiated by the page constructed from the navigation's response.  This preference will not extend to resource requests initiated to "https://example.com" from other origins. 3.2. <del> When selecting an optimized response based on one or more Client Hints, and if the resource is cacheable, the server needs to generate a Vary response header field (RFC7234) to indicate which hints can affect the selected response and whether the selected response is </del> <ins> When selecting a response based on one or more Client Hints, and if the resource is cacheable, the server needs to generate a Vary response header field (RFC7234) to indicate which hints can affect the selected response and whether the selected response is </ins> appropriate for a later request. Above example indicates that the cache key needs to include the Sec-
interoperability. The rich flexibility of client-driven HTTP/2 prioritization tree <del> building is rarely exercised; experience shows that clients either choose a single model optimized for a web use case (and don't vary it) or do nothing at all.  But every client builds their prioritization tree in a different way, which makes it difficult for servers to understand their intent and act or intervene accordingly. </del> <ins> building is rarely exercised.  Experience has shown that clients tend to choose a single model optimized for a web use case and experiment within the model constraints, or do nothing at all.  Furthermore, many clients build their prioritization tree in a unique way, which makes it difficult for servers to understand their intent and act or intervene accordingly. </ins> Many HTTP/2 server implementations do not include support for the priority scheme, some favoring instead bespoke server-driven schemes based on heuristics and other hints, like the content type of <del> resources and the order in which requests arrive.  For example, a server, with knowledge of the document structure, might want to prioritize the delivery of images that are critical to user experience above other images, but below the CSS files.  Since client trees vary, it is impossible for the server to determine how such images should be prioritized against other responses. </del> <ins> resources and the request generation order.  For example, a server, with knowledge of the document structure, might want to prioritize the delivery of images that are critical to user experience above other images, but below the CSS files.  Since client trees vary, it is impossible for the server to determine how such images should be prioritized against other responses. </ins> The HTTP/2 scheme allows intermediaries to coalesce multiple client trees into a single tree that is used for a single upstream HTTP/2
the client learns that the HTTP/2 priority scheme is deprecated, it SHOULD stop sending the HTTP/2 priority signals.  If the client learns that the HTTP/2 priority scheme is not deprecated, it SHOULD <del> stop sending PRIORITY_UPDATE frames, but MAY continue sending the Priority header field, as it is an end-to-end signal that might be useful to nodes behind the server that the client is directly connected to. </del> <ins> stop sending PRIORITY_UPDATE frames (h2-update-frame), but MAY continue sending the Priority header field (header-field), as it is an end-to-end signal that might be useful to nodes behind the server that the client is directly connected to. </ins> The SETTINGS frame precedes any priority signal sent from a client in HTTP/2, so a server can determine if it should respect the HTTP/2
room for future extensions.  Each key-value pair represents a priority parameter. <del> The Priority HTTP header field is an end-to-end way to transmit this set of parameters when a request or a response is issued.  In order to reprioritize a request, HTTP-version-specific frames are used by clients to transmit the same information on a single hop.  If intermediaries want to specify prioritization on a multiplexed HTTP connection, it SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT change the Priority header field. </del> <ins> The Priority HTTP header field (header-field) is an end-to-end way to transmit this set of parameters when a request or a response is issued.  In order to reprioritize a request, HTTP-version-specific frames (h2-update-frame and h3-update-frame) are used by clients to transmit the same information on a single hop.  If intermediaries want to specify prioritization on a multiplexed HTTP connection, they SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT change the Priority header field. </ins> In both cases, the set of priority parameters is encoded as a Structured Headers Dictionary (STRUCTURED-HEADERS).
providing those responses in parallel would be more helpful to the client than delivering the responses one by one. <del> There is no benefit in providing multiple responses with their incremental parameters set to false in parallel, as the client is not going to process those responses incrementally.  Serving non- incremental responses one by one, in the order in which those requests were generated is considered to be the best strategy. </del> <ins> If a client makes concurrent requests with the incremental parameter set to false, there is no benefit serving responses in parallel because the client is not going to process those responses incrementally.  Serving non-incremental responses one by one, in the order in which those requests were generated is considered to be the best strategy. </ins> The following example shows a request for a JPEG file with the urgency parameter set to "5" and the incremental parameter set to
the Priority request header field set to "u=7" (background).  Then, when the user navigates to a page which references the new JavaScript file, while the prefetch is in progress, the browser would send a <del> reprioritization frame with the priority field value set to "u=0" (prerequisite). </del> <ins> reprioritization frame with the priority field value set to "u=0". </ins> In HTTP/2 and HTTP/3, after a request message is sent on a stream, the stream transitions to a state that prevents the client from
Response: <ins> 2.1. A representation digest is the value of the output of a digest algorithm, together with an indication of the algorithm used (and any parameters). As explained in resource-representation the digest is computed on the entire selected "representation data" of the resource defined in RFC7231: The encoded digest output uses the encoding format defined for the specific digest-algorithm. 2.1.1. The "sha-256" digest-algorithm uses base64 encoding.  Note that digest-algorithm values are case insensitive. The "UNIXsum" digest-algorithm uses ASCII string of decimal digits. </ins> 3. <ins> The Want-Digest message header field indicates the sender's desire to receive a representation digest on messages associated with the request URI and representation metadata. If a digest-algorithm is not accompanied by a qvalue, it is treated as if its associated qvalue were 1.0. The sender is willing to accept a digest-algorithm if and only if it is listed in a Want-Digest header field of a message, and its qvalue is non-zero. If multiple acceptable digest-algorithm values are given, the sender's preferred digest-algorithm is the one (or ones) with the highest qvalue. Two examples of its use are 4. The Digest header field provides a digest of the representation data. "Representation data" might be: fully contained in the message body, partially-contained in the message body, or not at all contained in the message body. The resource is specified by the effective request URI and any "validator" contained in the message. For example, in a response to a HEAD request, the digest is calculated using the representation data that would have been enclosed in the payload body if the same request had been a GET. Digest can be used in requests too. The "Digest" value depends on the representation metadata. A Digest header field MAY contain multiple representation-data-digest values.  This could be useful for responses expected to reside in caches shared by users with different browsers, for example. A recipient MAY ignore any or all of the representation-data-digests in a Digest header field.  This allows the recipient to chose which digest-algorithm(s) to use for validation instead of verifying every received representation-data-digest. A sender MAY send a representation-data-digest using a digest- algorithm without knowing whether the recipient supports the digest- algorithm, or even knowing that the recipient will ignore it. Two examples of its use are 5. </ins> Digest algorithm values are used to indicate a specific digest computation.  For some algorithms, one or more parameters may be supplied.