jiebi/CodeConvo huggingface dataset:
Section 6.2.4 of QUIC-RECOVERY, also highlights consideration of application priorities when sending probe packets after Probe Timeout <del> timer expiration.  An QUIC implementation supporting application- </del> <ins> timer expiration.  A QUIC implementation supporting application- </ins> indicated priorities might use the relative priority of streams when choosing probe data. 13. As a general guideline, a server SHOULD NOT use priority information <del> for making schedule decisions across multiple connections, unless it knows that those connections originate from the same client.  Due to this, priority information conveyed over a non-coalesced HTTP </del> <ins> for making scheduling decisions across multiple connections, unless it knows that those connections originate from the same client.  Due to this, priority information conveyed over a non-coalesced HTTP </ins> connection (e.g., HTTP/1.1) might go unused. The remainder of this section discusses scenarios where unfairness is
facing edge might support HTTP/2 and HTTP/3 while communication to back end servers is done using HTTP/1.1.  Unlike with connection coalescing, the CDN will "de-mux" requests into discrete connections <del> to the back end.  As HTTP/1.1 and older do not provide a way to concurrently transmit multiple responses, there is no immediate fairness issue in protocol.  However, back end servers MAY still use client headers for request scheduling.  Back end servers SHOULD only schedule based on client priority information where that information can be scoped to individual end clients.  Authentication and other session information might provide this linkability. </del> <ins> to the back end.  HTTP/1.1 and older do not support response multiplexing in a single connection, so there is not a fairness problem.  However, back end servers MAY still use client headers for request scheduling.  Back end servers SHOULD only schedule based on client priority information where that information can be scoped to individual end clients.  Authentication and other session information might provide this linkability. </ins> 13.3.
The value is encoded as an sf-integer.  The default value is 3. <del> This parameter indicates the sender's recommendation, based on the expectation that the server would transmit HTTP responses in the order of their urgency values if possible.  The smaller the value, the higher the precedence. </del> <ins> Endpoints use this parameter to communicate their view of the precedence of HTTP responses.  The chosen value of urgency can be based on the expectation that servers might use this information to transmit HTTP responses in the order of their urgency.  The smaller the value, the higher the precedence. </ins> The following example shows a request for a CSS file with the urgency set to "0":
If a client makes concurrent requests with the incremental parameter set to false, there is no benefit serving responses with the same <del> urgency in parallel because the client is not going to process those </del> <ins> urgency concurrently because the client is not going to process those </ins> responses incrementally.  Serving non-incremental responses with the same urgency one by one, in the order in which those requests were generated is considered to be the best strategy. If a client makes concurrent requests with the incremental parameter <del> set to true, serving requests with the same urgency in parallel might be beneficial.  Doing this distributes the connection bandwidth, meaning that responses take longer to complete.  Incremental delivery is most useful where multiple partial responses might provide some value to clients ahead of a complete response being available. </del> <ins> set to true, serving requests with the same urgency concurrently might be beneficial.  Doing this distributes the connection bandwidth, meaning that responses take longer to complete. Incremental delivery is most useful where multiple partial responses might provide some value to clients ahead of a complete response being available. </ins> The following example shows a request for a JPEG file with the urgency parameter set to "5" and the incremental parameter set to
about how a server should use size, type or any other input to decide how to prioritize. <del> The following examples demonstrate how a server that strictly abides the scheduling guidance based on urgency and request generation order could find that early requests prevent serving of later requests. </del> <ins> There can be scenarios where a server will need to schedule multiple incremental and non-incremental responses at the same urgency level. Strictly abiding the scheduling guidance based on urgency and request generation order might lead to sub-optimal results at the client, as early non-incremental responses might prevent serving of incremental responses issued later.  The following are examples of such challenges. </ins> At the same urgency level, a non-incremental request for a large resource followed by an incremental request for a small resource.
Digest field calculations are tied to the "Content-Encoding" and "Content-Type" header fields.  Therefore, a given resource may have <del> multiple different checksum values when transferred with HTTP.  To allow both parties to exchange a simple checksum with no content codings (see Section 8.4.1 of SEMANTICS), two more digest-algorithms are added ("id-sha-256" and "id-sha-512"). </del> <ins> multiple different checksum values when transferred with HTTP. </ins> Digest fields do not provide integrity for HTTP messages or fields. However, they can be combined with other mechanisms that protect
Status: insecure <del> To allow sender and recipient to provide a checksum which is independent from "Content-Encoding", the following additional digest- algorithms are defined: Description: The sha-512 digest of the representation data of the resource when no content coding is applied Reference: RFC6234, RFC4648, this document. Status: standard Description: The sha-256 digest of the representation data of the resource when no content coding is applied Reference: RFC6234, RFC4648, this document. Status: standard </del> 7. When the representation enclosed in a state-changing request does not
because user-agent can validate that resource retrieval succeeded before handing off to a HTML parser, video player etc. for parsing. <del> Identity digest-algorithms (e.g. "id-sha-256" and "id-sha-512") are particularly useful for end-to-end integrity because they allow piecing together a resource from different sources with different HTTP messaging characteristics.  For example, different servers that apply different content codings. </del> Note that using digest fields alone does not provide end-to-end integrity of HTTP messages over multiple hops, since metadata could be manipulated at any stage.  Methods to protect metadata are
8.5. Digest fields may expose details of encrypted payload when the <del> checksum is computed on the unencrypted data.  For example, the use of the "id-sha-256" digest-algorithm in conjunction with the encrypted content-coding RFC8188. </del> <ins> checksum is computed on the unencrypted data. </ins> The checksum of an encrypted payload can change between different messages depending on the encryption algorithm used; in those cases
Intermediaries can consume and produce priority signals in a PRIORITY_UPDATE frame or Priority header field.  Sending a PRIORITY_UPDATE frame preserves the signal from the client, but <del> provides a signal that overrides for the next hop; see header-field- rationale.  Replacing or adding a Priority header field overrides any signal from a client and can affect prioritization for all subsequent recipients. </del> <ins> provides a signal that overrides that for the next hop; see header- field-rationale.  Replacing or adding a Priority header field overrides any signal from a client and can affect prioritization for all subsequent recipients. </ins> For both the Priority header field and the PRIORITY_UPDATE frame, the set of priority parameters is encoded as a Structured Fields
clients signal stream dependencies and weights to describe an unbalanced tree.  It suffered from limited deployment and interoperability and was deprecated in a revision of HTTP/2 HTTP2. <del> However, in order to maintain wire compatibility, HTTP/2 priority signals are still mandatory to handle (see HTTP2). </del> <ins> HTTP/2 retains these protocol elements in order to maintain wire compatibility (see HTTP2), which means that they might still be used in the absence of alternative signaling, such as the scheme this document describes. </ins> Clients can build RFC 7540 trees with rich flexibility but experience has shown this is rarely exercised.  Instead they tend to choose a
want-fields defines the Want-Digest and Want-Content-Digest request and response header and trailer field, <del> algorithms and deprecate-contentMD5 describe algorithms and their relation to Digest, </del> <ins> algorithms describes algorithms and their relation to Digest, </ins> state-changing-requests details computing representation digests, <del> obsolete-parameters obsoletes Digest field parameters, and </del> examples-unsolicited and examples-solicited provide examples of using Digest and Want-Digest.
has evolved since RFC3230 was published.  The concept of "instance" has been superseded by "selected representation". <del> This document replaces RFC3230.  The "Digest" and "Want-Digest" field definitions are updated to align with the terms and notational conventions in SEMANTICS.  Changes are intended to be semantically compatible with existing implementations but note that negotiation of "Content-MD5" is deprecated deprecate-contentMD5 and has been replaced by "Content-Digest" negotiation via "Want-Content-Digest". "Digest" field parameters are obsoleted obsolete-parameters and the algorithm table has been updated to reflect the current state of the art. </del> <ins> This document replaces RFC3230.  The changes described in the following paragraphs are intended to be semantically compatible with existing implementations where possible. The "Digest" and "Want-Digest" field definitions are updated to align with the terms and notational conventions in SEMANTICS. Negotiation of "Content-MD5" is deprecated and has been replaced by "Content-Digest" negotiation via "Want-Content-Digest". Sections 4.1.1 and 4.2 of RFC3230 defined field parameters.  This document obsoletes the usage of parameters with "Digest" because this feature has not been widely deployed and complicates field-value processing.  RFC3230 intended field parameters to provide a common way to attach additional information to a representation-data-digest. However, if parameters are used as an input to validate the checksum, an attacker could alter them to steer the validation behavior.  A digest-algorithm can still be parameterized by defining its own way to encode parameters into the representation-data-digest, in such a way as to mitigate security risks related to its computation. The algorithm table has been updated to reflect the current state of the art, (see algorithms). </ins> 1.4.
client's preference for reduced data usage, due to high transfer costs, slow connection speeds, or other reasons. <del> The token is a signal indicating explicit user opt-in into a reduced data usage mode on the client, and when communicated to origins allows them to deliver alternate content honoring such preference - e.g. smaller image and video resources, alternate markup, and so on. </del> <ins> This document defines the "on" sd-token value, which is used as a signal indicating explicit user opt-in into a reduced data usage mode on the client, and when communicated to origins allows them to deliver alternate content honoring such preference - e.g. smaller image and video resources, alternate markup, and so on.  New token and extension token values can only be defined by revisions of this specification. </ins> 8.
interoperability and was deprecated in a revision of HTTP/2 HTTP2. HTTP/2 retains these protocol elements in order to maintain wire compatibility (see HTTP2), which means that they might still be used <del> in the absence of alternative signaling, such as the scheme this document describes. </del> <ins> even in the presence of alternative signaling, such as the scheme this document describes. </ins> Many RFC 7540 server implementations do not act on HTTP/2 priority signals.
3. <del> The priority scheme defined by this document considers only the prioritization of HTTP messages and tunnels, see client-scheduling, server-scheduling, and connect-scheduling. Where HTTP extensions change stream behavior or define new data carriage mechanisms, they can also define how this priority scheme can be applied. </del> <ins> The priority scheme defined by this document is primarily focused on the prioritization of HTTP response messages (see HTTP).  It defines new priority parameters (parameters) and their conveyors (header- field and frame) intended to communicate the priority of responses to a server that is responsible for prioritizing them. server-scheduling provides considerations for servers about acting on those signals in combination with other inputs and factors. The CONNECT method (see HTTP) can be used to establish tunnels. Signaling applies similarly to tunnels; additional considerations for server prioritization are given in connect-scheduling. client-scheduling describes how clients can optionally apply elements of this scheme locally to the request messages that they generate. Some forms of HTTP extensions might change HTTP/2 or HTTP/3 stream behavior or define new data carriage mechanisms.  Such extensions can define themselves how this priority scheme is to be applied. </ins> 4.
This document defines the urgency("u") and incremental("i") parameters.  When receiving an HTTP request that does not carry these priority parameters, a server SHOULD act as if their default values <del> were specified.  Note that handling of omitted parameters is different when processing an HTTP response; see merging. </del> <ins> were specified. An intermediary can combine signals from requests and responses that it forwards.  Note that omission of parameters in responses is handled differently from omission in requests; see merging. </ins> Receivers parse the Dictionary as defined in STRUCTURED-FIELDS. Where the Dictionary is successfully parsed, this document places the
commitment interval starts when the commitment is received and authenticated and runs for a number of seconds equal to value of the "tls-commit" member, less the current age of the http-opportunistic <del> response (as defined in Section 4.2.3 of RFC7234).  A client SHOULD avoid sending requests via cleartext protocols or to unauthenticated alternative services for the duration of the commitment interval, except to discover new potential alternatives. </del> <ins> response (as defined in Section 4.2.3 of RFC7234).  Note that the commitment interval MAY exceed the freshness lifetime of the "http- opportunistic" resource. A client SHOULD avoid sending requests via cleartext protocols or to unauthenticated alternative services for the duration of the commitment interval, except to discover new potential alternatives. </ins> A commitment is not bound to a particular alternative service. Clients are able to use alternative services that they become aware
In contrast to the prioritization scheme of HTTP/2 that uses a hop- by-hop frame, the Priority header field is defined as end-to-end. <del> The rationale is that the Priority header field transmits how each response affects the client's processing of those responses, rather than how relatively urgent each response is to others.  The way a client processes a response is a property associated to that client generating that request.  Not that of an intermediary.  Therefore, it is an end-to-end property.  How these end-to-end properties carried by the Priority header field affect the prioritization between the responses that share a connection is a hop-by-hop issue. </del> <ins> The way that a client processes a response is a property associated with the client generating that request.  Not that of an intermediary.  Therefore, it is an end-to-end property.  How these end-to-end properties carried by the Priority header field affect the prioritization between the responses that share a connection is a hop-by-hop issue. </ins> Having the Priority header field defined as end-to-end is important for caching intermediaries.  Such intermediaries can cache the value
priority.  Expressing priority is therefore only a suggestion. A server can use priority signals along with other inputs to make <del> scheduling decisions.  No guidance is provided about how this can or should be done.  Factors such as implementation choices or deployment environment also play a role.  Any given connection is likely to have many dynamic permutations.  For these reasons, there is no unilateral perfect scheduler and this document only provides some basic recommendations for implementations. </del> <ins> scheduling decisions.  Factors such as implementation choices or deployment environment also play a role.  Any given connection is likely to have many dynamic permutations.  For these reasons, there is no unilateral perfect scheduler.  This document provides some basic, non-exhaustive, recommendations for how servers might act on priority parameters.  It does not describe in detail how servers might combine priority signals with other factors. </ins> Clients cannot depend on particular treatment based on priority signals.  Servers can use other information to prioritize responses.
The incremental parameter indicates how a client processes response bytes as they arrive.  It is RECOMMENDED that, when possible, servers <del> respect the incremental parameter (incremental).  Non-incremental resources can only be used when all of the response payload has been received.  Therefore, non-incremental responses of the same urgency SHOULD be served in their entirety, one-by-one, based on the stream </del> <ins> respect the incremental parameter (incremental). Non-incremental responses of the same urgency SHOULD be served by prioritizing bandwidth allocation in ascending order of the stream </ins> ID, which corresponds to the order in which clients make requests. Doing so ensures that clients can use request ordering to influence response order.
15. <del> RFC7540 stream prioritization relies on dependencies.  Considerations are presented to implementations, describing how limiting state or work commitments can avoid some types of problems.  In addition, CVE- 2019-9513 aka "Resource Loop", is an example of a DoS attack that abuses stream dependencies.  Extensible priorities does not use dependencies, which avoids these issues. </del> frame describes considerations for server buffering of PRIORITY_UPDATE frames.
12. Transport protocols such as TCP and QUIC provide reliability by <del> detecting packet losses and retransmitting lost information.  While this document specifies HTTP-layer prioritization, its effectiveness can be further enhanced if the transport layer factors priority into scheduling both new data and retransmission data.  The remainder of </del> <ins> detecting packet losses and retransmitting lost information.  In addition to the considerations in server-scheduling, scheduling of retransmission data could compete with new data.  The remainder of </ins> this section discusses considerations when using QUIC. QUIC states "Endpoints SHOULD prioritize retransmission of data over
SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2. <ins> If a server which advertises support for Extended CONNECT but receives an Extended CONNECT request with a ":protocol" value that is unknown or is not supported, the server SHOULD respond to the request with a 501 (Not Implemented) status code (HTTP).  A server MAY provide more information via a Problem Details resoponse RFC7807. </ins> 4. This document introduces no new security considerations beyond those
13. <del> As a general guideline, a server SHOULD NOT use priority information for making scheduling decisions across multiple connections, unless it knows that those connections originate from the same client.  Due to this, priority information conveyed over a non-coalesced HTTP connection (e.g., HTTP/1.1) might go unused. The remainder of this section discusses scenarios where unfairness is problematic and presents possible mitigations, or where unfairness is desirable. </del> <ins> Typically, HTTP implementations depend on the underlying transport to maintain fairness between connections competing for bandwidth.  When HTTP requests are forwarded through intermediaries, progress made by each connection originating from end clients can become different over time, depending on how intermediaries coalesce or split requests into backend connections.  This unfairness can expand if priority signals are used. coalescing and h1-backends discuss mitigations against this expansion of unfairness. Conversely, intentional-unfairness discusses how servers might intentionally allocate unequal bandwidth to some connections depending on the priority signals. </ins> 13.1.
When an intermediary coalesces HTTP requests coming from multiple clients into one HTTP/2 or HTTP/3 connection going to the backend <del> server, requests that originate from one client might have higher precedence than those coming from others. </del> <ins> server, requests that originate from one client might carry priority signals indicating higher precedence than those coming from others. </ins> It is sometimes beneficial for the server running behind an intermediary to obey Priority header field values.  As an example, a
parameters, which are a standardized and extensible format of priority information. header-field defines the Priority HTTP header field, a protocol-version-independent and end-to-end priority signal. <del> Clients can use this header to signal priority to servers in order to specify the precedence of HTTP responses.  Similarly, servers behind an intermediary can use it to signal priority to the intermediary. </del> <ins> Clients can send this header field to signal their view of how responses should be prioritized.  Similarly, servers behind an intermediary can use it to signal priority to the intermediary. </ins> After sending a request, a client can change the priority of the response (see reprioritization) using HTTP-version-specific frames defined in h2-update-frame and h3-update-frame.
parameters).  It can appear in requests and responses.  It is an end- to-end signal of the request priority from the client or the response priority from the server.  merging describes how intermediaries can <del> combine the priority information from client requests and server responses to correct or amend the precedence.  Clients cannot interpret the appearance or omission of a Priority response header as acknowledgement that any prioritization has occurred.  Guidance for how endpoints can act on Priority header values is given in server- scheduling and client-scheduling. </del> <ins> combine the priority information sent from clients and servers. Clients cannot interpret the appearance or omission of a Priority response header field as acknowledgement that any prioritization has occurred.  Guidance for how endpoints can act on Priority header values is given in server-scheduling and client-scheduling. </ins> Priority is a Dictionary (STRUCTURED-FIELDS):