jiebi/CodeConvo huggingface dataset:
This variation, however, suffers from the same basic limitation as GET in that it is not readily apparent -- absent specific knowledge of the resource and server to which the request is being sent -- that <del> a search operation is what is being requested.  Web applications use the POST method for a wide variety of uses including the creation or modification of existing resources.  Sending the request above to a different server, or even repeatedly sending the request to the same server could have dramatically different effects. </del> <ins> a safe, idempotent query is being performed. </ins> <del> The SEARCH method provides a solution that spans the gap between the </del> <ins> The QUERY method provides a solution that spans the gap between the </ins> use of GET and POST.  As with POST, the input to the query operation is passed along within the payload of the request rather than as part <del> of the request URI.  Unlike POST, however the semantics of the SEARCH method are specifically defined. </del> <ins> of the request URI.  Unlike POST, however, the method is explicitly safe and idempotent, allowing functions like caching and automatic retries to operate. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
5. <del> The SEARCH method is subject to the same general security </del> <ins> The QUERY method is subject to the same general security </ins> considerations as all HTTP methods as described in RFCHTTP. 6. <del> IANA is requested to update the registration of the SEARCH method in the permanent registry at <http://www.iana.org/assignments/http- methods> (see RFCHTTP). </del> <ins> IANA is requested to add QUERY method in the permanent registry at <http://www.iana.org/assignments/http-methods> (see RFCHTTP). </ins>
3. <del> The "Accept-Search" response header field MAY be used by a server to directly signal support for the SEARCH method while identifying the specific query format media types that may be used. </del> <ins> The "Accept-Query" response header field MAY be used by a server to directly signal support for the QUERY method while identifying the specific query format media type(s) that may be used. </ins> <del> The Accept-Search header field specifies a comma-separated listing of </del> <ins> The Accept-Query header field specifies a comma-separated listing of </ins> media types (with optional parameters) as defined by RFCHTTP. <del> The order of types listed by the Accept-Search header field is </del> <ins> The order of types listed by the Accept-Query header field is </ins> insignificant. 4.
15. <del> CVE-2019-9513 aka "Resource Loop", is a DoS attack based on manipulation of the RFC 7540 priority tree.  Extensible priorities does not use stream dependencies, which mitigates this vulnerability. Section 5.3.4 of RFC7540 describes a scenario where closure of streams in the priority tree could cause suboptimal prioritization. To avoid this, RFC7540 states that "an endpoint SHOULD retain stream prioritization state for a period after streams become closed". Retaining state for streams no longer counted towards stream concurrency consumes server resources.  Furthermore, RFC7540 identifies that reprioritization of a closed stream could affect dependents; it recommends updating the priority tree if sufficient state is stored, which will also consume server resources.  To limit this commitment, it is stated that "The amount of prioritization state that is retained MAY be limited" and "If a limit is applied, endpoints SHOULD maintain state for at least as many streams as allowed by their setting for SETTINGS_MAX_CONCURRENT_STREAMS.". Extensible priorities does not use stream dependencies, which minimizes most of the resource concerns related to this scenario. Section 5.3.4 of RFC7540 also presents considerations about the state required to store priority information about streams in an "idle" state.  This state can be limited by adopting the guidance about concurrency limits described above.  Extensible priorities is subject to a similar consideration because PRIORITY_UPDATE frames may arrive before the request that they reference.  A server is required to store the information in order to apply the most up-to-date signal to the request.  However, HTTP/3 implementations might have practical </del> <ins> 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. frame describes considerations for server buffering of PRIORITY_UPDATE frames.  HTTP/3 implementations might have practical </ins> barriers to determining reasonable stream concurrency limits depending on the information that is available to them from the QUIC transport layer. <ins> server-scheduling presents examples where servers that prioritize responses in a certain way might be starved of the ability to transmit payload. The security considerations from STRUCTURED-FIELDS apply to processing of priority parameters defined in parameters. </ins> 16. This specification registers the following entry in the Permanent
parameter (urgency), sending higher urgency responses before lower urgency responses. <del> It is RECOMMENDED that, when possible, servers respect the incremental parameter (incremental).  Non-incremental responses of the same urgency SHOULD be served one-by-one based on the Stream ID, which corresponds to the order in which clients make requests.  Doing so ensures that clients can use request ordering to influence response order.  Incremental responses of the same urgency SHOULD be served in round-robin manner. </del> The incremental parameter indicates how a client processes response <del> bytes as they arrive.  Non-incremental resources are only used when all of the response payload has been received.  Incremental resources are used as parts, or chunks, of the response payload are received. Therefore, the timing of response data reception at the client, such as the time to early bytes or the time to receive the entire payload, plays an important role in perceived performance.  Timings depend on resource size but this scheme provides no explicit guidance about how a server should use size as an input to prioritization.  Instead, the following examples demonstrate how a server that strictly abides the scheduling guidance based on urgency and request generation order </del> <ins> bytes as they arrive.  It is RECOMMENDED that, when possible, servers 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 ID, which corresponds to the order in which clients make requests. Doing so ensures that clients can use request ordering to influence response order. Incremental responses of the same urgency SHOULD be served by sharing bandwidth amongst them.  Incremental resources are used as parts, or chunks, of the response payload are received.  A client might benefit more from receiving a portion of all these resources rather than the entirety of a single resource.  How large a portion of the resource is needed to be useful in improving performance varies.  Some resource types place critical elements early, others can use information progressively.  This scheme provides no explicit mandate about how a server should use size, type or any other input to decide how to prioritize. The following examples demonstrate how a server that strictly abides the scheduling guidance based on urgency and request generation order </ins> could find that early requests prevent serving of later requests. At the same urgency level, a non-incremental request for a large
In order to mitigate this fairness problem, a server could use knowledge about the intermediary as another signal in its prioritization decisions.  For instance, if a server knows the <del> intermediary is coalescing requests, then it could serve the responses in round-robin manner.  This can work if the constrained </del> <ins> intermediary is coalescing requests, then it could avoid serving the responses in their entirety and instead distribute bandwidth (for example, in a round-robin manner).  This can work if the constrained </ins> resource is network capacity between the intermediary and the user agent, as the intermediary buffers responses and forwards the chunks based on the prioritization scheme it implements.
The ORIGIN frame contains the following fields, sets of which may be repeated within the frame to indicate multiple origins: <del> Origin-Len: An unsigned, 16-bit integer indicating the length, in octets, of the Origin field.  Origin: An optional sequence of characters containing the ASCII serialization of an origin (RFC6454, Section 6.2) that the sender believes this connection is authoritative for. </del> <ins> An unsigned, 16-bit integer indicating the length, in octets, of the Origin field. An optional sequence of characters containing the ASCII serialization of an origin (RFC6454, Section 6.2) that the sender believes this connection is authoritative for. </ins> The ORIGIN frame does not define any flags.  It can contain one or more Origin-Len/Origin pairs.
1. <del> It is common for an HTTP HTTP resource representation to have </del> <ins> It is common for representations of an HTTP HTTP resource to have </ins> relationships to one or more other resources.  Clients will often discover these relationships while processing a retrieved <del> representation, leading to further retrieval requests.  Meanwhile, the nature of the relationship determines whether the client is blocked from continuing to process locally available resources.  For example, visual rendering of an HTML document could be blocked by the retrieval of a CSS file that the document refers to.  In contrast, inline images do not block rendering and get drawn incrementally as the chunks of the images arrive. To provide meaningful presentation of a document at the earliest </del> <ins> representation, which may lead to further retrieval requests. Meanwhile, the nature of the relationship determines whether the client is blocked from continuing to process locally available resources.  An example of this is visual rendering of an HTML document, which could be blocked by the retrieval of a CSS file that the document refers to.  In contrast, inline images do not block rendering and get drawn incrementally as the chunks of the images arrive. HTTP/2 HTTP2 and HTTP/3 HTTP3 support multiplexing of requests and responses in a single connection.  An important feature of any implementation of a protocol that provides multiplexing is the ability to prioritize the sending of information.  For example, to provide meaningful presentation of an HTML document at the earliest </ins> moment, it is important for an HTTP server to prioritize the HTTP <del> responses, or the chunks of those HTTP responses, that it sends. </del> <ins> responses, or the chunks of those HTTP responses, that it sends to a client. A server that operates in ignorance of how clients issue requests and consume responses can cause suboptimal client application performance.  Priority signals allow clients to communicate their view of request priority.  Servers have their own needs that are independent from client needs, so they often combine priority signals with other available information in order to inform scheduling of response data. </ins> RFC 7540 RFC7540 stream priority allowed a client to send a series of priority signals that communicate to the server a "priority tree";
responses that uses absolute values. parameters defines priority parameters, which are a standardized and extensible format of priority information. header-field defines the Priority HTTP header <del> field that can be used by both client and server to exchange parameters in order to specify the precedence of HTTP responses in a protocol-version-independent and end-to-end manner.  h2-update-frame and h3-update-frame define version-specific frames that carry parameters for reprioritization.  This prioritization scheme and its signals can act as a substitute for RFC 7540 stream priority. </del> <ins> field, a protocol-version-independent and end-to-end priority signal. 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. h2-update-frame and h3-update-frame define version-specific frames that carry parameters, which clients can use for reprioritization. Header field and frame priority signals are input to a server's response prioritization process.  They are only a suggestion and do not guarantee any particular processing or transmission order for one response relative to any other response. server-scheduling and retransmission-scheduling provide consideration and guidance about how servers might act upon signals. The prioritization scheme and priority signals defined herein can act as a substitute for RFC 7540 stream priority. </ins> 1.1.
2. <del> An important feature of any implementation of a protocol that provides multiplexing is the ability to prioritize the sending of information.  Prioritization is a difficult problem, so it will always be suboptimal, particularly if one endpoint operates in ignorance of the needs of its peer.  Priority signalling allows endpoints to communicate their own view of priority, which can be combined with information the peer has to inform scheduling. </del> RFC 7540 stream priority (see Section 5.3 of RFC7540) is a complex system where clients signal stream dependencies and weights to describe an unbalanced tree.  It suffered from limited deployment and
Many RFC 7540 server implementations do not act on HTTP/2 priority signals.  Some instead favor custom server-driven schemes based on heuristics or other hints, such as resource content type or request <del> generation order.  For example, a server, with knowledge of the </del> <ins> generation order.  For example, a server, with knowledge of an HTML </ins> 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
they do not adversely interfere with prioritization performed by existing endpoints or intermediaries that do not understand the newly defined parameter.  Since unknown parameters are ignored, new <del> parameters should not change the interpretation of or modify the predefined parameters in a way that is not backwards compatible or fallback safe. </del> <ins> parameters should not change the interpretation of, or modify, the urgency (see urgency) or incremental (see incremental) parameters in a way that is not backwards compatible or fallback safe. </ins> For example, if there is a need to provide more granularity than eight urgency levels, it would be possible to subdivide the range
4.3.1. New Priority parameters can be defined by registering them in the <del> HTTP Priority Parameters Registry. Registration requests are reviewed and approved by a Designated Expert, as per Section 4.5 of RFC8126.  A specification document is appreciated, but not required. The Expert(s) should consider the following factors when evaluating requests: Community feedback If the parameters are sufficiently well-defined and adhere to the guidance provided in new-parameters. </del> <ins> HTTP Priority Parameters Registry.  The registry governs the keys (short textual strings) used in Structured Fields Dictionary (see Section 3.2 of STRUCTURED-FIELDS).  Since each HTTP request can have associated priority signals, there is value in having short key lengths, especially single-character strings.  In order to encourage extension while avoiding unintended conflict among attractive key values, the HTTP Priority Parameters Registry operates two registration policies depending on key length. Registration requests for parameters with a key length of one use the Specification Required policy, as per Section 4.6 of RFC8126. Registration requests for parameters with a key length greater than one use the Expert Review policy, as per Section 4.5 of RFC8126.  A specification document is appreciated, but not required. When reviewing registration requests, the designated expert(s) can consider the additional guidance provided in new-parameters but cannot use it as a basis for rejection. </ins> Registration requests should use the following template: <del> Name: [a name for the Priority Parameter that matches key] </del> <ins> [a name for the Priority Parameter that matches key] </ins> <del> Description: [a description of the parameter semantics and value] </del> <ins> [a description of the parameter semantics and value] </ins> <del> Reference: [to a specification defining this parameter] </del> <ins> [to a specification defining this parameter] </ins> See the registry at https://iana.org/assignments/http-priority [4] for details on where to send registration requests.
Stream ID MUST be within the client-initiated bidirectional stream limit.  If a server receives a PRIORITY_UPDATE (type=0xF0700) with a Stream ID that is beyond the stream limits, this SHOULD be treated as <del> a connection error of type H3_ID_ERROR. </del> <ins> a connection error of type H3_ID_ERROR.  Generating an error is not mandatory because HTTP/3 implementations might have practical barriers to determining the active stream concurrency limit that is applied by the QUIC layer. </ins> The push-stream variant PRIORITY_UPDATE (type=0xF0701) MUST reference a promised push stream.  If a server receives a PRIORITY_UPDATE
A PRIORITY_UPDATE frame communicates a complete set of all parameters in the Priority Field Value field.  Omitting a parameter is a signal to use the parameter's default value.  Failure to parse the Priority <del> Field Value MUST be treated as a connection error.  In HTTP/2 the </del> <ins> Field Value MAY be treated as a connection error.  In HTTP/2 the </ins> error is of type PROTOCOL_ERROR; in HTTP/3 the error is of type <del> H3_FRAME_ERROR. </del> <ins> H3_GENERAL_PROTOCOL_ERROR. </ins> A client MAY send a PRIORITY_UPDATE frame before the stream that it references is open (except for HTTP/2 push streams; see h2-update-
some other appropriate value e.g. according to the type and status of the primary document <del> in which the algorithm is defined; "deprecated" when the algorithm is insecure or otherwise undesirable; "reserved" when Digest algorithm references a reserved token value </del> <ins> in which the algorithm is defined; "insecure" when the algorithm is insecure; "reserved" when Digest algorithm references a reserved token value </ins> Description: the description of the digest-algorithm and its encoding
represented as a quoted string or MUST NOT include ";" or "," in the character sets used for the encoding. <del> Deprecated digest algorithms MUST NOT be used. </del> <ins> Insecure digest algorithms MAY be used to preserve integrity against accidental change, but MUST NOT be used in a potentially adversarial setting; for example, when signing the digest of content for authenticity. </ins> The registry is initialized with the tokens listed below.
algorithm. An endpoint might have a preference for algorithms, such as <del> preferring "standard" algorithms over "deprecated" ones.  Transition </del> <ins> preferring "standard" algorithms over "insecure" ones.  Transition </ins> from weak algorithms is supported by negotiation of digest-algorithm using "Want-Digest" or "Want-Content-Digest" (see want-fields) or by sending multiple representation-data-digest values from which the
RFC3230 has been added to the HTTP Digest Algorithm Values Registry with the "obsoleted" status. <del> All digest-algorithms defined in RFC3230 are now "deprecated". </del> <ins> All digest-algorithms defined in RFC3230 are now "insecure". </ins> 9.4. The digest-algorithm tokens for "MD5", "SHA", "SHA-256", "SHA-512" have been updated to lowercase. <del> The status of "MD5" and "SHA" has been updated to "deprecated", and </del> <ins> The status of "MD5" and "SHA" has been updated to "insecure", and </ins> their description has been modified accordingly. The "id-sha-256" and "id-sha-512" algorithms have been added to the
The problems and insights set out above provided the motivation for deprecating RFC 7540 stream priority (see Section 5.3 of RFC7540). <del> The SETTINGS_NO_RFC7540_PRIORITIES setting is defined by this </del> <ins> The SETTINGS_NO_RFC7540_PRIORITIES HTTP/2 setting is defined by this </ins> document in order to allow endpoints to explicitly opt out of using HTTP/2 priority signals (see Section 5.3.2 of HTTP2).  Endpoints are encouraged to use alternative priority signals (for example, header-
The value of SETTINGS_NO_RFC7540_PRIORITIES MUST be 0 or 1.  Any value other than 0 or 1 MUST be treated as a connection error (see <del> Section 5.4.1 of HTTP2) of type PROTOCOL_ERROR. </del> <ins> Section 5.4.1 of HTTP2) of type PROTOCOL_ERROR.  The initial value is 0. </ins> Endpoints MUST send this SETTINGS parameter as part of the first SETTINGS frame.  A sender MUST NOT change the
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 <del> 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. </del> <ins> PRIORITY_UPDATE 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 Fields Dictionary (see Section 3.2 of STRUCTURED-FIELDS).
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 <del> acknowledgement that any prioritization has occurred. </del> <ins> 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 (Section 3.2 of STRUCTURED-FIELDS):
because there is no explicit client-signalled initial priority.  A server can apply priority signals provided in an origin response; see the merging guidance given in merging.  In the absence of origin <del> signals, applying default parameter values could be suboptimal.  How ever a server decides to schedule a pushed response, it can signal the intended priority to the client by including the Priority field in a PUSH_PROMISE or HEADERS frame. </del> <ins> signals, applying default parameter values could be suboptimal.  By whatever means a server decides to schedule a pushed response, it can signal the intended priority to the client by including the Priority field in a PUSH_PROMISE or HEADERS frame. </ins> 10.1.