-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proxy support on Linux #9
Comments
This is the unit test I mentioned: 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: |
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 |
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, |
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! |
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, |
The approach looks good to me. Feel free to submit a PR. |
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:
Do you know whether this this a bug or by design? |
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. |
…oft#9) The premake build structure has been simplified and rewritten to reduce the boilerplate needed to add additional configurations while forcing the unique settings of a project to be defined. Migrate some defines and compiler options to the global settings and remove all the old boilerplate from this project. Issue-number: https://devtopia.esri.com/runtime/devops/issues/830 Signed-off-by: Christian O. Venegas <[email protected]>
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:
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
The text was updated successfully, but these errors were encountered: