Code change:
This includes changing the title, adjusting the language to be more generic, and adding a section with guidance for HTTP CONNECT.
Most of the considerations in optimistic-upgrade, which originally emerged from consideration of "connect-tcp", also apply to HTTP CONNECT. We should consider expanding the scope of the draft to cover that topic as well. cc NAME

Related discussion:
text: The resource has moved, so the server replies with a 3XX redirect status code (RFC9110). <del> After rejecting the upgrade, the server will continue to interpret </del> <ins> Similarly, a CONNECT request might be rejected if: The server does not support HTTP CONNECT. The specified destination is not allowed under server policy. The destination cannot be resolved, is unreachable, or does not accept the connection. The proxy requires the client to authenticate before proceeding. After rejecting a request, the server will continue to interpret </ins> subsequent bytes on that connection in accordance with HTTP/1.1. RFC9110 also states: However, because of the possibility of rejection, the converse is not <del> true: a client cannot necessarily begin using an upgraded protocol merely because it has finished sending the upgrade request message. </del> <ins> true: a client cannot necessarily begin using a new protocol merely because it has finished sending the corresponding request message. </ins> <del> In some cases, the client might expect that the upgrade will succeed. If this expectation is correct, the client might be able to reduce delay by immediately sending the first bytes of the upgraded protocol "optimistically", without waiting for the server's response.  This document explores the security implications of this "optimistic" behavior. </del> <ins> In some cases, the client might expect that the protocol transition will succeed.  If this expectation is correct, the client might be able to reduce delay by immediately sending the first bytes of the new protocol "optimistically", without waiting for the server's response.  This document explores the security implications of this "optimistic" behavior. </ins> 3. When there are only two distinct parties involved in an HTTP/1.1 <del> connection (i.e., the client and the server), HTTP Upgrade introduces no new security issues: each party must already be prepared for the other to send arbitrary data on the connection at any time.  However, HTTP connections often involve more than two parties, if the requests or responses include third-party data.  For example, a browser (party 1) might send an HTTP request to an origin (party 2) with path, headers, or body controlled by a website from a different origin (party 3).  Post-upgrade protocols such as WebSocket similarly are often used to convey data chosen by a third party. </del> <ins> connection (i.e., the client and the server), protocol transitions introduce no new security issues: each party must already be prepared for the other to send arbitrary data on the connection at any time. However, HTTP connections often involve more than two parties, if the requests or responses include third-party data.  For example, a browser (party 1) might send an HTTP request to an origin (party 2) with path, headers, or body controlled by a website from a different origin (party 3).  Post-transition protocols such as WebSocket similarly are often used to convey data chosen by a third party. </ins> If the third-party data source is untrusted, we call the data it provides "attacker-controlled".  The combination of attacker- <del> controlled data and optimistic HTTP Upgrade results in two </del> <ins> controlled data and optimistic protocol transitions results in two </ins> significant security issues. 3.1.