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?

Just found this about Linux/non-Windows http_client proxy support:
https://casablanca.codeplex.com/workitem/88

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.

Hi @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

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.

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

The approach looks good to me. Feel free to submit a PR.
@danimoth @ras0219-msft, FYI in case you all want to look at the design: Chris is implementing proxy support on non windows platforms.

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.

Ok, great. Thanks for the feedback. Yes @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.

@kavyako, could you comment on the last point above:

"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"

Do you know whether this this a bug or by design?

Hi @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

Hi,

is it possible to have Auto Proxy detection on non-Windows Platform ?

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.