jiebi/CodeConvo huggingface dataset:
requests with "unsafe" HTTP methods (as was the case prior to the introduction of the "SameSite" attribute). <del> For example, a login flow may involve a cross-site top-level "POST" request to an endpoint which expects a cookie with login information. For such a cookie, "Lax" enforcement is not appropriate, as it would cause the cookie to be excluded due to the unsafe HTTP request method.  On the other hand, "None" enforcement would allow the cookie to be sent with all cross-site requests, which may not be desirable due to the cookie's sensitive contents. </del> <ins> For example, the concluding step of a login flow may involve a cross- site top-level "POST" request to an endpoint; this endpoint expects a recently created cookie containing transactional state information, necessary to securely complete the login.  For such a cookie, "Lax" enforcement is not appropriate, as it would cause the cookie to be excluded due to the unsafe HTTP request method, resulting in an unrecoverable failure of the whole login flow. </ins> The "Lax-allowing-unsafe" enforcement mode described in lax-allowing- unsafe retains some of the protections of "Lax" enforcement (as <del> compared to "None") while still allowing cookies to be sent cross- site with unsafe top-level requests. </del> <ins> compared to "None") while still allowing recently created cookies to be sent cross-site with unsafe top-level requests. </ins> As a more permissive variant of "Lax" mode, "Lax-allowing-unsafe" mode necessarily provides fewer protections against CSRF.
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-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 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". </ins> 4.1.
"Upload-Complete" field value (upload-complete) MUST be set to false. The server SHOULD respect representation metadata received during <del> creation (upload-creation) and ignore any representation metadata received from appending. </del> <ins> creation (upload-creation).  An upload append request continues uploading the same representation as used in the upload creation (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 resumes the transfer of the gzipped data without indicating again that the gzip coding is applied. </ins> If the server does not consider the upload associated with the upload resource active, it MUST respond with a "404 (Not Found)" status
match the offset provided by the immediate previous offset retrieval (offset-retrieving), or the end offset of the immediate previous incomplete successful transfer, the server MUST respond with a "409 <del> (Conflict)" status code. </del> <ins> (Conflict)" status code.  The server MAY use the problem type PROBLEM of "https://iana.org/assignments/http-problem-types#mismatching- upload-offset" in the response; see mismatching-offset. </ins> The server applies the patch document of the "application/partial- upload" media type by appending the request content to the targeted
10. <ins> 10.1. This section defines the "https://iana.org/assignments/http-problem- types#mismatching-upload-offset" problem type PROBLEM.  A server MAY use this problem type when responding to an upload append request (upload-appending) to indicate that the "Upload-Offset" header field in the request does not match the upload resource's offset. Two problem type extension members are defined: the "expected-offset" and "provided-offset" members.  A response using this problem type SHOULD populate both members, with the value of "expected-offset" taken from the upload resource and the value of "provided-offset" taken from the upload append request. The following example shows an example response, where the resource's offset was 100, but the client attempted to append at offset 200: 10.2. This section defines the "https://iana.org/assignments/http-problem- types#completed-upload" problem type PROBLEM.  A server MAY use this problem type when responding to an upload append request (upload- appending) to indicate that the upload has already been completed and cannot be modified. The following example shows an example response: 11. </ins> The "301 (Moved Permanently)" and "302 (Found)" status codes MUST NOT be used in offset retrieval (offset-retrieving) and upload cancellation (upload-cancellation) responses.  For other responses,
apply the redirection directly in an immediate subsequent upload append (upload-appending). <del> 11. </del> <ins> 12. 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. 13. </ins> The server might process the uploaded data and make its results available in another resource during or after the upload.  This
indicated by the "Upload-Offset" field value does not equal the total of begin offset plus the number of bytes uploaded in the request. <ins> If the upload is already complete, the server MUST NOT modify the upload resource and MUST respond with a "400 (Bad Request)" status code.  The server MAY use the problem type PROBLEM of "https://iana.org/assignments/http-problem-types#completed-upload" in the response; see completed-upload. </ins> If the request completes successfully and the entire upload is complete, the server MUST acknowledge it by responding with a 2xx (Successful) status code.  Servers are RECOMMENDED to use a "201
<del> Security Considerations for Optimistic Use of HTTP Upgrade </del> <ins> Security Considerations for Optimistic Protocol Transitions in HTTP/1.1 </ins> draft-ietf-httpbis-optimistic-upgrade-latest Abstract <del> The HTTP/1.1 Upgrade mechanism allows the client to request a change to a new protocol.  This document discusses the security </del> <ins> In HTTP/1.1, the client can request a change to a new protocol on the existing connection.  This document discusses the security </ins> considerations that apply to data sent by the client before this request is confirmed, and updates RFC 9298 to avoid related security issues.
2. <del> In HTTP/1.1, a client is permitted to send an "Upgrade" request header field (RFC9110) to indicate that it would like to use this connection for a protocol other than HTTP/1.1.  The server replies with a "101 (Switching Protocols)" status code if it accepts the protocol change.  However, that specification also permits the server to reject the upgrade request: </del> <ins> In HTTP/1.1, a single connection is often used for many requests, one after another.  After each request, the connection is returned to its initial state, ready to send more HTTP requests.  However, HTTP/1.1 also contains two mechanisms that allow the client to change the protocol used for the remainder of the connection. </ins> <del> This rejection of the upgrade is common, and can happen for a variety of reasons: </del> <ins> One such mechanism is the "Upgrade" request header field (RFC9110), which indicates that the client would like to use this connection for a protocol other than HTTP/1.1.  The server replies with a "101 (Switching Protocols)" status code if it accepts the protocol change. The other mechanism is the HTTP "CONNECT" method.  This method indicates that the client wishes to establish a TCP connection to the specified host and port.  The server replies with a 2xx (Successful) response to indicate that the request was accepted and a TCP connection was established.  After this point, the TCP connection is acting as a TCP tunnel, not an HTTP/1.1 connection. Both of these mechanisms also permit the server to reject the request.  For example, RFC9110 says: and Rejections are common, and can happen for a variety of reasons.  An "upgrade" request might be rejected if: </ins> The server does not support any of the client's indicated Upgrade Tokens (i.e., the client's proposed new protocols), so it
client and server have distinct interpretations of the data that flows between them. <del> If the server accepts an HTTP Upgrade, it interprets the subsequent bytes in accordance with the new protocol.  If it rejects the upgrade, it interprets those bytes as HTTP/1.1.  However, the client doesn't know which interpretation the server will take until it receives the server's response status code.  If it uses the new protocol optimistically, this creates a risk that the server will interpret attacker-controlled data in the upgraded protocol as an </del> <ins> If the server accepts a protocol transition request, it interprets the subsequent bytes in accordance with the new protocol.  If it rejects the request, it interprets those bytes as HTTP/1.1.  However, the client doesn't know which interpretation the server will take until it receives the server's response status code.  If it uses the new protocol optimistically, this creates a risk that the server will interpret attacker-controlled data in the new protocol as an </ins> additional HTTP request issued by the client. <del> As a trivial example, consider an upgraded protocol in which the entire post-upgrade content might be freely attacker-controlled (e.g., "connect-tcp" I-D.ietf-httpbis-connect-tcp).  If the client is authenticated to the server using a connection-level authentication method such as TLS Client Certificates, the attacker could send an HTTP/1.1 POST request in the post-upgrade payload.  If the client delivers this payload optimistically, and the upgrade request fails, the server would interpret the payload as a subsequent authenticated </del> <ins> As a trivial example, consider an HTTP CONNECT client providing connectivity to an untrusted application.  If the client is authenticated to the proxy server using a connection-level authentication method such as TLS Client Certificates, the attacker could send an HTTP/1.1 POST request for the proxy server at the beginning of its TCP connection.  If the client delivers this data optimistically, and the CONNECT request fails, the server would misinterpret the application's data as a subsequent authenticated </ins> request issued by the client. 3.2.
A related category of attacks use protocol disagreement to exploit vulnerabilities in the server's request parsing logic.  These attacks apply when the HTTP client is trusted by the server, but the post- <del> upgrade data source is not.  If the server software was developed </del> <ins> transition data source is not.  If the server software was developed </ins> under the assumption that some or all of the HTTP request data is not <del> attacker-controlled, optimistic use of HTTP Upgrade can cause this </del> <ins> attacker-controlled, optimistic transmission can cause this </ins> assumption to be violated, exposing vulnerabilities in the server's HTTP request parser. 4. <del> If the server rejects the upgrade, the connection can continue to be used for HTTP/1.1.  There is no requirement to close the connection in response to an upgrade rejection, and keeping the connection open has performance advantages if additional HTTP requests to this server are likely.  Thus, it is normally inappropriate to close the connection in response to a rejected upgrade. </del> <ins> If the server rejects the transition request, the connection can continue to be used for HTTP/1.1.  There is no requirement to close the connection in response to a rejected transition, and keeping the connection open has performance advantages if additional HTTP requests to this server are likely.  Thus, it is normally inappropriate to close the connection in response to a rejected transition. </ins> 5.
7. <ins> Clients that send HTTP CONNECT requests on behalf of untrusted TCP clients MUST wait for a 2xx (Successful) response before sending any TCP payload data. To mitigate vulnerabilities from any clients that do not conform to this requirement, proxy servers MAY close the underlying connection when rejecting an HTTP CONNECT request, without processing any further data sent to the proxy server on that connection.  Note that this behavior may impair performance, especially when returning a "407 (Proxy Authentication Required)" response. 8. </ins> This document has no IANA actions.
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 <del> 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. </del> <ins> the value to inform the client about the upload progress. </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
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 <del> progress.  The same restrictions on the "Upload-Offset" header field in informational responses from the upload creation (upload-creation) apply. </del> <ins> progress. </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
11. <ins> The offset of an upload resource is the number of bytes that have been appended to the upload resource.  Appended data cannot be removed from an upload and, therefore, the upload offset MUST NOT decrease.  A server MUST NOT generate responses containing an "Upload-Offset" header field with a value that is smaller than was included in previous responses for the same upload resource.  This includes informational and final responses for upload creation (upload-creation), upload appending (upload-appending), and offset retrieval (offset-retrieving). If a server loses data that has been appended to an upload, it MUST consider the upload resource invalid and reject further use of the upload resource.  The "Upload-Offset" header field in responses serves as an acknowledgement of the append operation and as a guarantee that no retransmission of the data will be necessary. Client can use this guarantee to free resources associated to already uploaded data while the upload is still ongoing. 12. </ins> The "301 (Moved Permanently)" and "302 (Found)" status codes MUST NOT be used in offset retrieval (offset-retrieving) and upload cancellation (upload-cancellation) responses.  For other responses,
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> This document uses the following terminology from STRUCTURED-FIELDS to specify syntax and parsing: Dictionary, String, Inner List, Token, and Byte Sequence. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. </del> <ins> This document uses the following terminology from Section 3 of STRUCTURED-FIELDS to specify syntax and parsing: Dictionary, String, Inner List, Token, and Byte Sequence. </ins> This document uses the line folding strategies described in FOLDING.
2.1.2. The "match-dest" value of the Use-As-Dictionary header is an Inner <del> List of String values that provides a list of request destinations for the dictionary to match (https://fetch.spec.whatwg.org/#concept- request-destination). </del> <ins> List of String values that provides a list of FETCH request destinations for the dictionary to match. </ins> An empty list for "match-dest" MUST match all destinations.
9.2. <del> The CRIME attack shows that it's a bad idea to compress data from mixed (e.g. public and private) sources - the data sources include not only the compressed data but also the dictionaries.  For example, if you compress secret cookies using a public-data-only dictionary, you still leak information about the cookies. </del> <ins> The compression attacks in RFC7457 show that it's a bad idea to compress data from mixed (e.g. public and private) sources - the data sources include not only the compressed data but also the dictionaries.  For example, if you compress secret cookies using a public-data-only dictionary, you still leak information about the cookies. </ins> Not only can the dictionary reveal information about the compressed data, but vice versa, data compressed with the dictionary can reveal
dictionary to turn it into a tracking cookie. To mitigate any additional tracking concerns, clients MUST treat <del> dictionaries in the same way that they treat cookies.  This includes partitioning the storage as cookies are partitioned as well as clearing the dictionaries whenever cookies are cleared. </del> <ins> dictionaries in the same way that they treat cookies RFC6265.  This includes partitioning the storage as cookies are partitioned as well as clearing the dictionaries whenever cookies are cleared. </ins>
security issues discussed here and provide clear guidance on how clients can avoid them. <ins> 6.1. Some Upgrade Tokens, such as "TLS", are defined for use with any ordinary HTTP Method.  The upgraded protocol continues to provide HTTP semantics, and will convey the response to this HTTP request. The other Upgrade Tokens mentioned in existing do not preserve HTTP semantics, so the method is not relevant.  All of these Upgrade Tokens are specified only for use with the "GET" method. Future specifications for Upgrade Tokens should restrict their use to "GET" requests if the HTTP method is otherwise irrelevant and a request body is not required.  This improves consistency with other Upgrade Tokens and reduces the likelihood that a faulty server implementation might process the request body as the new protocol. </ins> 7. Clients that send HTTP CONNECT requests on behalf of untrusted TCP
policy" used by web browsers isolates content retrieved via different ports. <del> There are two audiences for this specification: developers of cookie- generating servers and developers of cookie-consuming user agents. </del> <ins> This specification applies to developers of both cookie-producing servers and cookie-consuming user agents. implementation-advisory helps to clarify the intended target audience for each implementation type. </ins> To maximize interoperability with user agents, servers SHOULD limit themselves to the well-behaved profile defined in sane-profile when
requests.  If the "SameSite" attribute's value is something other than these three known keywords, the attribute's value will be subject to a default enforcement mode that is equivalent to "Lax". <ins> If a user agent uses "Lax-allowing-unsafe" enforcement (See lax- allowing-unsafe) then this default enforcement mode will instead be equivalent to "Lax-allowing-unsafe". </ins> The "SameSite" attribute affects cookie creation as well as delivery. Cookies which assert "SameSite=Lax" or "SameSite=Strict" cannot be
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, <del> such as SSL or TLS, or if host is trusted.  For example, most user agents consider "https" to be a scheme that denotes a </del> <ins> such as SSL or TLS, or if the host is trusted.  For example, most user agents consider "https" to be a scheme that denotes a </ins> secure protocol and "localhost" to be trusted host. If the cookie's http-only-flag is true, then exclude the cookie
be enforced in set-cookie. Servers SHOULD use as few and as small cookies as possible to avoid <del> reaching these implementation limits and to minimize network bandwidth due to the Cookie header field being included in every request. </del> <ins> reaching these implementation limits, minimize network bandwidth due to the Cookie header field being included in every request, and to avoid reaching server header field limits (See server-syntax). </ins> Servers SHOULD gracefully degrade if the user agent fails to return one or more cookies in the Cookie header field because the user agent
Understanding how and when a request is considered same-site is also important in order to properly design a site for SameSite cookies. <del> 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. </del> <ins> For example, if a cross-site top-level request is made to a sensitive page that request will be considered cross-site and "SameSite=Strict" cookies won't be sent; that page's sub-resources requests, however, are same-site and would receive "SameSite=Strict" 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
Integer. The "min-size" key specifies a minimum size for a resumable <del> upload, counted in bytes.  The server will not create an upload </del> <ins> upload, counted in bytes.  The server MAY NOT create an upload </ins> resource if the client indicates that the uploaded data is smaller <del> than the minimum size.  The value is an Integer. </del> <ins> than the minimum size by including the "Content-Length" and "Upload-Complete: ?1" fields, but the server MAY still accept the uploaded data.  The value is an Integer. </ins> The "max-append-size" key specifies a maximum size counted in bytes for the request content in a single upload append request
The "min-append-size" key specifies a minimum size counted in bytes for the request content in a single upload append request <del> (upload-appending).  The server MAY reject requests below this limit and a client SHOULD NOT send smaller upload append requests. The value is an Integer. </del> <ins> (upload-appending) that does not complete the upload by setting the "Upload-Complete: ?1" field.  The server MAY reject non- completing requests below this limit and a client SHOULD NOT send smaller non-completing upload append requests.  A server MUST NOT reject an upload append request due to smaller size if the request includes the "Upload-Complete: ?1" field.  The value is an Integer. </ins> The "expires" key specifies the remaining lifetime of the upload resource in seconds counted from the generation of the response by