This repository was archived by the owner on Jun 1, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Jun 1, 2026. It is now read-only.
Proxy support on Linux #9
Description
Hi, I'm having trouble getting connections through a web proxy to work on Linux (RHEL 7.1). I'm specifying the proxy by URI:
web::web_proxy proxy("http://my_proxy_ip_address:my_proxy_port_number");
web::http::client::http_client_config client_config;
client_config.set_proxy(proxy);
web::http::client::http_client client(baseUri, client_config);
I saw that one of the proxy unit tests was marked as Ignore on Linux. Is proxy supported on Linux?
Any help would be appreciated.
-Alex
Activity
aiklimov commentedon Oct 29, 2015
This is the unit test I mentioned:
TEST_FIXTURE(uri_address, proxy_with_credentials, "Ignore:Linux", "NYI", "Ignore:Apple", "NYI", "Ignore:Android", "NYI")
Is it the case that only auto-discovery proxies are supported at this time, but not ones with proxy host & port specified?
aiklimov commentedon Oct 29, 2015
Just found this about Linux/non-Windows http_client proxy support:
https://casablanca.codeplex.com/workitem/88
kavyako commentedon Nov 2, 2015
hey aiklimov
Correct, proxy support is Not Yet Implemented on non windows plaforms. Hence the "NIY" tag with the corresponding tests for Linux/Android/Apple.
Thanks
Kavya.
deeringc commentedon Dec 15, 2015
Hi Kavya Kotacherry - MSFT (@kavyako),
I'm looking at implementing proxy support for non-Windows platforms. Who would be the best person from your team to have a design discussion with? Or would you rather I just put up a PR once I'm done?
Thanks,
Chris
kavyako commentedon Dec 15, 2015
That's awesome! You could start the discussion here and I will pull in the experts to provide feedback. Don't mind a PR too but going through the design might avoid some roundtripping and save time.
Thanks!
Kavya.
deeringc commentedon Dec 17, 2015
Ok, great! So what I've implemented so far is support for http and https proxies (via ssl tunneling). The design goal I've gone with is to try to continue the patterns that are already used in http_client_asio.cpp and to minimise the impact on existing code/flows so as to reduce the chance of regressions in areas I'm not familiar with.
In the case of http proxies, the required change is quite small, we basically have to change some of the details in the http request (and add support for basic authentication) but the flow is basically the same.
However, in order to support https proxies I've had to make some bigger changes. The basic protocol is that we have to initially connect to the proxy via an un-encrypted tcp socket. We send a CONNECT request indicating the address and port that we ultimately want to connect our ssl session with. The proxy creates a tcp connection with that port and if that succeeds it sends back a 200 to our client. At this point the client needs to start an ssl handshake that is tunneled through the proxy but is terminated at the web server (the proxy can't read any of the content). Once this tunnel is established, the http request and response proceed as normal.
In order to support this flow, I've introduced a new 'ssl_proxy_tunnel' class, it is a nested class of asio_context. This class deals with the initial connection to the proxy, the connect request and handling the response from the proxy. It has its own set of the handle____ callback functions for dealing with the boost asio flow. As a nested class it has access to the private members of the asio_context and updates state as the flow progresses. Importantly, it has to 'upgrade' the socket to support ssl once this initial tunnel flow is complete and it then calls back into the asio_context to complete the rest of the http flow. All error handling is done by calling back into the asio_context.
The lifecycle is a little strange, but I've followed the pattern that is there already for the asio_context. Basically, the ssl_proxy_tunnel class takes and stores a shared_ptr to the asio_context (asio_context does not have a reference to the ssl_proxy_tunnel!). The ssl_proxy_tunnel is kept alive via the boost::functions that are passed into boost asio. This in turn keeps the asio_context alive. After the ssl_proxy_tunnel completes its flow and calls back into the asio_context, it goes out of scope but the asio_context is kept alive via the boost::functions that are passed into boost asio for the remainder of the http request/response flow.
Hopefully that is reasonably clear. I'm very happy to go into more detail so just let me know.
Regards,
Chris
kavyako commentedon Dec 17, 2015
The approach looks good to me. Feel free to submit a PR.
danimoth Robert Schumacher (@ras0219-msft), FYI in case you all want to look at the design: Chris is implementing proxy support on non windows platforms.
ras0219-msft commentedon Dec 17, 2015
It looks good to me. The only thing I'd note is to try to reuse the same APIs and semantics where they exist already if possible.
deeringc commentedon Dec 18, 2015
Ok, great. Thanks for the feedback. Yes Robert Schumacher (@ras0219-msft), I've reused all the same APIs that are already exposed via the consumer-facing interfaces. One thing to note is that I haven't added any auto-detection of proxies. The consumer must specify them via the web client config api.
On that point, the auto detection code on windows seems a little flaky. It did not seem to detect the proxy configured under Internet Properties->Lan Settings. It only detected the proxy once I manually configured it via the CLI.
deeringc commentedon Jan 7, 2016
Kavya Kotacherry - MSFT (@kavyako), could you comment on the last point above:
Do you know whether this this a bug or by design?
rashidak99 commentedon Feb 3, 2016
Hi Kavya Kotacherry - MSFT (@kavyako)
As per request #41, Proxy support for non-windows platforms will be available in Release 2.8.0. Can you share the timelines by when it will be available.
Thanks,
Rashida
PremanandPatil commentedon Apr 1, 2016
Hi,
is it possible to have Auto Proxy detection on non-Windows Platform ?
ras0219-msft commentedon May 3, 2016
Closing this since the feature was implemented in release 2.8.0.
PremanandPatil if you're still interested in auto-proxy detection, please make a new issue.
arch: Make changes needed for the new premake build structure (micros…