jiebi/CodeConvo huggingface dataset:
waiting for a "401 (Unauthorized)" response before each new connection through the proxy. <del> 3.3.3. </del> <ins> 3.4. </ins> <del> 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. </del> <ins> When using the "connect-tcp" Upgrade Token, templated TCP proxies do not use the Capsule Protocol RFC9297.  Clients MAY request use of the Capsule Protocol by offering the Upgrade Token "connect-tcp-capsule" instead.  When offering or accepting the "connect-tcp-capsule" Upgrade Token, clients and servers SHOULD including a "Capsule- Protocol: ?1" header to facilitate processing by intermediaries. </ins> <del> 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. </del> <ins> Clients of this specification MAY implement "connect-tcp", "connect- tcp-capsule", or both.  Accordingly, a templated TCP proxy server MUST implement both Upgrade Tokens unless its use is restricted to a subset of compatible clients. </ins> <del> When using the Capsule Protocol, TCP payload data is sent in the </del> <ins> When using "connect-tcp-capsule", TCP payload data is sent in the </ins> payload of a new Capsule Type named DATA (data-capsule).  The ordered <del> concatenation of DATA capsule payloads has the same semantics as what would have been sent on the data stream if the Capsule Protocol were not in use.  It is applicable whenever use of the Capsule Protocol is optional. </del> <ins> concatenation of DATA capsule payloads represents the main payload data stream in any protocol where this is well-defined. Intermediaries MAY split or merge DATA capsules.  Endpoints MAY indicate a TCP connection error by sending an incomplete DATA capsule, as an alternative to using TCP, TLS, or HTTP stream errors. </ins> 4.
8.1. <del> IF APPROVED, IANA is requested to add the following entry to the HTTP Upgrade Token Registry: Value: "connect-tcp" Description: Proxying of TCP payloads Reference: (This document) </del> <ins> IF APPROVED, IANA is requested to add the following entries to the HTTP Upgrade Token Registry: </ins> For interoperability testing of this draft version, implementations <del> SHALL use the value "connect-tcp-05". </del> <ins> SHALL use the values "connect-tcp-06" and "connect-tcp-capsule-06. </ins> 8.2.
all the same requirements as for UDP proxying (RFC9298), and are subject to the same validation rules.  The client MUST substitute the destination host and port number into this template to produce the <del> request URI. </del> <ins> request URI.  The derived URI serves as the destination of a Capsule Protocol connection using the Upgrade Token "connect-tcp" (see registration in new-upgrade-token). When using "connect-tcp", TCP payload data is sent in the payload of a new Capsule Type named DATA (see registration in data-capsule). The ordered concatenation of DATA capsule payloads represents the TCP payload data. An intermediary MAY merge and split successive DATA capsules, subject to the following requirements: There are no intervening capsules of other types. The order of payload content is preserved. </ins> 3.1.
The response SHALL include a single "Upgrade" header field with the value "connect-tcp". <ins> The response SHOULD include a "Capsule-Protocol: ?1" header. </ins> If the request is malformed or impermissible, the proxy MUST return a 4XX error code.  If a TCP connection was not established, the proxy MUST NOT switch protocols to "connect-tcp", and the client MAY reuse this connection for additional HTTP requests. <del> After a success response is returned, the connection SHALL conform to all the usual requirements for classic CONNECT proxies in HTTP/1.1 (RFC9110).  Additionally, if the proxy observes a connection error from the client (e.g., a TCP RST, TCP timeout, or TLS error), it SHOULD send a TCP RST to the target.  If the proxy observes a connection error from the target, it SHOULD send a TLS "internal_error" alert to the client, or set the TCP RST bit if TLS is not in use.  These behaviors avoid truncation of transfers between the client and the target on vulnerable protocols (e.g., HTTP/1.1 without TLS) while preserving the confidentiality and integrity guarantees of the "https" scheme. </del> 3.2. In HTTP/2 and HTTP/3, the proxy MUST include
3.4. <del> When using the "connect-tcp" Upgrade Token, templated TCP proxies do not use the Capsule Protocol RFC9297.  Clients MAY request use of the Capsule Protocol by offering the Upgrade Token "connect-tcp-capsule" instead.  When offering or accepting the "connect-tcp-capsule" Upgrade Token, clients and servers SHOULD include a "Capsule- Protocol: ?1" header to facilitate processing by intermediaries. Clients of this specification MAY implement "connect-tcp", "connect- tcp-capsule", or both.  Accordingly, a templated TCP proxy server MUST implement both Upgrade Tokens unless its use is restricted to a subset of compatible clients. When using "connect-tcp-capsule", TCP payload data is sent in the payload of a new Capsule Type named DATA (data-capsule).  The ordered concatenation of DATA capsule payloads represents the main payload data stream in any protocol where this is well-defined. Intermediaries MAY split or merge DATA capsules.  Endpoints MAY indicate a TCP connection error by sending an incomplete DATA capsule, as an alternative to using TCP, TLS, or HTTP stream errors. </del> <ins> In each HTTP version, any requirements related to closing connections in Classic HTTP CONNECT also apply to "connect-tcp", with the following modifications: In HTTP/1.1, endpoints SHOULD close the connection in an error state to indicate receipt of a TCP connection error (e.g., a TCP RST or timeout).  Acceptable error states include sending an incomplete DATA capsule (as defined in RFC9297), a TLS Error Alert (RFC8446), or a TCP RST (if TLS is not in use).  When a connection is terminated in an error state, the receiving endpoint SHOULD send a TCP RST if the underlying TCP implementation permits it. In HTTP/2 and HTTP/3, senders MAY use an incomplete DATA capsule to indicate a TCP connection error, instead of (or in addition to) the signals defined for TCP connection errors in Classic HTTP CONNECT.  Recipients MUST recognize any incomplete capsule as a TCP connection error. Intermediaries MUST propagate connection shutdown errors, including when translating between different HTTP versions. </ins> 4.
8.1. <del> IF APPROVED, IANA is requested to add the following entries to the HTTP Upgrade Token Registry: </del> <ins> IF APPROVED, IANA is requested to add the following entry to the HTTP Upgrade Token Registry: </ins> For interoperability testing of this draft version, implementations <del> SHALL use the values "connect-tcp-06" and "connect-tcp-capsule-06. </del> <ins> SHALL use the value "connect-tcp-07". </ins> 8.2.
7. <del> 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. </del> <ins> In HTTP/1.1, clients that send CONNECT requests on behalf of untrusted TCP clients MUST wait for a 2xx (Successful) response before sending any TCP payload data. </ins> To mitigate vulnerabilities from any clients that do not conform to this requirement, proxy servers MAY close the underlying connection <del> when rejecting an HTTP CONNECT request, without processing any </del> <ins> when rejecting an HTTP/1.1 CONNECT request, without processing any </ins> 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.
semantics). Notice that the Cookie header field above contains two cookies, one <del> named SID and one named lang.  If the server wishes the user agent to persist the cookie over multiple "sessions" (e.g., user agent restarts), the server can specify an expiration date in the Expires attribute.  Note that the user agent might delete the cookie before the expiration date if the user agent's cookie store exceeds its quota or if the user manually deletes the server's cookie. </del> <ins> named SID and one named lang. Cookie names are case-sensitive, meaning that if a server sends the user agent two Set-Cookie header fields that differ only in their name's case the user agent will store and return both of those cookies in subsequent requests. If the server wishes the user agent to persist the cookie over multiple "sessions" (e.g., user agent restarts), the server can specify an expiration date in the Expires attribute.  Note that the user agent might delete the cookie before the expiration date if the user agent's cookie store exceeds its quota or if the user manually deletes the server's cookie. </ins> Finally, to remove a cookie, the server returns a Set-Cookie header field with an expiration date in the past.  The server will be
the name string is empty, and the value string is the value of name-value-pair. <del> Otherwise, the name string consists of the characters up to, but not including, the first %x3D ("=") character, and the (possibly empty) value string consists of the characters after the first %x3D ("=") character. </del> <ins> Otherwise, the (possibly empty) name string consists of the characters up to, but not including, the first %x3D ("=") character, and the (possibly empty) value string consists of the characters after the first %x3D ("=") character. </ins> Remove any leading or trailing WSP characters from the name string and the value string.
This document describes a use of HTTP Alternative Services RFC7838 to decouple the URI scheme from the use and configuration of underlying <del> encryption, allowing a "http" URI RFC7230 to be accessed using Transport Layer Security (TLS) RFC5246 opportunistically. </del> <ins> encryption.  It allows HTTP/2 RFC7540 to access a "http" URI RFC7230 using Transport Layer Security (TLS) RFC5246 with Opportunistic Security RFC7435. </ins> <del> Serving "https" URIs requires avoiding Mixed Content W3C.CR-mixed- content-20160802, which is problematic in many deployments.  This document describes a usage model whereby sites can serve "http" URIs over TLS, thereby avoiding these issues, while still providing </del> <ins> This document describes a usage model whereby sites can serve "http" URIs over TLS, thereby avoiding the problem of serving Mixed Content (describe in W3C.CR-mixed-content-20160802) while still providing </ins> protection against passive attacks. <del> Opportunistic Security RFC7435 does not provide the same guarantees as using TLS with "https" URIs; it is vulnerable to active attacks, and does not change the security context of the connection. </del> <ins> Opportunistic Security does not provide the same guarantees as using TLS with "https" URIs; Opportunistic Security is vulnerable to active attacks, and does not change the security context of the connection. </ins> Normally, users will not be able to tell that it is in use (i.e., there will be no "lock icon").
2.1. <del> Clients control which Client Hint headers and their respective header fields are communicated, based on their default settings, user configuration and/or preferences.  The user can be given the choice to enable, disable, or override specific hints. </del> <ins> Clients control which Client Hints are sent in requests, based on their default settings, user configuration and/or preferences. Implementers might provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations.  Implementations specific to certain use cases or threat models might avoid transmitting these headers altogether, or limit them to secure contexts or authenticated sessions.  Implementers should be aware that explaining the privacy implications of passive fingerprinting or network information disclosure may be challenging. </ins> The client and server, or an intermediate proxy, can use an opt-in mechanism to negotiate which fields should be reported to allow for
6. The "Downlink" request header field is a number that indicates the <del> client's maximum downlink speed in megabits per second (Mbps), as defined by the "downlinkMax" attribute in the W3C Network Information API (NETINFO). </del> <ins> client's maximum downlink speed in megabits per second (Mbps). </ins> If Downlink occurs in a message more than once, the minimum value should be used to override other occurrences.
2.2. <del> The ABNF (Augmented Backus-Naur Form) syntax for the Tunnel-Protocol header field is given below.  It is based on the Generic Grammar defined in RFC7230. </del> <ins> The ABNF (Augmented Backus-Naur Form) syntax for the `Tunnel- Protocol` header field is given below.  It is based on the Generic Grammar defined in RFC7230. </ins> ALPN protocol names are octet sequences with no additional constraints on format.  Octets not allowed in tokens (RFC7230) must
4. In case of using HTTP CONNECT to a TURN server the security <del> consideration of RFC7231 apply.  It states that there "are </del> <ins> considerations of RFC7231 apply.  It states that there "are </ins> significant risks in establishing a tunnel to arbitrary servers, particularly when the destination is a well-known or reserved TCP port that is not intended for Web traffic.  Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable whitelist of safe request targets." <del> The Tunnel-Protocol request header field described in this document is an optional header and HTTP Proxies may of course not support the header and therefore ignore it.  If the header is not present or ignored then the proxy has no explicit indication as to the purpose of the tunnel on which to provide consent, this is the generic case that exists without the Tunnel-Protocol header. </del> <ins> The `Tunnel-Protocol` request header field described in this document is an optional header.  Clients and HTTP Proxies could choose to not support the header and therefore fail to provide it, or ignore it when present.  If the header is not available or ignored, a proxy cannot identify the purpose of the tunnel and use this as input to any authorization decision regarding the tunnel.  This is indistinguishable from the case where either client or proxy does not support the `Tunnel-Protocol` header. </ins>
2.2. When presented with a request that contains one or more client hint <del> headers, servers can optimise the response based upon the information </del> <ins> headers, servers can optimize the response based upon the information </ins> in them.  When doing so, and if the resource is cacheable, the server MUST also generate a Vary response header field (Section 7.1.4 of RFC7231), and optionally Key (I-D.ietf-httpbis-key), to indicate
When a client receives Accept-CH, or if it is capable of processing the HTML response and finds an equivalent HTML meta element, it can <del> treat it as a signal that the server is interested in receiving </del> <ins> treat it as a signal that the application is interested in receiving </ins> specified request header fields that match the advertised field- <del> values; subsequent requests initiated to the same server and, optionally any subresource requests initiated as a result of processing the response from the server that includes the Accept-CH opt-in, can include the request header fields that match the advertised field-values. </del> <ins> values; subresource requests initiated as a result of processing the response from the server that includes the Accept-CH opt-in can include the request header fields that match the advertised field- values. </ins> For example, based on Accept-CH example above, a user agent could <del> append DPR, Width, Viewport-Width, and Downlink header fields to all </del> <ins> append DPR, Width, and Viewport-Width header fields to all </ins> subresource requests initiated by the page constructed from the <del> response.  Alternatively, a client can treat advertised support as a persistent origin preference and append same header fields on all future requests initiated to and by the resources associated with that origin. </del> <ins> response. </ins> 2.2.2. <ins> Servers can ask the client to remember an origin-wide Accept-CH preference for a specified period of time to enable delivery of Client Hints on all subsequent requests to the origin, and on subresource requests initiated as a result of processing a response from the origin. The field-value indicates that the Accept-CH preference should be considered stale after its age is greater than the specified number of seconds. For example, based on the Accept-CH and Accept-CH-Lifetime example above, a user agent could persist an origin-wide Accept-CH preference for up to 86400 seconds (1 day).  Then, if a request is initiated to the same origin before the preference is stale (e.g. as a result of a navigation to the origin, or fetching a subresource from the origin) the client could append the requested header fields (DPR and Viewport-Width in this example) to the request and any subresource requests initiated as a result of processing a response from same origin. 2.2.3. </ins> When selecting an optimized response based on one or more Client Hints, and if the resource is cacheable, the server needs to generate a Vary response header field (RFC7234) to indicate which hints can
Implementers ought to provide mechanisms and policies to control how and when such hints are advertised.  For example, they could require <del> origin opt-in; restrict delivery to same origin subrequests; limit delivery to requests that already carry indentifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on. </del> <ins> origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on. </ins> 6.
1. <del> Most if not all of the web pages processed by a web browser contain links to external resources that need to be fetched prior to rendering the documents.  Therefore, it is beneficial to send such links as early as possible in order to minimize the time spent until the browser becomes possible to render the document.  Link header of type "preload" (Preload) can be used to indicate such links within the response headers of an HTTP response. However, it is not always possible for an origin server to send a response immediately after receiving a request.  In fact, it is often the contrary.  There are many deployments in which an origin server needs to query a database before generating a response.  It is also not unusual for an origin server to delegate a request to an upstream HTTP server running at a distant location. </del> <ins> It is common for HTTP responses to contain links to external resources that need to be fetched prior to their use; for example, rendering HTML by a Web browser.  Having such links available to the client as early as possible helps to minimize perceived latency. The "preload" (Preload) link relation can be used to convey such links in the Link header field of an HTTP response.  However, it is not always possible for an origin server to generate a response header block immediately after receiving a request.  For example, the origin server might need to query a database before generating a response, or it might delegate a request to an upstream HTTP server running at a distant location. </ins> The dilemma here is that even though it is preferable for an origin server to send some headers as soon as it receives a request, it <del> cannot do so until the status code and the headers of the final HTTP response is determined. HTTP/2 (RFC7540) push can be used as a solution to the issue, but has its own limitations.  The resources that can be pushed using HTTP/2 are limited to those belonging to the same origin.  Also, it is impossible to send only the links of the resources using HTTP/2 push. Sending HTTP responses for every resource is an inefficient way of </del> <ins> cannot do so until the status code and the full headers of the final HTTP response are determined. HTTP/2 (RFC7540) server push can be used as a solution to this issue, but has its own limitations.  The responses that can be pushed using HTTP/2 are limited to those belonging to the same origin.  Also, it is impossible to send only the links using server push.  Finally, sending HTTP responses for every resource is an inefficient way of </ins> using bandwidth, especially when a caching server exists as an intermediary.
2. <del> This informational status code indicates the client that the server is likely to send a final response with the headers included in the informational response. </del> <ins> The 103 (Early Hints) informational status code indicates the client that the server is likely to send a final response with the headers included in the informational response. </ins> A server MUST NOT include Content-Length, Transfer-Encoding, or any <del> hop-by-hop headers (RFC7230, section 6.1) in the informational response using the status code. A client MAY speculatively evaluate the headers included in the informational response while waiting for the final response.  For example, a client may recognize the link header of type preload and start fetching the resource.  However, the evaluation MUST NOT affect how the final response is processed; the client must behave as if it had not seen the informational response.  A client MUST NOT process the headers included in the response as if they belonged to the informational response. </del> <ins> hop-by-hop header fields (RFC7230, section 6.1) in a 103 (Early Hints) response. A client MAY speculatively evaluate the headers included in a 103 (Early Hints) response while waiting for the final response.  For example, a client might recognize a Link header field value containing the relation type "preload" and start fetching the target resource. However, this MUST NOT affect how the final response is processed; when handling it, the client MUST behave as if it had not seen the informational response.  In particular, a client MUST NOT process the headers included in the final response as if they belonged to the informational response, or vice versa. </ins> An intermediary MAY drop the informational response.  It MAY send <del> HTTP/2 (RFC7540) push responses using the information found in the informational response. </del> <ins> HTTP/2 (RFC7540) server pushes using the information found in the 103 (Early Hints) response. </ins> 3. <del> Clients may have issues handling Early Hints, since informational response is rarely used for requests not including an Expect header (RFC7231, section 5.1.1). </del> <ins> Some clients may have issues handling 103 (Early Hints), since informational responses are rarely used in reply to requests not including an Expect header (RFC7231, section 5.1.1). </ins> <del> An HTTP/1.1 client that mishandles the informational response as a final response is likely to consider all the responses to the succeeding requests sent over the same connection to be part of the final response.  Such behavior may constitute a cross-origin </del> <ins> In particular, an HTTP/1.1 client that mishandles an informational response as a final response is likely to consider all responses to the succeeding requests sent over the same connection to be part of the final response.  Such behavior may constitute a cross-origin </ins> information disclosure vulnerability in case the client multiplexes requests to different origins onto a single persistent connection.