Skip to content
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

Closed
aiklimov opened this issue Oct 29, 2015 · 13 comments
Closed

Proxy support on Linux #9

aiklimov opened this issue Oct 29, 2015 · 13 comments

Comments

@aiklimov
Copy link

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

@aiklimov
Copy link
Author

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
Copy link
Author

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

@kavyako
Copy link
Contributor

kavyako commented 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
Copy link
Contributor

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

@kavyako
Copy link
Contributor

kavyako commented 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
Copy link
Contributor

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
Copy link
Contributor

kavyako commented Dec 17, 2015

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.

@ras0219-msft
Copy link
Contributor

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
Copy link
Contributor

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.

@deeringc
Copy link
Contributor

deeringc commented Jan 7, 2016

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

@rashidak99
Copy link

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

@PremanandPatil
Copy link

Hi,

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

@ras0219-msft
Copy link
Contributor

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.

GerHobbelt pushed a commit to GerHobbelt/cpprestsdk that referenced this issue Mar 20, 2024
…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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants