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 ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Cpp-netlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
