docs: clarify use of Extended CONNECT for h/2

api/envoy/config/route/v3/route_components.proto

@@ -440,7 +440,7 @@ message RouteMatch {
     // (WebSocket and the like) as they are normalized in Envoy as HTTP/1.1 style
     // upgrades.
     // This is the only way to match CONNECT requests for HTTP/1.1. For HTTP/2,
-    // where CONNECT requests may have a path, the path matchers will work if
+    // where Extended CONNECT requests may have a path, the path matchers will work if
     // there is a path present.
     // Note that CONNECT support is currently considered alpha in Envoy.
     // [#comment:TODO(htuch): Replace the above comment with an alpha tag.

docs/root/intro/arch_overview/http/upgrades.rst

@@ -48,7 +48,7 @@ a deployment of the form:
 In this case, if a client is for example using WebSocket, we want the Websocket to arrive at the
 upstream server functionally intact, which means it needs to traverse the HTTP/2 hop.
 
-This is accomplished via `extended CONNECT <https://tools.ietf.org/html/rfc8441>`_ support,
+This is accomplished via `Extended CONNECT (RFC8441) <https://tools.ietf.org/html/rfc8441>`_ support,
 turned on by setting :ref:`allow_connect <envoy_v3_api_field_config.core.v3.Http2ProtocolOptions.allow_connect>`
 true at the second layer Envoy. The
 WebSocket request will be transformed into an HTTP/2 CONNECT stream, with :protocol header
@@ -85,7 +85,7 @@ and forward the HTTP payload upstream. On receipt of initial TCP data from upstr
 will synthesize 200 response headers, and then forward the TCP data as the HTTP response body.
 
 .. warning::
-  This mode of CONNECT support can create major security holes if configured correctly, as the upstream
+  This mode of CONNECT support can create major security holes if not configured correctly, as the upstream
   will be forwarded *unsanitized* headers if they are in the body payload. Please use with caution
 
 Tunneling TCP over HTTP/2