jiebi/CodeConvo huggingface dataset:
5. <del> At the time of writing, there are four distinct Upgrade Tokens that are registered, associated with published documents, and not marked obsolete.  This section considers the impact of this document's considerations on each registered Upgrade Token. </del> <ins> This section describes the impact of this document's considerations on some registered Upgrade Tokens that are believed to be in use at the time of writing. </ins> 5.1. <del> RFC9110 is the source of the requirement quoted in background.  It also defines the "HTTP/*.*" family of Upgrade Tokens.  In HTTP/1.1, the only potentially applicable versions of this token are "0.9", "1.0", "1.1", and "2.0". Versions "0.9" and "1.0" are sufficiently syntactically similar to HTTP/1.1 that any such "downward upgrade" would be unlikely to result in the security concerns discussed here.  (An "upgrade" to version 1.1 has no effect at all.) A version number of "2.0" corresponds to HTTP/2.  Every HTTP/2 connection begins with a Client Connection Preface (RFC9113) that was selected to ensure that a compliant HTTP/1.1 server will not process further data on this connection.  This avoids security issues if an "HTTP/2.0" Upgrade Token is used optimistically. 5.2. </del> RFC2817 defines the "TLS/ " family of Upgrade Tokens, and correctly highlights the possibility
header field as a set-cookie-string (defined below). NOTE: The algorithm below is more permissive than the grammar in <del> sane-set-cookie.  For example, the algorithm strips leading and trailing whitespace from the cookie name and value (but maintains internal whitespace), whereas the grammar in sane-set-cookie forbids whitespace in these positions.  In addition, the algorithm below accommodates some characters that are not cookie-octets according to the grammar in sane-set-cookie.  User agents use this algorithm so as </del> <ins> sane-set-cookie.  For example, the algorithm allows cookie-name to be comprised of cookie-octets instead of being a token as specified in sane-set-cookie and the algorithm accommodates some characters that are not cookie-octets according to the grammar in sane-set-cookie. In addition, the algorithm below also strips leading and trailing whitespace from the cookie name and value (but maintains internal whitespace), whereas the grammar in sane-set-cookie forbids whitespace in these positions.  User agents use this algorithm so as </ins> to interoperate with servers that do not follow the recommendations in sane-profile.
by the user (e.g. a force reload). The immutable extension only applies during the freshness lifetime of <del> the response.  Stale responses SHOULD be revalidated as they normally would be in the absence of immutable. </del> <ins> the stored response.  Stale responses SHOULD be revalidated as they normally would be in the absence of immutable. </ins> <del> The immutable extension takes no arguments and if any arguments are present they have no meaning.  Multiple instances of the immutable extension are equivalent to one instance.  The presence of an immutable Cache-Control extension in a request has no effect. </del> <ins> The immutable extension takes no arguments.  If any arguments are present, they have no meaning, and MUST be ignored.  Multiple instances of the immutable extension are equivalent to one instance. The presence of an immutable Cache-Control extension in a request has no effect. </ins> 2.1.
corruption incidents.  These incidents include cache poisoning attacks.  Three mechanisms are suggested for mitigation of this risk: <del> Clients should ignore immutable for resources that are not part of an authenticated context such as HTTPS.  Authenticated resources are less vulnerable to cache poisoning. </del> <ins> Clients SHOULD ignore immutable from resources that are not part of an authenticated context such as HTTPS.  Authenticated resources are less vulnerable to cache poisoning. </ins> <del> User-Agents often provide two different refresh mechanismss: reload and some form of force-reload.  The latter is used to rectify interrupted loads and other corruption.  These reloads, typically indicated through no-cache request attributes, should ignore immutable as well. </del> <ins> User-Agents often provide two different refresh mechanisms: reload and some form of force-reload.  The latter is used to rectify interrupted loads and other corruption.  These reloads, typically indicated through no-cache request attributes, SHOULD ignore immutable as well. </ins> <del> Clients should ignore immutable for resources that do not provide </del> <ins> Clients SHOULD ignore immutable for resources that do not provide </ins> a strong indication that the stored response size is the correct response size such as responses delimited by connection close.
Let URL be the URL of the dictionary request. Let PATTERN be an instance of the URLPattern class constructed by <del> setting input=MATCH, and baseURL=URL (see URLPATTERN-CLASS). </del> <ins> setting input=MATCH, and baseURL=URL (see URLPATTERN). </ins> If the hasRegExpGroups attribute of PATTERN is TRUE then return <del> FALSE (see URLPATTERN-REGEXP). </del> <ins> FALSE (see URLPATTERN). </ins> Return TRUE.
Let MATCH be the value of "match" for the given dictionary. Let PATTERN be an instance of the URLPattern class constructed by <del> setting input=MATCH, and baseURL=BASEURL (see URLPATTERN-CLASS). </del> <ins> setting input=MATCH, and baseURL=BASEURL (see URLPATTERN). </ins> Return the result of running the "test" method of PATTERN with input=URL which will check for a match between the request URL and <del> the supplied "match" URL Pattern (see URLPATTERN-TEST). </del> <ins> the supplied "match" URL Pattern (see URLPATTERN). </ins> 2.2.3.
13. <del> A message might have a content coding, indicated by the "Content- Encoding" header field, and/or a transfer coding, indicated by the "Transfer-Encoding" header field (RFC9112), applied, which modify the representation of uploaded data in a message.  For correct interoperability, the client and server must share the same logic when counting bytes for the upload offset.  From the client's perspective, the offset is counted after content coding but before transfer coding is applied.  From the server's perspective, the offset is counted after the content's transfer coding is reversed but before the content coding is reversed. </del> <ins> Since the codings listed in "Content-Encoding" are a characteristic of the representation (see HTTP), both the client and the server always compute the upload offset on the content coded data (that is, the representation data).  Moreover, the content codings are retained throughout the entire upload, meaning thats that the server is not required to decode the representation data to support resumable uploads.  See DIGEST-FIELDS for more information. </ins> 14. <ins> Unlike "Content-Encoding" (see HTTP), "Transfer-Encoding" (see RFC9112) is a property of the message, not of the representation. Moreover. transfer codings can be applied in transit (e.g., by proxies).  This means that a client does not have to consider the transfer codings to compute the upload offset, while a server is responsible for transfer decoding the message before computing the upload offset.  Please note that the "Content-Length" header field cannot be used in conjunction with the "Transfer-Encoding" header field. 15. </ins> The integrity of an entire upload or individual upload requests can be verifying using digests from DIGEST-FIELDS.
cases, as the URI is more likely to be logged than the request content.  If a server creates a temporary resource to represent the results of a QUERY request (e.g., for use in the Location or Content- <del> Location field), the URI of this resource SHOULD NOT expose the original request content in plaintext. </del> <ins> Location field) and the request contains sensitive information that cannot be logged, then the URI of this resource SHOULD be chosen such that it does not include any sensitive portions of the original request content. </ins> 6.
Clients can send representation metadata (see HTTP) in the request that starts an upload.  Servers MAY interpret this metadata or MAY ignore it.  The "Content-Type" header field (HTTP) can be used to <del> indicate the media type of the file.  The content coding of the representation is specified using the "Content-Encoding" header field and is retained throughout the entire upload.  When resuming an interrupted upload, the same content coding is used for appending to the upload, producing a representation of the upload resource with one consistent content coding.  The "Content-Disposition" header field (RFC6266) can be used to transmit a filename; if included, the parameters SHOULD be either "filename", "filename*" or "boundary". </del> <ins> indicate the media type of the file.  The applied content codings are specified using the "Content-Encoding" header field and are retained throughout the entire upload.  When resuming an interrupted upload, the same content codings are used for appending to the upload, producing a representation of the upload resource.  The "Content- Disposition" header field (RFC6266) can be used to transmit a filename; if included, the parameters SHOULD be either "filename", "filename*" or "boundary". </ins> 4.1.
The server SHOULD respect representation metadata received during creation (upload-creation).  An upload append request continues uploading the same representation as used in the upload creation <del> (upload-creation) and thus uses the same content coding, if one was applied.  For example, if the initial upload creation included the "Content-Encoding: gzip" header field, the upload append request </del> <ins> (upload-creation) and thus uses the same content codings, if they were applied.  For example, if the initial upload creation included the "Content-Encoding: gzip" header field, the upload append request </ins> resumes the transfer of the gzipped data without indicating again that the gzip coding is applied.
MUST NOT fail the parsing to facilitate the addition of new limits in the future. <ins> A server that supports the creation of a resumable upload resource (upload-creation) under a target URI MUST include the "Upload-Limit" header field with the corresponding limits in a response to an "OPTIONS" request sent to this target URI.  If a server supports the creation of upload resources for any target URI, it MUST include the "Upload-Limit" header field with the corresponding limits in a response to an "OPTIONS" request with the "*" target.  The limits announced in an "OPTIONS" response SHOULD NOT be less restrictive than the limits applied to an upload once the upload resource has been created.  If the server does not apply any limits, it MUST use "min-size=0" instead of an empty header value.  A client can use an "OPTIONS" request to discover support for resumable uploads and potential limits before creating an upload resource. </ins> 8.3. The "Upload-Complete" request and response header field indicates
13. <del> A message might have a content coding, indicated by the "Content- Encoding" header field, and/or a transfer coding, indicated by the "Transfer-Encoding" header field (RFC9112), applied, which modify the representation of uploaded data in a message.  For correct interoperability, the client and server must share the same logic when counting bytes for the upload offset.  From the client's perspective, the offset is counted after content coding but before transfer coding is applied.  From the server's perspective, the offset is counted after the content's transfer coding is reversed but before the content coding is reversed. </del> <ins> Since the codings listed in "Content-Encoding" are a characteristic of the representation (see HTTP), both the client and the server always compute the upload offset on the content coded data (that is, the representation data).  Moreover, the content codings are retained throughout the entire upload, meaning that the server is not required to decode the representation data to support resumable uploads.  See DIGEST-FIELDS for more information. </ins> 14. <ins> Unlike "Content-Encoding" (see HTTP), "Transfer-Encoding" (see RFC9112) is a property of the message, not of the representation. Moreover, transfer codings can be applied in transit (e.g., by proxies).  This means that a client does not have to consider the transfer codings to compute the upload offset, while a server is responsible for transfer decoding the message before computing the upload offset.  Please note that the "Content-Length" header field cannot be used in conjunction with the "Transfer-Encoding" header field. 15. </ins> The integrity of an entire upload or individual upload requests can be verifying using digests from DIGEST-FIELDS.
with the "201 (Created)" status code and an "Upload-Complete" header value set to false. <del> If the request includes an "Upload-Complete" field value set to true 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 "Content-Length" field value and the server MUST record it to ensure its consistency. </del> <ins> The request can indicate the upload's final size in two different ways.  Both indicators may be present in the same request as long as they convey the same size.  If the sizes are inconsistent, the server MUST reject the request by responding with a "400 (Bad Request)" status code. If the request includes an "Upload-Complete" field value set to true 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 "Content-Length" field value and the server MUST record it to ensure its consistency. The value can therefore not be used if the upload is split across multiple requests. If the request includes the "Upload-Length" header field, the server MUST record its value as the upload's final size.  A client SHOULD provide this header field if the upload length is known at the time of upload creation. The upload is not automatically completed if the offset reaches the upload's final size.  Instead, a client MUST indicate the completion of an upload through the "Upload-Complete" header field.  Indicating an upload's final size can help the server allocate necessary resources for the upload and provide early feedback if the size does not match the server's limits (upload-limit). </ins> The server MAY enforce a maximum size of an upload resource.  This <del> limit MAY be equal to the upload's final size, if "Upload-Complete: ?1" and "Content-Length" are present in the upload creation request, or an arbitrary value.  The limit's value or its existence MUST NOT change throughout the lifetime of the upload resource.  The server MAY indicate such a limit to the client by including the "Upload- Limit" header field in the informational or final response to upload </del> <ins> limit MAY be equal to the upload's final size, if available, or an arbitrary value.  The limit's value or its existence MUST NOT change throughout the lifetime of the upload resource.  The server MAY indicate such a limit to the client by including the "Upload-Limit" header field in the informational or final response to upload </ins> creation.  If the client receives an "Upload-Limit" header field indicating that the maximum size is less than the amount of bytes it intends to upload to a resource, it SHOULD stop the current upload
considered complete. The next example shows an upload creation, where only the first 25 <del> bytes are transferred.  The server acknowledges the received data and that the upload is not complete yet: </del> <ins> bytes of a 100 bytes upload are transferred.  The server acknowledges the received data and that the upload is not complete yet: </ins> If the client received an informational response with the upload URL in the Location field value, it MAY automatically attempt upload
offset of the incomplete upload by sending a "HEAD" request to the upload resource. <del> 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. </del> <ins> The request MUST NOT include an "Upload-Offset", "Upload-Complete", or "Upload-Length" 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 respond with a "204 (No Content)" or "200 (OK)" status code.  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.  The response <del> MAY include the "Upload-Limit" header field if corresponding limits on the upload resource exist. </del> <ins> MUST include the "Upload-Length" header field set to the upload's final size if one was recorded during the upload creation (upload- creation).  The response MAY include the "Upload-Limit" header field if corresponding limits on the upload resource exist. </ins> An upload is considered complete only if the server completely and successfully received a corresponding creation request (upload-
upload's final size.  If they do not match, the server MUST reject the request with a "400 (Bad Request)" status code. <ins> The server MUST prevent that the offset exceeds the upload's final size when appending.  If a final size has been recorded and the upload append request exceeds this value, the server MUST stop appending bytes to the upload once the offset reaches the final size and reject the request with a "400 (Bad Request)" status code.  It is not sufficient to rely on the "Content-Length" header field for enforcement because the header field might not be present. </ins> The request content MAY be empty.  If the "Upload-Complete" field is then set to true, the client wants to complete the upload without appending additional data.
Since the codings listed in "Content-Encoding" are a characteristic of the representation (see HTTP), both the client and the server <del> always compute the upload offset on the content coded data (that is, the representation data).  Moreover, the content codings are retained throughout the entire upload, meaning that the server is not required to decode the representation data to support resumable uploads.  See DIGEST-FIELDS for more information. </del> <ins> always compute the values for "Upload-Offset" and optionally "Upload- Length" on the content coded data (that is, the representation data). Moreover, the content codings are retained throughout the entire upload, meaning that the server is not required to decode the representation data to support resumable uploads.  See DIGEST-FIELDS for more information. </ins> 14.
proxies).  This means that a client does not have to consider the transfer codings to compute the upload offset, while a server is responsible for transfer decoding the message before computing the <del> upload offset.  Please note that the "Content-Length" header field cannot be used in conjunction with the "Transfer-Encoding" header field. </del> <ins> upload offset.  The same applies to the value of "Upload-Length". Please note that the "Content-Length" header field cannot be used in conjunction with the "Transfer-Encoding" header field. </ins> 15. The integrity of an entire upload or individual upload requests can be verifying using digests from DIGEST-FIELDS. <ins> 15.1. Representation digests help verify the integrity of the entire data that has been uploaded so far, which might strech across multiple requests. </ins> If the client knows the integrity digest of the entire data before creating an upload resource, it MAY include the "Repr-Digest" header field when creating an upload (upload-creation).  Once the upload is
failed and not process the uploaded data further.  This way, the integrity of the entire uploaded data can be protected. <ins> Alternatively, when creating an upload (upload-creation), the client MAY ask the server to compute and return the integrity digests using a "Want-Repr-Digest" field conveying the preferred algorithms.  The response SHOULD include at least one of the requested digests, but MAY not include it.  The server SHOULD compute the representation digests using the preferred algorithms once the upload is complete and include the corresponding "Repr-Digest" header field in the response.  Alternatively, the server MAY compute the digest continuously during the upload and include the "Repr-Digest" header field in responses to upload creation (upload-creation) and upload appending requests (upload-appending) even when the upload is not completed yet.  This allows the client to simultaneously compute the digest of the transmitted upload data, compare its digest to the server's digest, and spot data integrity issues.  If an upload is spread across multiple requests, data integrity issues can be found even before the upload is fully completed. 15.2. Content digests help verify the integrity of the content in an individual request. </ins> If the client knows the integrity digest of the content from an upload creation (upload-creation) or upload appending (upload- appending) request, it MAY include the "Content-Digest" header field
interruptions.  The client can offer the server to upgrade such a request to a resumable upload (see feature-detection) by adding the "Upload-Complete: ?1" header field to the original request.  The <del> request is not changed otherwise. </del> <ins> "Upload-Length" header field SHOULD be added if the upload's final size is known upfront.  The request is not changed otherwise. </ins> A server that supports resumable uploads at the target URI can create a resumable upload resource and send its upload URL in a "104 (Upload
3.3.3. <del> In this specification, use of the Capsule Protocol RFC9297 is OPTIONAL.  Clients MAY request use of the Capsule Protocol by including a "Capsule-Protocol: ?1" header field in the request. Server support for the Capsule Protocol is also OPTIONAL.  If the request includes "Capsule-Protocol: ?1", and the server does not support the Capsule Protocol, the server MUST respond with a 4xx (Client Error) status and a "Capsule-Protocol: ?0" response header field, and MUST discard any data received on this request stream. Upon receiving such a response, the client MUST retry the request without the Capsule Protocol and MAY disable use of the Capsule Protocol with this URI Template for the remainder of the session. </del> <ins> In this specification, support for the Capsule Protocol RFC9297 is OPTIONAL for clients.  Clients MAY request use of the Capsule Protocol by including a "Capsule-Protocol: ?1" header field in the request. Server support for the Capsule Protocol is REQUIRED.  Servers MUST confirm use of the Capsule Protocol by echoing the "Capsule-Protocol: ?1" header in their response. </ins> When using the Capsule Protocol, TCP payload data is sent in the payload of a new Capsule Type named DATA (data-capsule).  The ordered