|
1 | | -.. _arch_overview_websocket: |
| 1 | +.. _arch_overview_upgrades: |
2 | 2 |
|
3 | 3 | HTTP upgrades |
4 | 4 | =========================== |
@@ -62,44 +62,43 @@ a GET method on the final Envoy-Upstream hop. |
62 | 62 | Note that the HTTP/2 upgrade path has very strict HTTP/1.1 compliance, so will not proxy WebSocket |
63 | 63 | upgrade requests or responses with bodies. |
64 | 64 |
|
65 | | -.. TODO(alyssawilk) unhide this when unhiding config |
66 | | -.. CONNECT support |
67 | | -.. ^^^^^^^^^^^^^^^ |
68 | | -
|
69 | | -.. Envoy CONNECT support is off by default (Envoy will send an internally generated 403 in response to |
70 | | -.. CONNECT requests). CONNECT support can be enabled via the upgrade options described above, setting |
71 | | -.. the upgrade value to the special keyword "CONNECT". |
72 | | -
|
73 | | -.. While for HTTP/2, CONNECT request may have a path, in general and for HTTP/1.1 CONNECT requests do |
74 | | -.. not have a path, and can only be matched using a |
75 | | -.. :ref:`connect_matcher <envoy_api_field_route.RouteMatch.connect_matcher>` |
76 | | -.. |
77 | | -.. Envoy can handle CONNECT in one of two ways, either proxying the CONNECT headers through as if they |
78 | | -.. were any other request, and letting the upstream terminate the CONNECT request, or by terminating the |
79 | | -.. CONNECT request, and forwarding the payload as raw TCP data. When CONNECT upgrade configuration is |
80 | | -.. set up, the default behavior is to proxy the CONNECT request, treating it like any other request using |
81 | | -.. the upgrade path. |
82 | | -.. If termination is desired, this can be accomplished by setting |
83 | | -.. :ref:`connect_config <envoy_api_field_config.filter.network.http_connection_manager.v2.HttpConnectionManager.UpgradeConfig.connect_config>` |
84 | | -.. If it that message is present for CONNECT requests, the router filter will strip the request headers, |
85 | | -.. and forward the HTTP payload upstream. On receipt of initial TCP data from upstream, the router |
86 | | -.. will synthesize 200 response headers, and then forward the TCP data as the HTTP response body. |
87 | | -
|
88 | | -.. .. warning:: |
89 | | -.. This mode of CONNECT support can create major security holes if configured correctly, as the upstream |
90 | | -.. will be forwarded *unsanitized* headers if they are in the body payload. Please use with caution |
91 | | -
|
92 | | -.. Tunneling TCP over HTTP/2 |
93 | | -.. ^^^^^^^^^^^^^^^^^^^^^^^^^ |
94 | | -.. Envoy also has support for transforming raw TCP into HTTP/2 CONNECT requests. This can be used to |
95 | | -.. proxy multiplexed TCP over pre-warmed secure connections and amortize the cost of any TLS handshake. |
96 | | -.. An example set up proxying SMTP would look something like this |
97 | | -.. |
98 | | -.. [SMTP Upstream] --- raw SMTP --- [L2 Envoy] --- SMTP tunneled over HTTP/2 --- [L1 Envoy] --- raw SMTP --- [Client] |
99 | | -.. |
100 | | -.. Examples of such a set up can be found in the Envoy example config `directory <https://github.com/envoyproxy/envoy/tree/master/configs/>` |
101 | | -.. If you run `bazel-bin/source/exe/envoy-static --config-path configs/encapsulate_in_connect.yaml --base-id 1` |
102 | | -.. and `bazel-bin/source/exe/envoy-static --config-path configs/terminate_connect.yaml` |
103 | | -.. you will be running two Envoys, the first listening for TCP traffic on port 10000 and encapsulating it in an HTTP/2 |
104 | | -.. CONNECT request, and the second listening for HTTP/2 on 10001, stripping the CONNECT headers, and forwarding the |
105 | | -.. original TCP upstream, in this case to google.com. |
| 65 | +CONNECT support |
| 66 | +^^^^^^^^^^^^^^^ |
| 67 | + |
| 68 | +Envoy CONNECT support is off by default (Envoy will send an internally generated 403 in response to |
| 69 | +CONNECT requests). CONNECT support can be enabled via the upgrade options described above, setting |
| 70 | +the upgrade value to the special keyword "CONNECT". |
| 71 | + |
| 72 | +While for HTTP/2, CONNECT request may have a path, in general and for HTTP/1.1 CONNECT requests do |
| 73 | +not have a path, and can only be matched using a |
| 74 | +:ref:`connect_matcher <envoy_v3_api_msg_config.route.v3.RouteMatch.ConnectMatcher>` |
| 75 | + |
| 76 | +Envoy can handle CONNECT in one of two ways, either proxying the CONNECT headers through as if they |
| 77 | +were any other request, and letting the upstream terminate the CONNECT request, or by terminating the |
| 78 | +CONNECT request, and forwarding the payload as raw TCP data. When CONNECT upgrade configuration is |
| 79 | +set up, the default behavior is to proxy the CONNECT request, treating it like any other request using |
| 80 | +the upgrade path. |
| 81 | +If termination is desired, this can be accomplished by setting |
| 82 | +:ref:`connect_config <envoy_v3_api_field_config.route.v3.RouteAction.UpgradeConfig.connect_config>` |
| 83 | +If it that message is present for CONNECT requests, the router filter will strip the request headers, |
| 84 | +and forward the HTTP payload upstream. On receipt of initial TCP data from upstream, the router |
| 85 | +will synthesize 200 response headers, and then forward the TCP data as the HTTP response body. |
| 86 | + |
| 87 | +.. warning:: |
| 88 | + This mode of CONNECT support can create major security holes if configured correctly, as the upstream |
| 89 | + will be forwarded *unsanitized* headers if they are in the body payload. Please use with caution |
| 90 | + |
| 91 | +Tunneling TCP over HTTP/2 |
| 92 | +^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 93 | +Envoy also has support for transforming raw TCP into HTTP/2 CONNECT requests. This can be used to |
| 94 | +proxy multiplexed TCP over pre-warmed secure connections and amortize the cost of any TLS handshake. |
| 95 | +An example set up proxying SMTP would look something like this |
| 96 | + |
| 97 | +[SMTP Upstream] --- raw SMTP --- [L2 Envoy] --- SMTP tunneled over HTTP/2 --- [L1 Envoy] --- raw SMTP --- [Client] |
| 98 | + |
| 99 | +Examples of such a set up can be found in the Envoy example config :repo:`directory <configs/>` |
| 100 | +If you run `bazel-bin/source/exe/envoy-static --config-path configs/encapsulate_in_connect.yaml --base-id 1` |
| 101 | +and `bazel-bin/source/exe/envoy-static --config-path configs/terminate_connect.yaml` |
| 102 | +you will be running two Envoys, the first listening for TCP traffic on port 10000 and encapsulating it in an HTTP/2 |
| 103 | +CONNECT request, and the second listening for HTTP/2 on 10001, stripping the CONNECT headers, and forwarding the |
| 104 | +original TCP upstream, in this case to google.com. |
0 commit comments