jiebi/CodeConvo huggingface dataset:
however, prudent to ensure that this designation is not the extent of a site's defense against CSRF, as same-site navigations and submissions can certainly be executed in conjunction with other <del> attack vectors such as cross-site scripting. </del> <ins> attack vectors such as cross-site scripting or abuse of page redirections. Understanding how and when a request is considered same-site is also important in order to properly design a site for SameSite cookies. For example, if a top-level request is made to a sensitive page that request will be considered cross-site and SameSite cookies won't be sent; that page's sub-resources requests, however, are same-site and would receive SameSite cookies.  Sites can avoid inadvertently allowing access to these sub-resources by returning an error for the initial page request if it doesn't include the appropriate cookies. </ins> Developers are strongly encouraged to deploy the usual server-side defenses (CSRF tokens, ensuring that "safe" HTTP methods are
malicious) request.  Thus, the reload request should be considered cross-site, like the request that initially navigated to the page. <ins> Because requests issued for, non-user initiated, reloads attach all SameSite cookies, developers should be careful and thoughtful about when to initiate a reload in order to avoid a CSRF attack.  For example, the page could only initiate a reload if a CSRF token is present on the initial request. </ins> 8.8.6. The "Lax" enforcement mode described in strict-lax allows a cookie to
The retrieval's URI's path path-matches the cookie's path. If the cookie's secure-only-flag is true, then the retrieval's <del> URI's scheme must denote a "secure" protocol (as defined by the user agent). NOTE: The notion of a "secure" protocol is not defined by this document.  Typically, user agents consider a protocol secure if the protocol makes use of transport-layer security, such as SSL or TLS.  For example, most user agents consider "https" to be a scheme that denotes a secure protocol. </del> <ins> URI must denote a "secure" connection (as defined by the user agent). NOTE: The notion of a "secure" connection is not defined by this document.  Typically, user agents consider a connection secure if the connection makes use of transport-layer security, such as SSL or TLS, or if host is trusted.  For example, most user agents consider "https" to be a scheme that denotes a secure protocol and "localhost" to be trusted host. </ins> If the cookie's http-only-flag is true, then exclude the cookie if the retrieval's type is "non-HTTP".
upload resource in parallel.  This helps avoid race conditions, and data loss or corruption.  The server is RECOMMENDED to take measures to avoid parallel upload transfers: The server MAY terminate any <del> creation (upload-creation) or append (upload-appending) for the same upload URL.  Since the client is not allowed to perform multiple transfers in parallel, the server can assume that the previous attempt has already failed.  Therefore, the server MAY abruptly terminate the previous HTTP connection or stream. </del> <ins> creation (upload-creation) or append for the same upload URL.  Since the client is not allowed to perform multiple transfers in parallel, the server can assume that the previous attempt has already failed. Therefore, the server MAY abruptly terminate the previous HTTP connection or stream. </ins> If the offset indicated by the "Upload-Offset" field value does not match the offset provided by the immediate previous offset retrieval
(see output}), and forward it to the upstream HTTP server, then the upstream server performs the validation. <del> The mechanism for the intermediary to communicate this information to the upstream HTTP server is out of scope for this document. </del> <ins> This document defines the "Signature-Auth-Context" request header field for this latter purpose.  The Signature-Auth-Context header field's value is a Structured Field Byte Sequence (see STRUCTURED- FIELDS) that contains the 48-byte key exporter output (see output), without any parameters.  For example: </ins> Note that both of these mechanisms require the upstream HTTP server to trust the intermediary.  This is usually the case because the intermediary already needs access to the TLS certificate private key <del> in order to respond to requests. </del> <ins> in order to respond to requests.  HTTP servers that parse the Signature-Auth-Context header field MUST ignore it unless they have already established that they trust the sender. </ins> 9.
This document, if approved, requests IANA to register the following entry in the "TLS Exporter Labels" registry maintained at <<https://www.iana.org/assignments/tls-parameters#exporter-labels>>: <ins> 10.3. This document, if approved, requests IANA to register the following entry in the "Hypertext Transfer Protocol (HTTP) Field Name" registry maintained at <<https://www.iana.org/assignments/http-fields/http- fields.xhtml>>: </ins>
request, the algorithm to be used is negotiated through the regular mechanism for negotiating content encoding in HTTP. <del> This document introduces two new content encoding algorithms: </del> The dictionary to use is negotiated separately and advertised in the "Available-Dictionary" request header. 3.1. <ins> This document introduces two new content encoding algorithms: br-d: Brotli RFC7932 using an external compression dictionary and a compression window of not more than 16 MB. zstd-d: Zstandard RFC8878 using an external compression dictionary and a compression window of not more than 8 MB. 3.2. </ins> The client adds the algorithms that it supports to the "Accept- Encoding" request header. e.g.: <del> 3.2. </del> <ins> 3.3. </ins> If a server supports one of the dictionary algorithms advertised by the client and chooses to compress the content of the response using
4.1. <del> IANA is asked to update the "HTTP Content Coding Registry" registry (HTTP) according to the table below: </del> <ins> IANA is asked to enter the following into the "HTTP Content Coding Registry" registry (HTTP): Name: br-d Description: A stream of bytes compressed using the Brotli protocol with an external dictionary of not more than 16 MB. Reference: This document Notes: IANA is asked to enter the following into the "HTTP Content Coding Registry" registry (HTTP): Name: zstd-d Description: A stream of bytes compressed using the Zstandard protocol with an external dictionary of not more than 8 MB. Reference: This document Notes: </ins> 4.2.
2.1.1. The "match" value of the Use-As-Dictionary header is a String value <del> that provides the URLPattern to use for request matching (https://urlpattern.spec.whatwg.org/). </del> <ins> that provides the URL Pattern URLPattern to use for request matching. </ins> <del> The URLPattern used for matching does not support using Regular </del> <ins> The URL Pattern used for matching does not support using Regular </ins> expressions. The following algorithm will return TRUE for a valid match pattern
Let URL be the URL of the dictionary request. <del> Let PATTERN be a URLPattern constructed by setting input=MATCH, and baseURL=URL (https://urlpattern.spec.whatwg.org/). </del> <ins> Let PATTERN be a URL Pattern URLPattern constructed by setting input=MATCH, and baseURL=URL. </ins> <del> If PATTERN has regexp groups then return FALSE (https://urlpattern.spec.whatwg.org/#urlpattern-has-regexp- groups). </del> <ins> If PATTERN has regexp groups then return FALSE. </ins> Return True.
Let MATCH be the value of "match" for the given dictionary. <del> Let PATTERN be a URLPattern constructed by setting input=MATCH, and baseURL=BASEURL (https://urlpattern.spec.whatwg.org/). </del> <ins> Let PATTERN be a URL Pattern URLPattern constructed by setting input=MATCH, and baseURL=BASEURL. </ins> Return the result of running the "test" method of PATTERN with <del> input=URL (https://urlpattern.spec.whatwg.org/#ref-for-dom- urlpattern-test) </del> <ins> input=URL. </ins> 2.2.3.
6.3.1. To make sure that a dictionary can only impact content from the same <del> 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. </del> <ins> origin where the dictionary was served, the URL Pattern used for matching a dictionary to requests (match) is guaranteed to be for the same origin that the dictionary is served from. </ins> 6.3.2.
3.2. <del> In HTTP/2 and HTTP/3, the client uses the proxy by issuing an "extended CONNECT" request as follows: </del> <ins> In HTTP/2 and HTTP/3, the proxy MUST include SETTINGS_ENABLE_CONNECT_PROTOCOL in its SETTINGS frame RFC9220.  The client uses the proxy by issuing an "extended CONNECT" request as follows: </ins> The :method pseudo-header field SHALL be "CONNECT".
When there are multiple dictionaries that match a given request URL, the client MUST pick a single dictionary using the following rules: <del> 1.  For clients that support request destinations, a dictionary that 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. 1.  Given equivalent destination and match length precedence, the most recently fetched dictionary takes precedence. </del> <ins> For clients that support request destinations, a dictionary that specifies and matches a "match-dest" takes precedence over a match that does not use a destination. Given equivalent destination precedence, the dictionary with the longest "match" takes precedence. Given equivalent destination and match length precedence, the most recently fetched dictionary takes precedence. </ins> 2.3.
that don't support them or serving the response compressed with the wrong dictionary: <del> 4. </del> <ins> 6. </ins> <del> 4.1. </del> <ins> 6.1. </ins> IANA is asked to enter the following into the "HTTP Content Coding Registry" registry (HTTP): Name: br-d <del> Description: A stream of bytes compressed using the Brotli protocol with an external dictionary of not more than 16 MB. </del> <ins> Description: "Dictionary-Compressed Brotli" data format. </ins> Reference: This document
Name: zstd-d <del> Description: A stream of bytes compressed using the Zstandard protocol with an external dictionary of not more than 8 MB. </del> <ins> Description: "Dictionary-Compressed Zstandard" data format. </ins> Reference: This document Notes: <del> 4.2. </del> <ins> 6.2. </ins> IANA is asked to update the "Hypertext Transfer Protocol (HTTP) Field Name Registry" registry (HTTP) according to the table below: <del> 5. </del> <ins> 7. </ins> To minimize the risk of middle-boxes incorrectly processing dictionary-compressed responses, compression dictionary transport MUST only be used in secure contexts (HTTPS). <del> 6. </del> <ins> 8. </ins> The security considerations for Brotli RFC7932 and Zstandard RFC8878 apply to the dictionary-based versions of the respective algorithms. <del> 6.1. </del> <ins> 8.1. </ins> The dictionary must be treated with the same security precautions as the content, because a change to the dictionary can result in a
the adversary can control the dictionary, the adversary can learn information about the compressed data. <del> 6.3. </del> <ins> 8.3. </ins> If any of the mitigations do not pass, the client MUST drop the response and return an error. <del> 6.3.1. </del> <ins> 8.3.1. </ins> To make sure that a dictionary can only impact content from the same origin where the dictionary was served, the URL Pattern used for matching a dictionary to requests (match) is guaranteed to be for the same origin that the dictionary is served from. <del> 6.3.2. </del> <ins> 8.3.2. </ins> For clients, like web browsers, that provide additional protection against the readability of the payload of a response and against user
For example: <del> 2.4. 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 Byte Sequence containing the 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: </del> 3. This specification defines the 'compression-dictionary' link relation
4. <del> The "br-d" content encoding identifies a resource that is a </del> <ins> The "dcb" content encoding identifies a resource that is a </ins> "Dictionary-Compressed Brotli" stream. <del> A "Dictionary-Compressed Brotli" stream is a Brotli RFC7932 stream for a response that has been compressed with an external dictionary using a compression window not larger than 16 MB. </del> <ins> A "Dictionary-Compressed Brotli" stream has a fixed header that is followed by a Shared Brotli SHARED-BROTLI stream.  The header consists of a fixed 4 byte sequence and a 32 byte hash of the external dictionary that was used.  The Shared Brotli stream is created using the referenced external dictionary and a compression window that is at most 16 MB in size. The 36-byte fixed header is as follows: </ins> <del> Clients that announce support for br-d content encoding MUST be able </del> <ins> Clients that announce support for dcb content encoding MUST be able </ins> to decompress resources that were compressed with a window size of up to 16 MB.
5. <del> The "zstd-d" content encoding identifies a resource that is a </del> <ins> The "dcz" content encoding identifies a resource that is a </ins> "Dictionary-Compressed Zstandard" stream. <del> A "Dictionary-Compressed Zstandard" stream is a Zstandard RFC8878 stream for a response that has been compressed with an external dictionary. </del> <ins> A "Dictionary-Compressed Zstandard" stream is a binary stream that starts with a 40-byte fixed header and is followed by a Zstandard RFC8878 stream of the response that has been compressed with an external dictionary. The 40-byte header consists of a fixed 8-byte sequence followed by the 32-byte SHA-256 hash of the external dictionary that was used to compress the resource: The 40-byte header is a Zstandard skippable frame (little-endian 0x184D2A5E) with a 32-byte length (little-endian 0x00000020) that is compatible with existing Zstandard decoders. </ins> <del> Clients that announce support for zstd-d content encoding MUST be able to decompress resources that were compressed with a window size of at least 8 MB or 1.25 times the size of the dictionary, which ever is greater, up to a maximum of 128 MB. </del> <ins> Clients that announce support for dcz content encoding MUST be able to decompress resources that were compressed with a window size of at least 8 MB or 1.25 times the size of the dictionary, which ever is greater, up to a maximum of 128 MB. </ins> The window size used will be encoded in the content (currently, this can be expressed in powers of two only) and it MUST be lower than
6.1. <del> The client adds the content encodings that it supports to the "Accept-Encoding" request header. e.g.: </del> <ins> When a dictionary is available for use on a given request, and the client chooses to make dictionary-based content-encoding available, the client adds the dictionary-aware content encodings that it supports to the "Accept-Encoding" request header. e.g.: When a client does not have a stored dictionary that matches the request, or chooses not to use one for the request, the client MUST NOT send its dictionary-aware content-encodings in the "Accept- Encoding" request header. </ins> 6.2.
USASCII character), and WSP (whitespace). The OWS (optional whitespace) and BWS (bad whitespace) rules are <del> defined in Section 5.6.3 of HTTPSEM. </del> <ins> defined in Section 5.6.3 of RFC9110. </ins> 2.3. The terms "user agent", "client", "server", "proxy", and "origin server" have the same meaning as in the HTTP/1.1 specification <del> (HTTPSEM, Section 3). </del> <ins> (RFC9110, Section 3). </ins> The request-host is the name of the host, as known by the user agent, to which the user agent is sending an HTTP request or from which it
Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field.  The usual mechanism for folding HTTP headers <del> fields (i.e., as defined in Section 5.3 of HTTPSEM) might change the </del> <ins> fields (i.e., as defined in Section 5.3 of RFC9110) might change the </ins> semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such folding.
risk of CSRF attacks, developers may set the "SameSite" attribute in a "Lax" enforcement mode that carves out an exception which sends same-site cookies along with cross-site requests if and only if they <del> are top-level navigations which use a "safe" (in the HTTPSEM sense) </del> <ins> are top-level navigations which use a "safe" (in the RFC9110 sense) </ins> HTTP method.  (Note that a request's method may be changed from POST to GET for some redirects (see Sections 15.4.2 and 15.4.3 of <del> HTTPSEM); in these cases, a request's "safe"ness is determined based </del> <ins> RFC9110); in these cases, a request's "safe"ness is determined based </ins> on the method of the current redirect hop.) Lax enforcement provides reasonable defense in depth against CSRF
ua-requirements), the user agent will send a Cookie header field that conforms to the following grammar: <ins> While Section 5.4 of RFC9110 does not define a length limit for header fields it is likely that the web server's implementation does impose a limit; many popular implementations have default limits of 8K.  Servers SHOULD avoid setting a large number of large cookies such that the final cookie-string would exceed their header field limit.  Not doing so could result in requests to the server failing. </ins> Servers MUST be tolerant of multiple cookie headers.  For example, an <del> HTTP/2 RFC9113 or HTTP/3 RFC9114 connection might split a cookie header to improve compression. </del> <ins> HTTP/2 RFC9113 or HTTP/3 RFC9114 client or intermediary might split a cookie header to improve compression.  Servers are free to determine what form this tolerance takes.  For example, the server could process each cookie header individually or the server could concatenate all the cookie headers into one and then process that final, single, header.  The server should be mindful of any header field limits when deciding which approach to take. Note: Since intermediaries can modify cookie headers they should also be mindful of common server header field limits in order to avoid sending servers headers that they cannot process.  For example, concatenating multiple cookie headers into a single header might exceed a server's size limit. </ins> 4.2.2.
HTTP request as defined in same-site-requests, and the retrieval's type is "HTTP". <ins> Note: Previous versions of this specification required that only one Cookie header field be sent in requests.  This is no longer a requirement.  While this specification requires that a single cookie- string be produced, some user agents may split that string across multiple cookie header fields.  For examples, see Section 8.2.3 of RFC9113 and Section 4.2.1 of RFC9114. </ins> 5.8.2. The user agent MAY implement "non-HTTP" APIs that can be used to
encoding from QUIC and MUST be encoded in the minimum number of bytes necessary. <del> The encoding of the public key is determined by the Signature </del> <ins> 3.1.1. Both the "Public Key" field of the TLS key exporter context (see above) and the "a" Parameter (see parameter-a) carry the same public key.  The encoding of the public key is determined by the Signature </ins> Algorithm in use as follows: This document does not define the public key encodings for other
4.2. The REQUIRED "a" (public key) parameter is a byte sequence that <del> contains the public key used by the server to validate the signature </del> <ins> specifies the public key used by the server to validate the signature </ins> provided by the client.  This avoids key confusion issues (see SEEMS- <del> LEGIT).  The encoding of the public key is described in context. </del> <ins> LEGIT).  The encoding of the public key is described in public-key- encoding. </ins> 4.3.
4.1. <del> The REQUIRED "k" (key ID) parameter is a byte sequence that </del> <ins> The REQUIRED "k" (key ID) Parameter is a byte sequence that </ins> identifies which key the client wishes to use to authenticate.  This can, for example, be used to point to an entry in a server-side database of known keys. 4.2. <del> The REQUIRED "a" (public key) parameter is a byte sequence that </del> <ins> The REQUIRED "a" (public key) Parameter is a byte sequence that </ins> specifies 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 public-key-
4.3. <del> The REQUIRED "p" (proof) parameter is a byte sequence that specifies </del> <ins> The REQUIRED "p" (proof) Parameter is a byte sequence that specifies </ins> the proof that the client provides to attest to possessing the credential that matches its key ID. 4.4. <del> The REQUIRED "s" (signature) parameter is an integer that specifies </del> <ins> The REQUIRED "s" (signature) Parameter is an integer that specifies </ins> the signature scheme used to compute the proof transmitted in the "p" <del> directive.  Its value is an integer between 0 and 65535 inclusive </del> <ins> Parameter.  Its value is an integer between 0 and 65535 inclusive </ins> from the IANA "TLS SignatureScheme" registry maintained at <<https://www.iana.org/assignments/tls-parameters/tls- parameters.xhtml#tls-signaturescheme>>. 4.5. <del> The REQUIRED "v" (verification) parameter is a byte sequence that </del> <ins> The REQUIRED "v" (verification) Parameter is a byte sequence that </ins> specifies the verification that the client provides to attest to possessing the key exporter output (see output for details).  This avoids issues with signature schemes where certain keys can generate
the presence of authentication to observers due to clear-text TLS Client Hello extensions. <ins> Since the freshness described above is provided by a TLS key exporter, it can be as old as the underlying TLS connection.  Servers can require better freshness by forcing clients to create new connections using mechanisms such as the GOAWAY frame (see H3). </ins> The authentication proofs described in this document are not bound to individual HTTP requests; if the key is used for authentication proofs on multiple requests on the same connection, they will all be