jiebi/CodeConvo huggingface dataset:
offset of the incomplete upload by sending a "HEAD" request to the upload resource. <del> The request MUST NOT include the "Upload-Offset" header or the "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. </del> <ins> The request MUST NOT include an "Upload-Offset" or "Upload-Complete" header field.  The server MUST reject requests with either of these fields by responding with a "400 (Bad Request)" status code. </ins> If the server considers the upload resource to be active, it MUST <del> send back a "204 (No Content)" response.  The response MUST include the "Upload-Offset" header set to the current resumption offset for the target resource.  The response MUST include the "Upload-Complete" header which is set to true if and only if the upload is complete. </del> <ins> respond with a "204 (No Content)" status code.  The response MUST include the "Upload-Offset" header field, with the value set to the current resumption offset for the target resource.  The response MUST include the "Upload-Complete" header field; the value is set to true only if the upload is complete. </ins> An upload is considered complete only if the server completely and <del> successfully received a corresponding creation (upload-creation) request or append (upload-appending) request with the "Upload- Complete" header being set to true. </del> <ins> successfully received a corresponding creation request (upload- creation) or append request (upload-appending) with the "Upload- Complete" header value set to true. </ins> The client MUST NOT perform offset retrieval while creation (upload- creation) or append (upload-appending) is in progress.
based on the resumption offset from a single offset retrieving (offset-retrieving) request. <del> The response SHOULD include "Cache-Control: no-store" header to prevent HTTP caching. </del> <ins> In order to prevent HTTP caching, the response SHOULD include a "Cache-Control" header field with the value "no-store". </ins> If the server does not consider the upload resource to be active, it <del> MUST respond with "404 (Not Found)" status code. </del> <ins> MUST respond with a "404 (Not Found)" status code. </ins> The resumption offset can be less than or equal to the number of bytes the client has already sent.  The client MAY reject an offset
5. This specification defines the following authentication parameters. <del> These parameters use structured fields (STRUCTURED-FIELDS) in their definition, even though the Authorization field itself does not use structured fields.  Due to the syntax requirements for authentication parameters, the byte sequences defined below SHALL be enclosed in double-quotes (the base64-encoded data and colon delimeters are enclosed in double-quotes, see example in example). </del> <ins> All of the byte sequences below are encoded using base64url (see BASE64) without quotes and without padding.  In other words, these byte sequence authentication parameters values MUST NOT include any characters other then ASCII letters, digits, dash and underscore. The integer below is encoded without a minus and without leading zeroes.  In other words, the integer authentication parameters value MUST NOT include any characters other than digits, and MUST NOT start with a zero unless the full value is "0". Using the syntax from ABNF: </ins> 5.1.
upload append (upload-appending), and upload cancellation (upload- cancellation). <del> Once the upload resource is available, the target resource MAY send an informational response with a "104 (Upload Resumption Supported)" status code to the client while the request content is being uploaded.  In this informational response, the "Location" header field MUST be set to the upload resource. </del> <ins> Once the upload resource is available and while the request content is being uploaded, the target resource MAY send one or more informational responses with a "104 (Upload Resumption Supported)" status code to the client.  In the first informational response, the "Location" header field MUST be set to the URL pointing to the upload resource.  In subsequent informational responses, the "Location" header field MUST NOT be set.  An informational response MAY contain the "Upload-Offset" header field with the current upload offset as the value to inform the client about the upload progress.  In subsequent informational responses, the upload offset MUST NOT be smaller than in previous informational responses.  In addition, later offset retrievals (offset-retrieving) MUST NOT receive an upload offset that is less than the offset reported in the latest informational response, allowing the client to free associated resources. </ins> The server MUST send the "Upload-Offset" header field in the response if it considers the upload active, either when the response is a
incomplete successful transfer, the server MUST respond with a "409 (Conflict)" status code. <ins> While the request content is being uploaded, the target resource MAY send one or more informational responses with a "104 (Upload Resumption Supported)" status code to the client.  These informational responses MUST NOT contain the "Location" header field. They MAY include the "Upload-Offset" header field with the current upload offset as the value to inform the client about the upload progress.  The same restrictions on the "Upload-Offset" header field in informational responses from the upload creation (upload-creation) apply. </ins> The server MUST send the "Upload-Offset" header field in the response if it considers the upload active, either when the response is a success (e.g. "201 (Created)"), or when the response is a failure
Upon parsing this name, "dot%5C.label" MUST be treated as a single label. <del> Similarly the "\" character in a label MUST be escaped as "\\". Other uses of "\" MUST NOT appear in the label after percent- decoding. </del> <ins> Similarly the "\" character in a label MUST be escaped as "\\" and then percent-encoded.  Other uses of "\" MUST NOT appear in the label after percent-decoding.  For example, if there is a DNS name "backslash\name.example.com", it would first be escaped as "backslash\\name.example.com", and then percent-encoded as follows: </ins> 3.
Implementations ought to note that the full chain of names might not be available in common DNS resolution APIs, such as "getaddrinfo". <del> "getaddrinfo" does have an option for "AI_CANONNAME", but this will only return the last name in the chain (the canonical name), not the alias names. </del> <ins> "getaddrinfo" does have an option for "AI_CANONNAME" (Section 6.1 of RFC3493), but this will only return the last name in the chain (the canonical name), not the alias names. </ins> An implementation MAY include incomplete information in the "next- hop-aliases" parameter to accommodate cases where it is unable to
11. <del> This specification registers the following entry in the Permanent Message Header Field Names registry established by RFC3864: </del> <ins> IANA is asked to register the following entries in the "Hypertext Transfer Protocol (HTTP) Field Name Registry": </ins> <del> Header field name: Upload-Offset, Upload-Complete Applicable protocol: http Status: standard Author/change controller: IETF Specification: This document Related information: n/a This specification registers the following entry in the "HTTP Status </del> <ins> IANA is asked to register the following entry in the "HTTP Status </ins> Codes" registry: <del> Code: 104 (suggested value) Description: Upload Resumption Supported Specification: This document </del>
2.1.6. <del> The "hashes" value of the Use-As-Dictionary header is a inner-list value that provides a list of supported hash algorithms in order of server preference. The dictionaries are identified by the hash of their contents and this value allows for negotiation of the algorithm to use. The "hashes" value is optional and defaults to (sha-256). 2.1.7. 2.1.7.1. </del> <ins> 2.1.6.1. </ins> A response that contained a response header: Would specify matching any document request for a URL with a path <del> prefix of /product/ on the same Origin as the original request, </del> <ins> prefix of /product/ on the same Origin as the original request, and </ins> expiring as a dictionary in 7 days independent of the cache lifetime <del> of the resource, and advertise support for both sha-256 and sha-512 hash algorithms. </del> <ins> of the resource. </ins> <del> 2.1.7.2. </del> <ins> 2.1.6.2. </ins> A response that contained a response header: <del> Would match main.js in any directory under /app/, expiring as a dictionary in one year and support using the sha-256 hash algorithm. </del> <ins> Would match main.js in any directory under /app/ and expiring as a dictionary in one year. </ins> 2.2.
the content, because a change to the dictionary can result in a change to the decompressed content. <ins> The dictionary is validated using a SHA-256 hash of the content to make sure that the client and server are both using the same dictionary.  The strength of the SHA-256 hash algorithm isn't explicitly needed to counter attacks since the dictionary is being served from the same origin as the content.  That said, if a weakness is discovered in SHA-256 and it is determined that the dictionary negotiation should use a different hash algorithm, the "Use-As- Dictionary" response header can be extended to specify a different algorithm and the server would just ignore any "Available-Dictionary" requests that do not use the updated hash. </ins> 6.2. The CRIME attack shows that it's a bad idea to compress data from
To be considered as a match, the dictionary must not yet be expired as a dictionary.  When iterating through dictionaries looking for a match, the expiration time of the dictionary is calculated by taking <del> the last time the dictionary was written and adding the "ttl" seconds </del> <ins> the last time the dictionary was fetched and adding the "ttl" seconds </ins> from the "Use-As-Dictionary" response.  If the current time is beyond the expiration time of the dictionary, it MUST be ignored.
header to the request to indicate to the server that it has a dictionary available to use for compression. <del> The "Available-Dictionary" request header is a lowercase Base16-encoded RFC4648 SHA-256 hash of the contents of a single </del> <ins> The "Available-Dictionary" request header is a Structured Field STRUCTURED-FIELDS sf-binary SHA-256 hash of the contents of a single </ins> available dictionary. <del> Its syntax is defined by the following ABNF: </del> The client MUST only send a single "Available-Dictionary" request header with a single hash value for the best available match that it has available.
equivalent destination, path and search precedence, the most recently fetched dictionary takes precedence. <ins> 2.3. When a HTTP server responds with a resource that is encoded with a dictionary the server MUST send the hash of the dictionary that was used in the "Content-Dictionary" response header. The "Content-Dictionary" response header is a Structured Field STRUCTURED-FIELDS sf-dictionary SHA-256 hash of the contents of the dictionary that was used to encode the response. If the HTTP response contains a "Content-Dictionary" response header with the hash of a dictionary that the client does not have available then the client cannot decode or use the HTTP response. For example: </ins> 3. When a compression dictionary is available for use for a given
The upload resource URL is the identifier used for modifying the upload.  Without further protection of this URL, an attacker may obtain information about an upload, append data to it, or cancel it. To prevent this, the server SHOULD ensure that only authorized clients can access the upload resource.  In addition, the upload resource URL SHOULD be generated in such a way that makes it hard to be guessed by unauthorized clients. <ins> Some servers or intermediaries provide scanning of content uploaded by clients.  Any scanning mechanism that relies on receiving a complete file in a single request message can be defeated by resumable uploads because content can be split across multiple messages.  Servers or intermediaries wishing to perform content scanning SHOULD consider how resumable uploads can circumvent scanning and take appropriate measures.  Possible strategies include waiting for the upload to complete before scanning a full file, or disabling resumable uploads. </ins> 11. IANA is asked to register the following entries in the "Hypertext
2.1.5. <ins> The "id" value of the Use-As-Dictionary header is a sf-string value that specifies a server identifier for the dictionary.  If an "id" value is present then it MUST be sent to the server in a "Dictionary- ID" request header when the dictionary is advertised as being available. The server identifier MUST be treated as an opaque string by the client. The server identifier MUST NOT be relied upon by the server to guarantee the contents of the dictionary.  The dictionary hash MUST be validated before use. The "id" value string length (after any decoding) supports up to 1024 characters. The "id" value is optional. 2.1.6. </ins> The "type" value of the Use-As-Dictionary header is a sf-string value that describes the file format of the supplied dictionary.
2.3. <ins> When a HTTP client makes a request for a resource for which it has an appropriate dictionary and the dictionary was stored with a server- provided "id" in the Use-As-Dictionary response then the client MUST echo the stored "id" in a "Dictionary-ID" request header. The "Dictionary-ID" request header is a Structured Field STRUCTURED- FIELDS sf-string of up to 1024 characters (after any decoding) and MUST be identical to the server-provided "id". For example: 2.4. </ins> When a HTTP server responds with a resource that is encoded with a dictionary the server MUST send the hash of the dictionary that was used in the "Content-Dictionary" response header.
The Use-As-Dictionary response header is a Structured Field STRUCTURED-FIELDS sf-dictionary with values for "match", "match- <del> search", "match-dest", "ttl", "id", and "type". </del> <ins> dest", "ttl", "id", and "type". </ins> 2.1.1. The "match" value of the Use-As-Dictionary header is a sf-string <del> value that provides the "pathname" of a URLPattern (https://urlpattern.spec.whatwg.org/#dom-urlpatterninit-pathname). </del> <ins> value that provides the URLPattern to use for request matching (https://urlpattern.spec.whatwg.org/). </ins> <del> The "match" is a URL path relative to the full request URL of the dictionary.  The request URL for the dictionary itself is used as the "baseURL" for constructing the URLPattern (https://urlpattern.spec.whatwg.org/) that is used for matching the dictionary to relevant requests when running dictionary-url-matching. </del> <ins> The URLPattern used for matching does not support using Regular expressions. </ins> <del> The URLPattern used for request matching does not support regular expressions (https://urlpattern.spec.whatwg.org/#token-type-regexp) in the "match". </del> <ins> The following algorithm will return TRUE for a valid match pattern and FALSE for an invalid pattern that MUST NOT be used: </ins> <del> The "match" value is required and MUST be included in the Use-As- Dictionary sf-dictionary for the dictionary to be considered valid. </del> <ins> Let MATCH be the value of "match" for the given dictionary. </ins> <del> 2.1.2. </del> <ins> Let URL be the URL of the dictionary request. </ins> <del> The "match-search" value of the Use-As-Dictionary header is a sf- string value that provides the "search" of a URLPattern (https://urlpattern.spec.whatwg.org/#dom-urlpatterninit-search). </del> <ins> Let PATTERN be a URLPattern constructed by setting input=MATCH, and baseURL=URL (https://urlpattern.spec.whatwg.org/). </ins> <del> The "match-search" is the match pattern for the searchpart of the request URL and does not support regular expressions. </del> <ins> If PATTERN has regexp groups then return FALSE (https://urlpattern.spec.whatwg.org/#urlpattern-has-regexp- groups). </ins> <del> The "match-search" value is optional and defaults to the asterisk wildcard token "*". </del> <ins> Return True. </ins> <del> 2.1.3. </del> <ins> The "match" value is required and MUST be included in the Use-As- Dictionary sf-dictionary for the dictionary to be considered valid. 2.1.2. </ins> The "match-dest" value of the Use-As-Dictionary header is a sf-string value that provides a request destination
2.2.2. When a dictionary is stored as a result of a "Use-As-Dictionary" <del> directive, it includes "match", "match-search" and "match-dest" strings that are used to match an outgoing request from a client to the available dictionaries. </del> <ins> directive, it includes "match" and "match-dest" strings that are used to match an outgoing request from a client to the available dictionaries. Dictionaries MUST have been served from the same {Origin} as the outgoing request to match. </ins> To see if an outbound request matches a given dictionary, the following algorithm will return TRUE for a successful match and FALSE
If DEST is not an empty string and If DEST and REQUEST_DEST are not the same value, return FALSE <del> Let PATH be the value of "match" for the given dictionary. </del> <ins> Let BASEURL be the URL of the dictionary request. </ins> <del> Let SEARCH be the value of "match-search" for the given dictionary. </del> <ins> Let URL represent the URL of the outbound request being checked. </ins> <del> Let BASEURL be the request URL of the given dictionary. </del> <ins> If the {Origin} of BASEURL and the {Origin} of URL are not the same, return FALSE. </ins> <del> Let PATTERN be a URLPattern constructed by setting pathname=PATH, search=SEARCH, baseURL=BASEURL (https://urlpattern.spec.whatwg.org/). </del> <ins> Let MATCH be the value of "match" for the given dictionary. </ins> <del> LET URL represent the request URL being checked. </del> <ins> Let PATTERN be a URLPattern constructed by setting input=MATCH, and baseURL=BASEURL (https://urlpattern.spec.whatwg.org/). </ins> <del> Return the result of running the URLPattern "match" algorithm (https://urlpattern.spec.whatwg.org/#match) </del> <ins> Return the result of running the "test" method of PATTERN with input=URL (https://urlpattern.spec.whatwg.org/#ref-for-dom- urlpattern-test) </ins> 2.2.3.
specifies and matches a "match-dest" takes precedence over a match that does not use a destination.  1.  Given equivalent destination precedence, the dictionary with the longest "match" takes precedence. <del> 1.  Given equivalent destination and path precedence, the dictionary with the longest "match-search" takes precedence.  1.  Given equivalent destination, path and search precedence, the most recently fetched dictionary takes precedence. </del> <ins> 1.  Given equivalent destination and match length precedence, the most recently fetched dictionary takes precedence. </ins> 2.3.
1.2. <del> Classic HTTP CONNECT proxies are identified by an origin.  The proxy does not have a path of its own.  This prevents any origin from hosting multiple distinct proxy services. Ordinarily, HTTP allows multiple origin hostnames to share a single server IP address and port number (i.e., virtual-hosting), by specifying the applicable hostname in the "Host" or ":authority" header field.  However, classic HTTP CONNECT proxies use these fields to indicate the CONNECT request's destination (RFC9112), leaving no way to determine the proxy's origin from the request.  As a result, classic HTTP CONNECT proxies cannot be deployed using virtual- hosting, nor can they apply the usual defenses against server port misdirection attacks (see RFC9110). </del> <ins> HTTP clients can be configured to use proxies by selecting a proxy hostname, a port, and whether to use a security protocol.  However, CONNECT requests using the proxy do not carry this configuration information.  Instead, they only indicate the hostname and port of the target.  This prevents any HTTP server from hosting multiple distinct proxy services, as the server cannot distinguish them by path (as with distinct resources) or by origin (as in "virtual hosting"). The absence of an explicit origin for the proxy also rules out the usual defenses against server port misdirection attacks (see RFC9110) and creates ambiguity about the use of origin-scoped response header fields (e.g., "Alt-Svc" RFC7838, "Strict-Transport-Security" RFC6797). </ins> Classic HTTP CONNECT proxies can be used to reach a target host that is specified as a domain name or an IP address.  However, because
usual requirements for classic CONNECT proxies in this HTTP version (see RFC9113 and RFC9114). <ins> 3.3. A templated TCP proxy has an unambiguous origin of its own.  Origin- scoped HTTP header fields such as "Alt-Svc" RFC7838 and "Strict- Transport-Security" RFC6797 apply to this origin when they are associated with a templated TCP proxy request or response. </ins> 4. This section discusses some behaviors that are permitted or
3.3. <del> A templated TCP proxy has an unambiguous origin of its own.  Origin- scoped HTTP header fields such as "Alt-Svc" RFC7838 and "Strict- Transport-Security" RFC6797 apply to this origin when they are associated with a templated TCP proxy request or response. </del> <ins> 3.3.1. Ordinary HTTP headers apply only to the single resource identified in the request or response.  An origin-scoped HTTP header is a special response header that is intended to change the client's behavior for subsequent requests to any resource on this origin. Unlike classic HTTP CONNECT proxies, a templated TCP proxy has an unambiguous origin of its own.  Origin-scoped headers apply to this origin when they are associated with a templated TCP proxy response. Here are some origin-scoped headers that could potentially be sent by a templated TCP proxy: "Alt-Svc" "Strict-Transport-Security" "Public-Key-Pins" "Accept-CH" "Set-Cookie" RFC6265, which has configurable scope. "Clear-Site-Data" 3.3.2. Authentication to a templated TCP proxy normally uses ordinary HTTP authentication via the "401 (Unauthorized)" response code, the "WWW- Authenticate" response header field, and the "Authorization" request header field (RFC9110).  A templated TCP proxy does not use the "407 (Proxy Authentication Required)" response code and related header fields (RFC9110) because they do not traverse HTTP gateways (see operational-considerations). Clients SHOULD assume that all proxy resources generated by a single template share a protection space (i.e., a realm) (RFC9110).  For many authentication schemes, this will allow the client to avoid waiting for a "401 (Unauthorized)" response before each new connection through the proxy. </ins> 4.
infrastructure.  However, current gateways might need modifications to support TCP proxy services.  To be compatible, a gateway must: <del> support Extended CONNECT. </del> <ins> support Extended CONNECT (if acting as an HTTP/2 or HTTP/3 server). support HTTP/1.1 Upgrade to "connect-tcp" (if acting as an HTTP/1.1 server) only after forwarding the upgrade request to the origin and observing a success response. </ins> <del> convert HTTP/1.1 Upgrade requests into Extended CONNECT. </del> <ins> forward the "connect-tcp" protocol to the origin. </ins> <del> allow the Extended CONNECT method to pass through to the origin. </del> <ins> convert "connect-tcp" requests between all supported HTTP server and client versions. </ins> <del> forward Proxy-* request headers to the origin. </del> <ins> allow any "Proxy-Status" headers to traverse the gateway. </ins> 8.