Support for HTTP CONNECT Proxies#1396
Conversation
DIDONAX
commented
May 9, 2026
DIDONAX
commented
- fixes Use HTTP CONNECT method for proxy server #263
- fixes bug where using tls was always determined by the proxy scheme rather than target scheme.
- fixes same issue with choosing the SNI.
|
As long as it is configurable separately. For Transitous we rely on setting a proxy for GBFS but not for GTFS-RT feeds. |
| auto const use_tls = | ||
| proxy.has_value() ? proxy->use_tls_ | ||
| : next_url.scheme_id() == boost::urls::scheme::https; | ||
| auto const use_tls = next_url.scheme_id() == boost::urls::scheme::https; |
There was a problem hiding this comment.
this will kill support for non-CONNECT proxies?
we still want to support "normal" proxies
There was a problem hiding this comment.
i tested this with proxy=https://rt.triptix.tech and use_connect = false and it works.
| boost::asio::awaitable<void> http_CONNECT(Stream& stream, | ||
| boost::urls::url const& url, | ||
| std::optional<proxy> const& proxy) { | ||
| if (!proxy) co_return; |
felixguendling
changed the title
| auto const use_tls = | ||
| proxy ? proxy->use_tls_ | ||
| : next_url.scheme_id() == boost::urls::scheme::https; |
There was a problem hiding this comment.
why don't we need this anymore?
There was a problem hiding this comment.
this was wrong, the request schema should always be that of the target: for example before for an http proxy a http request will always be forwarded even for an https target. i used mitmproxy to confirm this .
this is before (master branch) the feed endpoint is never reached:
and after:
so basically it wasn't working before when proxy and target schema didnt match.
There was a problem hiding this comment.
For CONNECT yes, but also for non-CONNECT? If the proxy is https but the target is http, I still need to send a https request?
There was a problem hiding this comment.
Also depends on the config of the proxy I guess. In rt.triptix.tech the schema of the target is just hardcoded, in a dynamic proxy I'm not sure what is supposed to happen. But maybe I'm missing something. I think rt.triptix.tech might not handle redirects correctly in this case either.
There was a problem hiding this comment.
the screenshots are with use_connect=false so this is the normal case. i also tested rt.triptix.tech with connect disabled and it seems to work. can you test if this is also the case for you?
There was a problem hiding this comment.
with rt.triptix.tech actually both variants should work because it listens on both 80 and 443 and because it will contact the upstream target with whatever scheme was configured for that target in the proxy.
But I guess in the end you're right that for a dynamic proxy, it is most important to know whether to connect to the upstream via http or https and without any additional headers etc it can only know that from it's own connection to the client – meaning all such proxies would need to listen on both http and https.
Do we know about someone else using the proxy feature already?
3 participants
