jiebi/CodeConvo huggingface dataset:
Given an ASCII string as input_string, return a string of Unicode characters. input_string is modified to remove the parsed value. <del> If the first character of input_string is not "%", fail parsing. </del> <ins> If the first two characters of input_string are not "%" followed by DQUOTE, fail parsing. </ins> <del> Discard the first character of input_string. </del> <ins> Discard the first two characters of input_string. </ins> <del> Let parsed_string be the result of running Parsing a String (parse-string) with input_string. </del> <ins> Let byte_array be an empty byte array. </ins> <del> Let byte_array be the result of applying ASCII encoding to input_string. </del> <ins> While input_string is not empty: </ins> <del> For each sigil_byte in byte_array which is %25 ("%"): </del> <ins> Let char be the result of consuming the first character of input_string. If char is in the range %x00-1f or %x7f-ff (i.e., it is not in VCHAR or SP), fail parsing. If char is "%": Let octet_hex be the result of consuming two characters from input_string.  If there are not two characters, fail parsing. </ins> <del> Let octet_hex be the two bytes after sigil_byte in byte_string. If there are not two bytes, fail parsing. </del> <ins> Let octet be the result of hex decoding octet_hex (Section 8 of RFC4648), in a case-insensitive fashion.  If decoding fails, fail parsing. </ins> <del> Let octet be the result of decoding octet_hex as hexidecimal, in a case-insensitive fashion. </del> <ins> Append octet to byte_array. </ins> <del> Replace sigil_byte and octet_hex in byte_array with octet. </del> <ins> If char is DQUOTE: </ins> <del> Let unicode_string be the result of decoding byte_array as a UTF-8 string UTF8.  Fail parsing if decoding fails. </del> <ins> Let unicode_string be the result of decoding byte_array as a UTF-8 string UTF8.  Fail parsing if decoding fails. </ins> <del> Return unicode_string. </del> <ins> Return unicode_string. Otherwise, if char is not "%" or DQUOTE: Let byte be the result of applying ASCII encoding to char. Append byte to byte_array. Reached the end of input_string without finding a closing DQUOTE; fail parsing. </ins> 5.
MUST acknowledge it by responding with the "201 (Created)" status code, the "Upload-Incomplete" header set to true. <ins> If the request includes the "Upload-Complete: ?1" header field and a valid "Content-Length" header field, the client attempts to upload a fixed-length resource in one request.  In this case, the upload's final size is the value of the "Content-Length" header field and the server MUST record the upload's final size to ensure its consistency with future Upload Appending Procedures. </ins> If the client received an informational repsonse with the upload URL, it MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a server error status code between 500
MUST acknowledge it by responding with the "201 (Created)" status code, the "Upload-Incomplete" header set to true. <ins> If the request includes the "Upload-Complete: ?1" header field and a valid "Content-Length" header field, the client attempts to upload the remaining resource in one request.  In this case, the upload's final size is the sum of the upload's offset and the "Content-Length" header field.  If the server does not have a record of the upload's final size from the Upload Creation or previous Upload Appending Procedures, the server MUST record the upload's final size to ensure its consistency with future Upload Appending Procedures.  If the server does have a previous record, the upload's final size from a previous procedure MUST match the upload's final size from the current Upload Appending Procedure.  If they do not match, the server MUST reject the request with the "400 (Bad Request)" status code. </ins> The client MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a server error status code between 500 and 599 (inclusive) is received.  The client SHOULD
The key exporter context contains the following fields: The Signature Algorithm and Port fields are encoded as unsigned <del> 16-bit integers in network byte order.  The Key ID, Scheme, Host, and Real fields are length prefixed strings; they are preceded by a Length field that represents their length in bytes.  These length fields are encoded using the variable-length integer encoding from QUIC and MUST be encoded in the minimum number of bytes necessary. </del> <ins> 16-bit integers in network byte order.  The Key ID, Public Key, Scheme, Host, and Real fields are length prefixed strings; they are preceded by a Length field that represents their length in bytes. These length fields are encoded using the variable-length integer encoding from QUIC and MUST be encoded in the minimum number of bytes necessary. The encoding of the public key is determined by the Signature Algorithm in use as follows: This document does not define the public key encodings for other algorithms.  In order for a SignatureScheme to be usable with the Signature HTTP authentication scheme, its public key encoding needs to be defined in a corresponding document. </ins> 4.2.
5.2. <ins> The REQUIRED "a" (public key) parameter is a byte sequence that contains the public key used by the server to validate the signature provided by the client.  This avoids key confusion issues (see SEEMS- LEGIT).  The encoding of the public key is described in context. 5.3. </ins> The REQUIRED "p" (proof) parameter is a byte sequence that specifies the proof that the user agent provides to attest to possessing the credential that matches its key ID. <del> 5.3. </del> <ins> 5.4. </ins> The REQUIRED "s" (signature) parameter is an integer that specifies the signature scheme used to compute the proof transmitted in the "p"
FIELDS that contains one or more DNS names in a comma-separated list. The items in the list include all alias names and canonical names received in CNAME records DNS during the course of resolving the next <del> hop's hostname using DNS, not including the original requested </del> <ins> hop's hostname using DNS, and MAY include the original requested </ins> hostname itself.  The names SHOULD appear in the order in which they were received in DNS.  If there are multiple CNAME records in the chain, the first name in the "next-hop-aliases" list would be the
"next-hop" and "next-hop-aliases" parameters, "next-hop-aliases" can be included without including "next-hop". <ins> The proxy can also include the name of the next hop as the first item in the list.  This is particularly useful for reverse proxies when clients would not otherwise know the name of the next hop, and the "next-hop" header is used to convey an IP address. For example, consider a proxy "reverseproxy.example.net" that receives the following records when performing DNS resolution for the next hop "host.example.com": The proxy could include the following proxy status in its response: </ins> The "next-hop-aliases" parameter only applies when DNS was used to resolve the next hop's name, and does not apply in all situations. Clients can use the information in this parameter to determine how to
4.1. When using this specification in HTTP/2 or HTTP/3, clients MAY start <del> sending TCP stream content without waiting for an HTTP response. Proxies MUST buffer this "false start" content until the TCP stream becomes writable, and discard it if the TCP connection fails.  (This "false start" behavior is not permitted in HTTP/1.1 because it would prevent reuse of the connection after an error response such as 407 (Proxy Authentication Required).) </del> <ins> sending TCP stream content optimistically, subject to flow control limits (RFC9113)(RFC9000).  Proxies MUST buffer this "optimistic" content until the TCP stream becomes writable, and discard it if the TCP connection fails.  (This "optimistic" behavior is not permitted in HTTP/1.1 because it would prevent reuse of the connection after an error response such as "407 (Proxy Authentication Required)".) </ins> Servers that host a proxy under this specification MAY offer support for TLS early data in accordance with RFC8470.  Clients MAY send <del> "connect-tcp" requests in early data, and MAY include "false start" content in early data (in HTTP/2 and HTTP/3).  Proxies MAY accept, reject, or delay processing of this early data.  For example, a proxy with limited anti-replay defenses might choose to perform DNS resolution of the "target_host" when a request arrives in early data, but delay the TCP connection until the TLS handshake completes. </del> <ins> "connect-tcp" requests in early data, and MAY include "optimistic" TCP content in early data (in HTTP/2 and HTTP/3).  At the TLS layer, proxies MAY ignore, reject, or accept the "early_data" extension (RFC8446).  At the HTTP layer, proxies MAY process the request immediately, return a "425 (Too Early)" response (RFC8470), or delay some or all processing of the request until the handshake completes. For example, a proxy with limited anti-replay defenses might choose to perform DNS resolution of the "target_host" when a request arrives in early data, but delay the TCP connection until the TLS handshake completes. </ins> 4.2.
sequence of procedures. 1) If the client is aware that the server supports resumable upload, <del> it can use the Upload Creation Procedure with the "Upload-Incomplete" header to start an upload.  The client can include the first part of the file in the Upload Creation Procedure. </del> <ins> it can use the Upload Creation Procedure with the "Upload-Complete: ?0" header to start an upload.  The client can include the first part of the file in the Upload Creation Procedure. </ins> 2) After creation, the following parts are sent using the Upload Appending Procedure (upload-appending), and the last part of the <del> upload does not have the "Upload-Incomplete" header. </del> <ins> upload has the "Upload-Complete: ?1" header to indicate the complete transfer. </ins> 4.
otherwise intended.  The server MAY only support a limited number of methods. <del> The request MUST include the "Upload-Incomplete" header field (upload-incomplete).  It MUST be set to true if the end of the request body is not the end of the upload.  Otherwise, it MUST be set to false.  This header field can be used for request identification by a server.  The request MUST NOT include the "Upload-Offset" header. </del> <ins> The request MUST include the "Upload-Complete" header field (upload- complete).  It MUST be set to false if the end of the request body is not the end of the upload.  Otherwise, it MUST be set to true.  This header field can be used for request identification by a server.  The request MUST NOT include the "Upload-Offset" header. </ins> If the request is valid, the server SHOULD create an upload resource. If so, the server MUST include the "Location" header in the response
complete, the server MUST acknowledge it by responding with a successful status code between 200 and 299 (inclusive).  Server is RECOMMENDED to use "201 (Created)" response if not otherwise <del> specified.  The response MUST NOT include the "Upload-Incomplete" header with the value of true. </del> <ins> specified.  The response MUST NOT include the "Upload-Complete" header with the value of false. </ins> If the request completes successfully but the entire upload is not <del> yet complete indicated by the "Upload-Incomplete" header, the server MUST acknowledge it by responding with the "201 (Created)" status code, the "Upload-Incomplete" header set to true. </del> <ins> yet complete indicated by the "Upload-Complete: ?0" header, the server MUST acknowledge it by responding with the "201 (Created)" status code, the "Upload-Complete" header set to false. </ins> If the client received an informational repsonse with the upload URL, it MAY automatically attempt upload resumption when the connection is
If the client has no knowledge of whether the resource supports resumable uploads, the Upload Creation Procedure MAY be used with <del> some additional constraints.  In particular, the "Upload-Incomplete" header field (upload-incomplete) MUST NOT be set to true if the server support is unclear.  This allows the upload to function as if it is a regular upload. </del> <ins> some additional constraints.  In particular, the "Upload-Complete" header field (upload-complete) MUST NOT be set to false if the server support is unclear.  This allows the upload to function as if it is a regular upload. </ins> The server SHOULD send the "104 (Upload Resumption Supported)" informational response to the client, to indicate its support for a
knowledge of server support. The request MUST NOT include the "Upload-Offset" header or the <del> "Upload-Incomplete" header.  The server MUST reject the request with the "Upload-Offset" header or the "Upload-Incomplete" header by sending a "400 (Bad Request)" response. </del> <ins> "Upload-Complete" header.  The server MUST reject the request with the "Upload-Offset" header or the "Upload-Complete" header by sending a "400 (Bad Request)" response. </ins> If the server considers the upload associated with this upload URL active, it MUST send back a "204 (No Content)" response.  The response MUST include the "Upload-Offset" header set to the current resumption offset for the client.  The response MUST include the <del> "Upload-Incomplete" header which is set to true if and only if the upload is incomplete.  An upload is considered complete if and only if the server completely and successfully received a corresponding </del> <ins> "Upload-Complete" header which is set to true if and only if the upload is complete.  An upload is considered complete if and only if the server completely and successfully received a corresponding </ins> Upload Creation Procedure (upload-creation) or Upload Appending <del> Procedure (upload-appending) request with the "Upload-Incomplete" header being omitted or set to false. </del> <ins> Procedure (upload-appending) request with the "Upload-Complete" header being set to true. </ins> The client MUST NOT perform the Offset Retrieving Procedure (offset- retrieving) while the Upload Creation Procedure (upload-creation) or
complete, the server MUST acknowledge it by responding with a successful status code between 200 and 299 (inclusive).  Server is RECOMMENDED to use "201 (Created)" response if not otherwise <del> specified.  The response MUST NOT include the "Upload-Incomplete" header with the value of true. </del> <ins> specified.  The response MUST NOT include the "Upload-Complete" header with the value of false. </ins> If the request completes successfully but the entire upload is not <del> yet complete indicated by the "Upload-Incomplete" header, the server </del> <ins> yet complete indicated by the "Upload-Complete" header, the server </ins> MUST acknowledge it by responding with the "201 (Created)" status <del> code, the "Upload-Incomplete" header set to true. </del> <ins> code, the "Upload-Complete" header set to true. </ins> The client MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a server error status
knowledge of server support. The request MUST use the "DELETE" method.  The request MUST NOT <del> include the "Upload-Offset" header or the "Upload-Incomplete" header. </del> <ins> include the "Upload-Offset" header or the "Upload-Complete" header. </ins> The server MUST reject the request with the "Upload-Offset" header or <del> the "Upload-Incomplete" header by sending a "400 (Bad Request)" </del> <ins> the "Upload-Complete" header by sending a "400 (Bad Request)" </ins> response. If the server has successfully deactivated this upload URL, it MUST
9.2. <del> The "Upload-Incomplete" request and response header field is an Item </del> <ins> The "Upload-Complete" request and response header field is an Item </ins> Structured Header indicating whether the corresponding upload is considered complete.  Its value MUST be a boolean.  Its ABNF is <del> The "Upload-Incomplete" header field MUST only by used if support by </del> <ins> The "Upload-Complete" header field MUST only by used if support by </ins> the resource is known to the client (feature-detection). 10.
input_string.  If there are not two characters, fail parsing. <ins> If octet_hex contains characters outside the range %x30-39 or %x61-66 (i.e., it is not in 0-9 or lowercase a-f), fail parsing. </ins> Let octet be the result of hex decoding octet_hex (Section 8 <del> of RFC4648), in a case-insensitive fashion.  If decoding fails, fail parsing. </del> <ins> of RFC4648). </ins> Append octet to byte_array.
An origin server that supports the resolution of "http" URIs can indicate support for this specification by providing an alternative service advertisement RFC7838 for a protocol identifier that uses <del> TLS, such as "h2" RFC7540, or "http/1.1" RFC7301.  Note that HTTP/1.1 requests MUST use the absolute form (see Section 5.3.2 of RFC7230). </del> <ins> TLS, such as "h2" RFC7540.  Such a protocol MUST include an explicit indication of the scheme of the resource.  This excludes HTTP/1.1; HTTP/1.1 clients are forbidden from including the absolute form of a URI in requests to origin servers (see Section 5.3.1 of RFC7230). </ins> A client that receives such an advertisement MAY make future requests <del> intended for the associated origin (RFC6454) to the identified service (as specified by RFC7838), provided that the alternative service opts in as described in auth. </del> <ins> intended for the associated origin RFC6454 to the identified service (as specified by RFC7838), provided that the alternative service opts in as described in opt-in. </ins> A client that places the importance of protection against passive attacks over performance might choose to withhold requests until an
to determine if a request is for an "https" resource; for example, they might look for TLS on the stack, or a server port number of 443. <del> This might be due to limitations in the protocol (the most common HTTP/1.1 request form does not carry an explicit indication of the URI scheme), or it may be because how the server and application are </del> <ins> This might be due to expected limitations in the protocol (the most common HTTP/1.1 request form does not carry an explicit indication of the URI scheme and the resource might have been developed assuming HTTP/1.1), or it may be because how the server and application are </ins> implemented (often, they are two separate entities, with a variety of possible interfaces between them).
The "hashes" value is optional and defaults to (sha-256). <del> 2.1.5. </del> <ins> 2.1.7. </ins> <del> 2.1.5.1. </del> <ins> 2.1.7.1. </ins> A response that contained a response header: <del> Would specify matching any URL with a path prefix of /product/ on the same Origin as the original request, expiring as a dictionary in 7 days independent of the cache lifetime of the resource, and advertise support for both sha-256 and sha-512 hash algorithms. </del> <ins> Would specify matching any document request for a URL with a path prefix of /product/ on the same Origin as the original request, expiring as a dictionary in 7 days independent of the cache lifetime of the resource, and advertise support for both sha-256 and sha-512 hash algorithms. </ins> <del> 2.1.5.2. </del> <ins> 2.1.7.2. </ins> A response that contained a response header:
6.3.1. To make sure that a dictionary can only impact content from the same <del> origin where the dictionary was served, the "match" pattern used for matching a dictionary to requests MUST be for the same origin that the dictionary is served from. </del> <ins> origin where the dictionary was served, the URLPattern used for matching a dictionary to requests is guaranteed to be for the same origin that the dictionary is served from. </ins> 6.3.2.
this will cause parsing to fail, but it is not possible to reliably fail in all such circumstances. <del> The Display String type conveys a Unicode string without any form of sanitization.  Applications using these values need to perform their own checks on their content; for example, they might contain escape sequences, or NUL.  Mitigation strategies include escaping untrusted content before displaying it. </del> <ins> The Display String type can convey any possible Unicode code point without sanitization; for example, they might contain unassigned code points, control points (including NUL), or noncharacters.  Therefore, applications consuming Display Strings need to consider strategies such as filtering or escaping untrusted content before displaying it. See also UNICODE-SECURITY and I-D.draft-bray-unichars. </ins>
Date values can be conveyed in Structured Fields. Dates have a data model that is similar to Integers, representing a <del> (possibly negative) delta in seconds from January 1, 1970 00:00:00 UTC, excluding leap seconds. </del> <ins> (possibly negative) delta in seconds from 1970-01-01T00:00:00Z, excluding leap seconds. </ins> For example: <ins> Parsers MUST support Dates whose values include all days in years 1 to 9999 (i.e., -62,135,596,800 to 253,402,214,400 delta seconds from 1970-01-01T00:00:00Z). </ins> 3.3.8. Display Strings are similar to Strings, in that they consist of zero
accept the upload from the client, and the client begins transferring the entire file in the request content. <del> An informational response can be sent to the client to signal the support of resumable upload on the server and transmit the upload resource URL in the Location header. </del> <ins> An informational response can be sent to the client, which signals the server's support of resumable upload as well as the upload resource URL via the Location header field (HTTP). </ins> <del> 2) If the connection to the server gets interrupted, the client may want to resume the upload.  Before this is possible, the client must know the amount of data that the server was able to receive before the connection got interrupted.  To achieve this, the client retrieves the offset (offset-retrieving) from the upload resource. </del> <ins> 2) If the connection to the server is interrupted, the client might want to resume the upload.  However, before this is possible the client needs to know the amount of data that the server received before the interruption.  It does so by retrieving the offset (offset-retrieving) from the upload resource. </ins> <del> 3) Afterwards, the client can resume the upload by sending the remaining file content to the upload resource (upload-appending), appending to the already stored data in the upload.  The "Upload- Offset" value is included to ensure that the client and server agree on the offset that the upload resumes from. </del> <ins> 3) The client can resume the upload by sending the remaining file content to the upload resource (upload-appending), appending to the already stored data in the upload.  The "Upload-Offset" value is included to ensure that the client and server agree on the offset that the upload resumes from. </ins> <del> 4) If the client is not interested in completing the upload anymore, it can instruct the upload resource to delete the upload and free all </del> <ins> 4) If the client is not interested in completing the upload, it can instruct the upload resource to delete the upload and free all </ins> related resources (upload-cancellation). 3.2.
Client implementations of draft versions of the protocol MUST send a header field "Upload-Draft-Interop-Version" with the interop version <del> as its value to its requests.  Its ABNF is </del> <ins> as its value to its requests.  The "Upload-Draft-Interop-Version" field value is an Integer. </ins> Server implementations of draft versions of the protocol MUST NOT send a "104 (Upload Resumption Supported)" informational response