jiebi/CodeConvo huggingface dataset:
graphical user agent could send a "visible" parameter to indicate if the resource being requested is within the viewport. <ins> Generic parameters are preferred over vendor-specific, application- specific or deployment-specific values.  If a generic value cannot be agreed upon in the community, the parameter's name should be correspondingly specific (e.g., with a prefix that identifies the vendor, application or deployment). 3.3.1. New Priority parameters can be defined by registering them in the HTTP Priority Parameters Registry. Registration requests are reviewed and approved by a Designated Expert, as per RFC8126, Section 4.5.  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. Registration requests should use the following template: Name: [a name for the Priority Parameter that matches key] Description: [a description of the parameter semantics and value] Reference: [to a specification defining this parameter] See the registry at https://iana.org/assignments/http-priority [4] for details on where to send registration requests. </ins> 4. The Priority HTTP header field can appear in requests and responses.
10.2. <del> Requests without content can still send a "Digest" field applying the digest-algorithm to an empty representation. </del> <ins> In this example, a HEAD request is used to retrieve the checksum of a resource. </ins> The response "Digest" field-value is calculated over the JSON object "{"hello": "world"}", which is not shown because there is no payload data. <del> In this example there is no content coding applied, so the "sha-256" and the "id-sha-256" digest-values in the response would be the same. </del> Request: Response:
below. Some digest-algorithms, although registered, rely on vulnerable <del> algorithms: the "md5" digest-algorithm MUST NOT be used due to collision attacks CMU-836068 and the "sha" digest-algorithm MUST NOT be used due to collision attacks IACR-2020-014. </del> <ins> algorithms and MUST not be used: "md5", see CMU-836068 and NO-MD5; "sha", see IACR-2020-014 and NO-SHA1. See the references above for further information. </ins>
Description: The MD5 algorithm, as specified in RFC1321.  The output of this algorithm is encoded using the base64 encoding RFC4648.  This digest-algorithm MUST NOT be used as it's now <del> vulnerable to collision attacks CMU-836068. </del> <ins> vulnerable to collision attacks.  See NO-MD5 and CMU-836068. </ins> Reference: RFC1321, RFC4648, this document.
Description: The SHA-1 algorithm RFC3174.  The output of this algorithm is encoded using the base64 encoding RFC4648.  This digest-algorithm MUST NOT be used as it's now vulnerable to <del> collision attacks IACR-2020-014. </del> <ins> collision attacks.  See NO-SHA1 and IACR-2020-014. </ins> Reference: RFC3174, RFC6234, RFC4648, this document.
Name: connection_terminated Description: The intermediary's connection to the next hop was <del> closed before any part of the response was received.  If some part was received, see http_response_incomplete. </del> <ins> closed before complete response was received. </ins> Extra Parameters: None. Recommended HTTP status code: 502 <ins> Notes: Responses with this error type might not have been generated by the intermediary. </ins> 2.4.9. Name: connection_timeout
_RFC EDITOR: please remove this section before publication_ <del> This work was originally based on draft-cavage-http-signatures-12, but has since diverged from it, to reflect discussion since adoption by the HTTP Working Group.  In particular, it addresses issues that have been identified, and adds features to support new use cases.  It is a work-in-progress and not yet suitable for deployment. </del> <ins> Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. Working Group information can be found at https://httpwg.org/ [2]; source code and issues list for this draft can be found at https://github.com/httpwg/http-extensions/labels/signatures [3]. </ins> 1.
7.1.  URIs <del> [1] https://openjdk.java.net/groups/net/httpclient/intro.html </del> <ins> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ [2] https://httpwg.org/ [3] https://github.com/httpwg/http-extensions/labels/signatures [4] https://openjdk.java.net/groups/net/httpclient/intro.html </ins> <del> [2] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ </del> <ins> [5] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ </ins> V1_chap04.html#tag_04_16
of SEMANTICS. The definitions "representation", "selected representation", <del> "representation data", "representation metadata", and "payload data" in this document are to be interpreted as described in SEMANTICS. </del> <ins> "representation data", "representation metadata", and "content" in this document are to be interpreted as described in SEMANTICS. </ins> Algorithm names respect the casing used in their definition document (eg.  SHA-1, CRC32c) whereas digest-algorithm tokens are quoted (eg.
The representation digest is an integrity mechanism for HTTP resources which uses a checksum that is calculated independently of <del> the payload data (see Section 6.4 of SEMANTICS).  It uses the </del> <ins> the content (see Section 6.4 of SEMANTICS).  It uses the </ins> representation data (see Section 8.1 of SEMANTICS), that can be fully <del> or partially contained in the payload data, or not contained at all: </del> <ins> or partially contained in the content, or not contained at all: </ins> This takes into account the effect of the HTTP semantics on the <del> messages; for example, the payload data can be affected by Range Requests or methods such as HEAD, while the way the payload data is transferred "on the wire" is dependent on other transformations (e.g. transfer codings for HTTP/1.1 - see Section 6.1 of HTTP11).  To help </del> <ins> messages; for example, the content can be affected by Range Requests or methods such as HEAD, while the way the content is transferred "on the wire" is dependent on other transformations (e.g. transfer codings for HTTP/1.1 - see Section 6.1 of HTTP11).  To help </ins> illustrate how such things affect "Digest", several examples are provided in resource-representation.
responds with a "Digest" field even though the client did not solicit one using "Want-Digest". <del> Some examples include JSON objects in the payload data.  For presentation purposes, objects that fit completely within the line- length limits are presented on a single line using compact notation with no leading space.  Objects that would exceed line-length limits are presented across multiple lines (one line per key-value pair) with 2 spaced of leading indentation. </del> <ins> Some examples include JSON objects in the content.  For presentation purposes, objects that fit completely within the line-length limits are presented on a single line using compact notation with no leading space.  Objects that would exceed line-length limits are presented across multiple lines (one line per key-value pair) with 2 spaced of leading indentation. </ins> "Digest" is media-type agnostic and does not provide canonicalization algorithms for specific formats.  Examples of "Digest" are calculated
The following examples demonstrate interactions where a client solicits a "Digest" using "Want-Digest". <del> Some examples include JSON objects in the payload data.  For presentation purposes, objects that fit completely within the line- length limits are presented on a single line using compact notation with no leading space.  Objects that would exceed line-length limits are presented across multiple lines (one line per key-value pair) with 2 spaced of leading indentation. </del> <ins> Some examples include JSON objects in the content.  For presentation purposes, objects that fit completely within the line-length limits are presented on a single line using compact notation with no leading space.  Objects that would exceed line-length limits are presented across multiple lines (one line per key-value pair) with 2 spaced of leading indentation. </ins> "Digest" is media-type agnostic and does not provide canonicalization algorithms for specific formats.  Examples of "Digest" are calculated
12.7. When "Digest" is used in trailer fields, the receiver gets the digest <del> value after the payload data and may thus be tempted to process the data before validating the digest value.  It is prefereable that data is only be processed after validating the Digest. </del> <ins> value after the content and may thus be tempted to process the data before validating the digest value.  It is prefereable that data is only be processed after validating the Digest. </ins> If received in trailers, "Digest" MUST NOT be discarded; instead, it MAY be merged in the header section (See Section 6.5.1 of SEMANTICS).
required. Certificates - Applications using HTTP should specify that TLS <del> certificates are to be checked according to I-D.ietf-httpbis- semantics, Section 4.3.4 when HTTPS is used. </del> <ins> certificates are to be checked according to Section 4.3.4 of I- D.ietf-httpbis-semantics when HTTPS is used. </ins> Applications using HTTP should not statically require HTTP features that are usually negotiated to be supported by clients.  For example,
validation first because it does not always require a conversion into identity encoding. <del> There is a chance that a user agent supporting both mechanisms may find one validates successfully while the other fails.  This document specifies no requirements or guidance for user agents that experience such cases. </del> <ins> A user agent supporting both mechanisms: - can legitimately ignore "Digest" when using SRI, because digest specifies that "a recipient MAY ignore any or all of the representation-data-digests"; - enforce both "Digest" and SRI: in this case it can be useful to provide enough information to identify whether the mismatch happened at the "Digest" or the SRI level. </ins> 10.
The SEARCH method is used to initiate a server-side search.  Unlike the HTTP GET method, which requests that a server return a <ins> representation of the resource identified by the target URI (as defined by RFCHTTP), the SEARCH method is used to ask the server to perform a query operation (described by the request payload) over some set of data scoped to the effective request URI.  The payload returned in response to a SEARCH cannot be assumed to be a </ins> representation of the resource identified by the effective request <del> URI (as defined by RFC7230), the SEARCH method is used to ask the server to perform a query operation (described by the request payload) over some set of data scoped to the effective request URI. The payload returned in response to a SEARCH cannot be assumed to be a representation of the resource identified by the effective request </del> URI. The body payload of the request defines the query.  Implementations MAY use a request body of any content type with the SEARCH method; however, for backwards compatibility with existing WebDAV implementations, SEARCH requests that use the text/xml or <del> application/xml content types MUST be processed per the requirements </del> <ins> application/xml media types MUST be processed per the requirements </ins> established by RFC5323. SEARCH requests are both safe and idempotent with regards to the
indication as to the final disposition of the search operation.  For instance, a successful search that yields no results can be represented by a 204 No Content response.  If the response includes a <del> body payload, the payload is expected to describe the results of the search operation.  In some cases, the server may choose to respond </del> <ins> content, it is expected to describe the results of the search operation.  In some cases, the server may choose to respond </ins> indirectly to the SEARCH request by returning a 3xx Redirection with <del> a Location header specifying an alternate Request URI from which the search results can be retrieved using an HTTP GET request.  Various non-normative examples of successful SEARCH responses are illustrated in examples. </del> <ins> a Location header field specifying an alternate Request URI from which the search results can be retrieved using an HTTP GET request. Various non-normative examples of successful SEARCH responses are illustrated in examples. </ins> The response to a SEARCH request is not cacheable.  It ought to be noted, however, that because SEARCH requests are safe and idempotent,
The semantics of the SEARCH method change to a "conditional SEARCH" if the request message includes an If-Modified-Since, If-Unmodified- <del> Since, If-Match, If-None-Match, or If-Range header field (RFC7232). </del> <ins> Since, If-Match, If-None-Match, or If-Range header field (RFCHTTP). </ins> A conditional SEARCH requests that the query be performed only under the circumstances described by the conditional header field(s).  It is important to note, however, that such conditions are evaluated
The "Accept-Search" response header field MAY be used by a server to directly signal support for the SEARCH method while identifying the <del> specific query format Content-Type's that may be used. </del> <ins> specific query format media types that may be used. </ins> <del> The Accept-Search header specifies a comma-separated listing of media types (with optional parameters) as defined by RFC7231. </del> <ins> The Accept-Search header field specifies a comma-separated listing of media types (with optional parameters) as defined by RFCHTTP. </ins> <del> The order of types listed by the Accept-Search header is </del> <ins> The order of types listed by the Accept-Search header field is </ins> insignificant. 4.
5. The SEARCH method is subject to the same general security <del> considerations as all HTTP methods as described in RFC7231. </del> <ins> considerations as all HTTP methods as described in RFCHTTP. </ins> 6. IANA is requested to update the registration of the SEARCH method in the permanent registry at <http://www.iana.org/assignments/http- <del> methods> (see RFC7231). </del> <ins> methods> (see RFCHTTP). </ins>
Abstract <del> This document defines the HTTP Digest and Want-Digest fields, thus allowing client and server to negotiate an integrity checksum of the </del> <ins> This document defines the HTTP Digest and Want-Digest fields, which allows client and server to negotiate an integrity checksum of the </ins> exchanged resource representation data. <del> This document obsoletes RFC 3230.  It replaces the term "instance" with "representation", which makes it consistent with the HTTP Semantic and Context defined in draft-ietf-httpbis-semantics. </del> <ins> This document obsoletes RFC 3230. </ins> Note to Readers
resources which uses a checksum that is calculated independently of the content (see Section 6.4 of SEMANTICS).  It uses the representation data (see Section 8.1 of SEMANTICS), that can be fully <del> or partially contained in the content, or not contained at all: </del> <ins> or partially contained in the content, or not contained at all. </ins> This takes into account the effect of the HTTP semantics on the messages; for example, the content can be affected by Range Requests
Digest-algorithm values are used to indicate a specific digest computation. <del> All digest-algorithm values are case-insensitive but lower case is preferred. </del> <ins> All digest-algorithm token values are case-insensitive but lower case is preferred; digest-algorithm token values MUST be compared in a case-insensitive fashion. </ins> <del> The Internet Assigned Numbers Authority (IANA) acts as a registry for digest-algorithm values.  The registry contains the tokens listed below. </del> <ins> The Internet Assigned Numbers Authority (IANA) maintains a registry for digest-algorithm values.  The registry is initialized with the tokens listed below. </ins> <del> Some digest-algorithms, although registered, rely on vulnerable algorithms and MUST not be used: </del> <ins> Deprecated digest algorithms MUST NOT be used: </ins> "md5", see CMU-836068 and NO-MD5;
Description: The MD5 algorithm, as specified in RFC1321.  The output of this algorithm is encoded using the base64 encoding <del> RFC4648.  This digest-algorithm MUST NOT be used as it's now vulnerable to collision attacks.  See NO-MD5 and CMU-836068. </del> <ins> RFC4648.  This digest-algorithm is now vulnerable to collision attacks.  See NO-MD5 and CMU-836068. </ins> Reference: RFC1321, RFC4648, this document.
Description: The SHA-1 algorithm RFC3174.  The output of this algorithm is encoded using the base64 encoding RFC4648.  This <del> digest-algorithm MUST NOT be used as it's now vulnerable to collision attacks.  See NO-SHA1 and IACR-2020-014. </del> <ins> digest-algorithm is now vulnerable to collision attacks.  See NO-SHA1 and IACR-2020-014. </ins> Reference: RFC3174, RFC6234, RFC4648, this document.
algorithm, or even knowing that the recipient will ignore it. "Digest" can be sent in a trailer section.  When an incremental <del> digest-algorithms is used, the sender and the receiver can dynamically compute the digest value while streaming the content. </del> <ins> digest-algorithm is used, the sender and the receiver can dynamically compute the digest value while streaming the content. </ins> 4. The "Want-Digest" field indicates the sender's desire to receive a representation digest on messages associated with the request URI and <del> representation metadata. </del> <ins> representation metadata.  It can be used in both requests and responses. </ins> <del> If a digest-algorithm is not accompanied by a "qvalue", it is treated as if its associated "qvalue" were 1.0. </del> <ins> If a digest-algorithm is not accompanied by a "qvalue" (see Section 12.4.2 ofSEMANTICS), it is treated as if its associated "qvalue" were 1.0. </ins> The sender is willing to accept a digest-algorithm if and only if it is listed in a "Want-Digest" field of a message, and its "qvalue" is
algorithm, or even knowing that the recipient will ignore it. "Digest" can be sent in a trailer section.  In this case, "Digest" <del> MAY be merged in the header section (See Section 6.5.1 of SEMANTICS). </del> <ins> MAY be merged in to the header section (See Section 6.5.1 of SEMANTICS). </ins> When an incremental digest-algorithm is used, the sender and the receiver can dynamically compute the digest value while streaming the
Section 5.4.1) of type PROTOCOL_ERROR. Endpoints MUST send this SETTINGS parameter as part of the first <del> SETTINGS frame.  When the peer receives the first SETTINGS frame, it learns the sender has deprecated the HTTP/2 priority scheme if it receives the SETTINGS_DEPRECATE_HTTP2_PRIORITIES parameter with the value of 1. A sender MUST NOT change the SETTINGS_DEPRECATE_HTTP2_PRIORITIES parameter value after the first SETTINGS frame.  Detection of a change by a receiver MUST be treated as a connection error of type PROTOCOL_ERROR. </del> <ins> SETTINGS frame.  A sender MUST NOT change the SETTINGS_DEPRECATE_HTTP2_PRIORITIES parameter value after the first SETTINGS frame.  Detection of a change by a receiver MUST be treated as a connection error of type PROTOCOL_ERROR. </ins> Until the client receives the SETTINGS frame from the server, the client SHOULD send both the priority signal defined in the HTTP/2 <del> priority scheme and also that of this prioritization scheme.  Once 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 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. </del> <ins> priority scheme and also that of this prioritization scheme.  When the client receives the first SETTINGS frame that contains the SETTINGS_DEPRECATE_HTTP2_PRIORITIES parameter with value of 1, it SHOULD stop sending the HTTP/2 priority signals.  If the value was 0 or if the settings parameter was absent, it SHOULD 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 scheme before building state.  A server that receives <del> SETTINGS_DEPRECATE_HTTP2_PRIORITIES MUST ignore HTTP/2 priority signals. </del> <ins> SETTINGS_DEPRECATE_HTTP2_PRIORITIES with value of 1 MUST ignore HTTP/2 priority signals. </ins> Where both endpoints disable HTTP/2 priorities, the client is expected to send this scheme's priority signal.  Handling of omitted
9.3. <del> The "Cookie Attribute Registry" defines the name space of attribute used to control cookies' behavior.  The registry is maintained at https://www.iana.org/assignments/cookie-attribute-names [4]. </del> <ins> IANA is requested to create the "Cookie Attribute Registry", defining the name space of attribute used to control cookies' behavior.  The registry should be maintained at https://www.iana.org/assignments/ cookie-attribute-names [4]. </ins> 9.3.1.
deployments to work in practice, the reverse proxy needs to convey information about the client certificate to the origin application server.  A common way this information is conveyed in practice today <del> is by using non-standard headers to carry the certificate (in some </del> <ins> is by using non-standard fields to carry the certificate (in some </ins> encoding) or individual parts thereof in the HTTP request that is dispatched to the origin server.  This solution works but interoperability between independently developed components can be cumbersome or even impossible depending on the implementation choices <del> respectively made (like what header names are used or are </del> <ins> respectively made (like what field names are used or are </ins> configurable, which parts of the certificate are exposed, or how the certificate is encoded).  A well-known predictable approach to this commonly occurring functionality could improve and simplify
This document aspires to standardize an HTTP header field named "Client-Cert" that a TLS terminating reverse proxy (TTRP) adds to <del> requests that it sends to the backend origin servers.  The header </del> <ins> requests that it sends to the backend origin servers.  The field </ins> value contains the client certificate from the mutually-authenticated TLS connection between the originating client and the TTRP.  This enables the backend origin server to utilize the client certificate information in its application logic.  While there may be additional proxies or hops between the TTRP and the origin server (potentially even with mutually-authenticated TLS connections between them), the <del> scope of the "Client-Cert" header is intentionally limited to </del> <ins> scope of the "Client-Cert" header field is intentionally limited to </ins> exposing to the origin server the certificate that was presented by the originating client in its connection to the TTRP.
The "Client-Cert" header field defined herein is only for use in HTTP requests and MUST NOT be used in HTTP responses.  It is a single HTTP <del> header field-value as defined in Section 3.2 of RFC7230, which MUST </del> <ins> header field value as defined in Section 3.2 of RFC7230, which MUST </ins> NOT have a list of values or occur multiple times in a request. 2.3.