Issue by sirthias
_Monday Oct 27, 2014 at 15:52 GMT_
_Originally opened as https://github.com/akka/akka/issues/16153_
Required for one connection:
CONNECT target.host:443 HTTP/1.1 request to the proxy2xx response (afterwards all communication on the connection will be directly tunneled through to the target host)This feature should likely be implemented on the level of host-level client-side API as in most cases you'll want a managed connection pool to the proxy.
Some pointers:
Comment by ktoso
_Wednesday Jul 15, 2015 at 21:10 GMT_
Relates to https://github.com/akka/akka/issues/17976
Comment by ktoso
_Thursday Nov 12, 2015 at 00:41 GMT_
Logging a "very big" +1 here, we may want to think how and when we could address this.
Comment by ktoso
_Wednesday Feb 10, 2016 at 11:05 GMT_
Logging another +1 (for my reference, sorry for the noise)
Comment by ktoso
_Wednesday Jun 29, 2016 at 14:44 GMT_
Akka team won't be able (time wise) to pick up this issue in the short-term, so we'd like to encourage you to try to contribute this feature, or contact us if you'd like sponsor its development.
+1
+1
+1
Any update on this? Every single corporate firewall on the planet requires you to connect to the outside world via an https proxy, so not having this makes the akka-http client functionality pretty much useless.
+1
Note that a PR is worth more than a million +1s. (Also please use the reaction button instead of spamming this ticket with +1 comments, thanks!)
+1, but if the +1 is not enough to express interest, I can always write: PLEASE FIX THIS, I AM INTERESTED IN SEEING THIS FIXED.
I was playing around this issue and managed to complete HTTPS request via proxy. Here is my code: https://github.com/akka/akka-http/compare/master...note:192-https-proxy?expand=1. It's not ready to be a PR, there is still a lot of work to do, I am mostly sharing it for early validation. So the solution boils down to having additional GraphStage (I called it ProxyGraphStage) between tlsStage and transportFlow. Its only goal is to send CONNECT, wait for OK answer and then simply forward all messages untouched. In future there should be correct error handling and so on. @jrudolph Does such approach makes sense? If it makes sense I will work further on this and prepare a PR.
Great work, @note for taking a stab at it. I just opened another PR yesterday which could be used as groundwork for it: it allows to redefine the transport the pool (or a single client connection) uses to access a host. The only predefined transport so far would be the existing TCP transport. Your HTTPS proxy support could be an HttpsProxyTransport, then we could have a SOCKS transport etc.
The basic change you would need to do is to include your underlying TCP connection to the HTTPS proxy into your code. Apart from that no changes to the existing http-core infrastructure would be necessary. WDYT?
It certainly looks promising, so please open a PR. I'll try to merge my PR this week so you can rebase on top of that.
For reference, the pluggable transport PR https://github.com/akka/akka-http/pull/917
@jrudolph Thanks for your feedback, your PR seems very helpful - with that I think there's a great chance I will be able to implement Https proxy without touching Http.scala at all. Will continue to work on this at latest on Monday.
Great, thanks, @note. We (and lots of other people) are looking forward to it.
Most helpful comment
Any update on this? Every single corporate firewall on the planet requires you to connect to the outside world via an https proxy, so not having this makes the akka-http client functionality pretty much useless.