Menu
▾
▴
cpp-netlib-devel
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-02-17 19:23:33
|
Is OpenSSL required in order to compile a simple http client? If I make a little test program like #include "boost/network/protocol/http.hpp" typedef network::http::basic_client<tags::http_keepalive_8bit_udp_resolve, 1, 1> http_client; http_client(); I get an error C:\work\boost\boost/asio/ssl/detail/openssl_types.hpp(23) : fatal error C1083: Cannot open include file: 'openssl/conf.h': No such file or directory Any thoughts? Erik |
|
From: Glyn M. <gly...@gm...> - 2010-02-17 19:29:27
|
Hi Erik, On 17 February 2010 20:22, Nelson, Erik - 2 <eri...@ba... > wrote: > > Is OpenSSL required in order to compile a simple http client? If I make > a little test program like > > #include "boost/network/protocol/http.hpp" > typedef > network::http::basic_client<tags::http_keepalive_8bit_udp_resolve, 1, 1> > http_client; > http_client(); > > > I get an error > > C:\work\boost\boost/asio/ssl/detail/openssl_types.hpp(23) : fatal error > C1083: Cannot open include file: 'openssl/conf.h': No such file or > directory > > Any thoughts? > > That example shouldn't need OpenSSL and therefore that's a bug. Can you add a ticket to the issue tracker? http://github.com/cpp-netlib/cpp-netlib/issues Thanks for bringing this to our attention, Glyn |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-02-17 19:52:17
|
From: Glyn Matthews >That example shouldn't need OpenSSL and therefore that's a bug. Can you add a ticket to the issue tracker? done- thanks |
|
From: Dean M. B. <mik...@gm...> - 2010-02-18 05:57:51
|
Hi Glyn and Erik, Unfortunately because we support HTTPS, we require OpenSSL everytime. There should be a way to disable it though. HTH On Thu, Feb 18, 2010 at 3:51 AM, Nelson, Erik - 2 <eri...@ba...> wrote: > From: Glyn Matthews > >>That example shouldn't need OpenSSL and therefore that's a bug. Can you >> add a ticket to the issue tracker? > > done- thanks > > ------------------------------------------------------------------------------ > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > _______________________________________________ > Cpp-netlib-devel mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel > > -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-02-18 15:28:13
|
From: Dean Michael Berris on Thursday, February 18, 2010 12:56 AM >Unfortunately because we support HTTPS, we require OpenSSL everytime. >There should be a way to disable it though. A few things to think about in the discussion --there are a number of SSL providers available... OpenSSL, MatrixSSL, MS Windows API --OpenSSL may be packaged with most GNU/Linux distributions, but it's not on Windows --OpenSSL has a dependency on Perl to build on MS Windows, so an additional dependency is created (Perl is not packaged with Windows) I understand that the effect could be made with a define like BOOST_NETLIB_NO_SSL, but that seems like a big hammer... Is there no other way to pay for only what you use (http, in this case)? As an aside, I previously investigated building both MatrixSSL and OpenSSL into my portable (Windows/Linux) app and found MatrixSSL much simpler to work with. Erik |
|
From: Dean M. B. <mik...@gm...> - 2010-02-19 15:41:16
|
On Thu, Feb 18, 2010 at 11:27 PM, Nelson, Erik - 2 <eri...@ba...> wrote: > From: Dean Michael Berris on Thursday, February 18, 2010 12:56 AM > >>Unfortunately because we support HTTPS, we require OpenSSL everytime. >>There should be a way to disable it though. > > A few things to think about in the discussion > > --there are a number of SSL providers available... OpenSSL, MatrixSSL, > MS Windows API If Boost.Asio works with any of these, then you should be able to link to them. > --OpenSSL may be packaged with most GNU/Linux distributions, but it's > not on Windows Yes. Although the choice of OpenSSL is made by Boost.Asio. Where Boost.Asio works, cpp-netlib should work too. > --OpenSSL has a dependency on Perl to build on MS Windows, so an > additional dependency is created (Perl is not packaged with Windows) > > I understand that the effect could be made with a define like > BOOST_NETLIB_NO_SSL, but that seems like a big hammer... Is there no > other way to pay for only what you use (http, in this case)? > There should be a compile-time option for that, although it's not yet implemented. Boost.Asio has a way of turning off SSL support too. > As an aside, I previously investigated building both MatrixSSL and > OpenSSL into my portable (Windows/Linux) app and found MatrixSSL much > simpler to work with. > Again, if Boost.Asio works with it then it should be doable. cpp-netlib depends on Boost.Asio to provide the SSL support and functionality at the transport level. cpp-netlib is much higher level for that. -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-02-19 16:00:09
|
From: Dean Michael Berris Friday, February 19, 2010 10:41 AM >If Boost.Asio works with any of these, then you should be able to link to them. Fair enough >Yes. Although the choice of OpenSSL is made by Boost.Asio. Where Boost.Asio works, cpp-netlib should work too. Fair enough > --OpenSSL has a dependency on Perl to build on MS Windows, so an > additional dependency is created (Perl is not packaged with Windows) > > I understand that the effect could be made with a define like > BOOST_NETLIB_NO_SSL, but that seems like a big hammer... Is there no > other way to pay for only what you use (http, in this case)? > >There should be a compile-time option for that, although it's not yet implemented. Boost.Asio has a way of turning off SSL support too. Does this *have* to be a compile-time option? Can't we just not #include some https files?> >Again, if Boost.Asio works with it then it should be doable. >cpp-netlib depends on Boost.Asio to provide the SSL support and functionality at the transport level. cpp-netlib is much higher level for that. Okay, thanks for the detailed response. Erik |
|
From: Dean M. B. <mik...@gm...> - 2010-02-19 16:20:41
|
On Fri, Feb 19, 2010 at 11:59 PM, Nelson, Erik - 2 <eri...@ba...> wrote: > From: Dean Michael Berris Friday, February 19, 2010 10:41 AM > >>There should be a compile-time option for that, although it's not yet > implemented. Boost.Asio has a way of turning off SSL support too. > > Does this *have* to be a compile-time option? Can't we just not > #include some https files?> > Yes, even a #include is a compile-time option. This also allows you to define the macro from the command-line of the compiler if it's allowed, or from the .cpp file before including cpp-netlib HTTP-related headers. -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-02-19 16:55:08
|
From: Dean Michael Berris Sent: Friday, February 19, 2010 11:20 AM > Yes, even a #include is a compile-time option. This also allows you to define > the macro from the command-line of the compiler if it's allowed, or > from the .cpp file before >including cpp-netlib HTTP-related headers. I guess I was thinking of it another way... For example, there are lots of things in boost that I don't use, yet I don't need to #define any macros whatsoever- I simply don't include the header files. More specifically, if I want to use only the 'new' Spirit, and not the classic Spirit, I don't need to #define DISABLE_CLASSIC_SPIRIT I simply #include the files that have the functionality that I need. In sync_connection_base.hpp, classes https_sync_connection and http_sync_connection are defined. It's not clear to me why http_sync_connection should require boost/asio/ssl.hpp to be included... if these two classes were defined in separate files (say https_sync_connection.hpp and http_sync_connection.hpp) couldn't we avoid the need to have a command-line #define to eliminate something that my program never requested? I'm not sure exactly how the design evolved, but I'm guessing it started with just http and then https was added, leading to the branching on 'bool https' in sync_connection_base::new_connection. I haven't looked through the code, but it feels a little like https is a little uncomfortable there... suppose some other transports become available for http, and we end up with 'httpa', 'httpb', and 'httpc'. It seems to me that #defining three more things that I don't want to use, and adding three more args to sync_connection_base::new_connection would feel a little strange. Anyway, this is just my viewpoint- I know you've got tons of stuff to do, and my parents always told me not to get in the way of the person doing the work. However you decide to handle it is fine with me. Erik |
|
From: Dean M. B. <mik...@gm...> - 2010-02-21 14:32:53
|
On Sat, Feb 20, 2010 at 12:54 AM, Nelson, Erik - 2 <eri...@ba...> wrote: > From: Dean Michael Berris Sent: Friday, February 19, 2010 11:20 AM > >> Yes, even a #include is a compile-time option. This also allows you to > define >> the macro from the command-line of the compiler if it's allowed, or >> from the .cpp file before >including cpp-netlib HTTP-related headers. > > I guess I was thinking of it another way... For example, there are lots > of things in boost that I don't use, yet I don't need to #define any > macros whatsoever- I simply don't include the header files. > > More specifically, if I want to use only the 'new' Spirit, and not the > classic Spirit, I don't need to > > #define DISABLE_CLASSIC_SPIRIT > > I simply #include the files that have the functionality that I need. > > In sync_connection_base.hpp, classes https_sync_connection and > http_sync_connection are defined. It's not clear to me why > http_sync_connection should require boost/asio/ssl.hpp to be included... > if these two classes were defined in separate files (say > https_sync_connection.hpp and http_sync_connection.hpp) couldn't we > avoid the need to have a command-line #define to eliminate something > that my program never requested? > Sure, but then that's not user friendly IMO. I'd rather have someone do: #include <boost/network/include/http.hpp> And they get both the client and the server headers and support for HTTPS out of the box. If they don't want HTTPS support on the client site, then that's not the full-featured HTTP client -- and you have to say that explicitly. Something like: #include <boost/network/include/http/client.hpp> #include <boost/network/include/http/server.hpp> Would also be nice. Having additional includes just for explicit HTTPS support doesn't sound like a friendly solution from my perspective. > I'm not sure exactly how the design evolved, but I'm guessing it started > with just http and then https was added, leading to the branching on > 'bool https' in sync_connection_base::new_connection. > > I haven't looked through the code, but it feels a little like https is a > little uncomfortable there... suppose some other transports become > available for http, and we end up with 'httpa', 'httpb', and 'httpc'. > It seems to me that #defining three more things that I don't want to > use, and adding three more args to sync_connection_base::new_connection > would feel a little strange. > Actually, it's meant to be scalable that way -- dynamically. And no, there are no other protocols coming for HTTP that I know, and even if there are, yes you'd have to turn off the features you don't want to use. By default, to be friendly to most users who expect a full-feature HTTP client, you enable everything. > Anyway, this is just my viewpoint- I know you've got tons of stuff to > do, and my parents always told me not to get in the way of the person > doing the work. However you decide to handle it is fine with me. > For now you need OpenSSL. It's not a high priority for me to implement that macro define switch, unless you send a patch or fork the project. ;) HTH -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-02-22 17:35:07
|
From: Dean Michael Berris on Sunday, February 21, 2010 9:32 AM >For now you need OpenSSL. It's not a high priority for me to implement >that macro define switch, unless you send a patch or fork the project. ;) Fair enough... I'll just hack something in for now that works for me. Erik |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X