[cpp-netlib-devel] [Proxy] The great forgotten feature :)

[Amoriello H. <amo...@gm...>]

Hi Dean, Contributors,


First of all, I would like to thanks you and the contributors of the
cpp-netlib for their awsome work!
I would like to use you library, but it misses a key feature for the
use I would like to make of this lib.

This feature is described as "Use O/S described proxy facilites"
https://github.com/cpp-netlib/cpp-netlib/issues/2

I am a cpp fan, but not as experienced as you and the contributors, so
I can't submit any pull request yet.

But I have red the docs (html, slide, paper and even the boostcon talk
:) and I finaly came to open the code.
All I can share (now) to help this request to be done, is to share
some points I saw while reading the code.

Actualy, I tried to imagine where to start if I wanted to implement a
"simple" http-proxy configuration : proxy name and port (no
authentication) in the sync_client impl.
(and because this is the only thing I need yet :)


* as you said in the request comment, I also think the best place to
configure the proxy information is the client ctor.
------------------------------------------------------------------------------------------------

So we can imagine we add have a

sync_client::sync_client (bool cache_resolved,
                                     bool follow_redirect,
                                     optional<string_type> const&
certificate_path = optional<string_type>(),
                                     optional<string_type> const&
verify_path = optional<string_type>(),
                                     optional<string_type> const&
proxy_host = optional<string_type>(),
                                     optional<string_type> const&
proxy_port = optional<string_type>())



* Then we have to change the sync_client:request_skeleton<>(...)
------------------------------------------------------------------------------------------------

In this function, you get the connection_object from the
connection_base::get_connection.
Here, we have to pass to the get_connection function the proxy_host
and proxy_port optionals string. That would lead to the following
prototype :

connection_ptr get_connection(resolver_type& resolver,
                                             basic_request<Tag> const& request_,
                                             optional<string_type>
const & certificate_file = optional<string_type>(),
                                             optional<string_type>
const & verify_file = optional<string_type>(),
                                             optional<string_type>
const & proxy_host = optional<string_type>(),
                                             optional<string_type>
const & proxy_port = optional<string_type>())


and then, if (proxy_host.size != 0), then I initialize the
connection_impl not on the request.host, and port, but on the
proxy_host and port.

----- I don't really think this "if" is what you expect in a "modern"
library design.




* Then the connection_base::send_request
------------------------------------------------------------------------------------------------

basic_response<Tag>
send_request(string_type const & method, basic_request<Tag> request_,
bool get_body)

Here, we loose the trace of the proxy_host and proxy_port optional
string (maybe they should be added to the connection_policy's private
members).

I think, there, we are close to the end of the "simple proxy support
implementation".




* Last, but not least. The linearize algorithm.
------------------------------------------------------------------------------------------------

When we connect to a proxy, (using GET for example), the GET parameter
MUST be the entire uri, not only the uri.path().

if (request.path().empty() || request.path()[0] != consts::slash_char())
       *oi = consts::slash_char();
boost::copy(request.path(), oi);


But there, we completely loose the trace of the proxy_host and
proxy_port information, so there is no way to know if it is the
complete uri that should be written, or only the uri.path().

I am not really friendly with boost::concept yet, so the linearize.hpp
code is quite obfuscated to me.
I don't know how to help the linearize algorithm to be aware of the
fact that it is behind a proxy or not.

Maybe a new tag "proxy" and some meta like "is_behind_proxy" to
provide a static dispatch based on the tag and avoid the ugly "if" in
the connection object, and help the linearize algo?

Thanks for this lib, I hope futur boost reviewer will see the
potential of this piece of master code and design, and will accept it
to be integrated in the boost trunk.
Sorry if I can't submit any pull request yet, and sorry for my bad english.

-- 
Amoriello Hutti