Ember Proxy Support #6086
Replies: 4 comments
-
This is archaic, but is a sketch on blaze-client from a few years ago: #1182. It looks like I put a request attribute on things that blaze was supposed to tunnel. A second pool could work, but there are subtleties in how the request gets rendered (like rendering an absolute URI as the request target), so I think requests may still need to know they're being proxied. I think I remember this effort collapsing because I couldn't figure out how to add and remove the SSLStage on demand that was necessary to do a secure proxy. I think client is much higher value than server. There are a bunch of weird rules in the HTTP spec about how proxy servers are supposed to behave, and when |
Beta Was this translation helpful? Give feedback.
-
It would be really nice to have support for setting and observing custom headers sent and received during a TLS handshake. Many proxy servers can be controlled using the TLS handshake phase and often report additional information in the response headers. When we try to communicate with the target using HTTPS there is no other way for the proxy server to talk to the client but during the TLS handshake phase. (for example proxymesh https://docs.proxymesh.com/article/7-request-response-headers) client ----- HTTP----> proxy -----> HTTPS----> server
Usually the client has no access to the first CONNECT request and the first response so it cannot set/get any headers. There is a workaround in java http client when using a custom Either way it would be nice to have this functionality without the need of such code gymnastics. |
Beta Was this translation helpful? Give feedback.
-
This came up at $WORK today. We have someone on the deprecated AHC backend, using its proxy support, and I couldn't recommend Ember or Blaze. I think the JDK11 client (which is also excellent) will work for them, but sharing to show the demand is there. |
Beta Was this translation helpful? Give feedback.
-
Here is another case when proxy support would be handy - typelevel/otel4s#563. |
Beta Was this translation helpful? Give feedback.
-
What do we want proxy support to look like?
To summarize the basics. Connect is used to establish a pipe, which can be used like a normal connection once established. The resource being the full uri component rather than just the path. There are a slew of headers to be used as intermediaries for this process, Forwarded, X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto, Via and then otherwise acts like a tunnel.
I'm not even sure what we'd want this to look like api wise, let alone how it fits into the current modeling.
Throwing out ideas, on client we could have a secondary pool that gets checked first of tunnelled connections that is leveraged before the root pool. Which the client could automatically leverage.
On server, this is really more about what we want to allow and what we do as the data passes through our tunnel. To support this the client would need to be integrated in some form into the server, so probably would need some sort of subsystem. (Luckily the generic client interface is all in core types making it fairly straightforward to work without helpers)
Beta Was this translation helpful? Give feedback.
All reactions