cpp-netlib-devel — Developers Mailing List

[cpp-netlib-devel] two servers listening on same port?

[Nelson, E. - 2 <eri...@ba...>]

If I try to run two servers on the same port, will I get an error?
Taking from the hello_world_server.cpp example, something like

 

 

hello_world handler;

server server_("localhost", "3000", handler);

server server_1("localhost", "3000", handler);

 

if I call run() on both servers from different threads, it appears that
no exception is thrown... is that expected behavior?  Is there some way
to detect if a port is already in use?

 

Thanks

 

Erik

Re: [cpp-netlib-devel] Suggestions for a logo?

[Dean M. B. <mik...@gm...>]

On Tue, Mar 9, 2010 at 7:29 AM, Allister Levi Sanchez
<all...@gm...> wrote:
>
> Hey Dean,
> Got nothing to do tonight so here's another try.  Please forgive the simplicity (not a graphics whiz either (just used OpenOffice Draw) LOL.

LOL. :D I love it. :)

Any comments from the others?

--
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Proposal: Utilities Directory

[Dean M. B. <mik...@gm...>]

On Sat, Feb 27, 2010 at 11:10 AM, Marshall Clow <mcl...@gm...> wrote:
> On Feb 11, 2010, at 9:02 AM, Darren Garvey wrote:
>>
>>
>> Marshall, are you planning to integrate your MIME parser with cpp-netlib?
>
>
> [ Sorry for the long delay - work jumped up and bit me hard ]

I know that just all too well. :)

> Yes and no. ;-)

Cool. :D

> I think that the MIME routines (parser, storage, manipulation, and output)
> should be a separate library from cpp-netlib.
> However, I have no problem with cpp-netlib using it, and I will be checking
> it into the cpp-netlib github repo so that development of the two can
> continue together.

Cool. :D

> -- Marshall
> P.S. The reasoning behind this that other libraries in boost might want to
> consume/create/manipulate MIME messages.

I agree 100%.

> P.P.S. If you *completely* hate this, let me know and we can hash it out.

No objection from me. :)

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Proposal: Utilities Directory

[Darren G. <dar...@gm...>]

Hi Marshall,

On 27 February 2010 03:10, Marshall Clow <mcl...@gm...> wrote:

> On Feb 11, 2010, at 9:02 AM, Darren Garvey wrote:
>
> I've taken a look at this. It looks pretty cool, like it could fit the
> bill. Two extra features that I would find very useful are:
>
> * Either:
>   - Ability to restart the parser - ie. support chunked data.
>   or:
>   - Ability to pass in a Boost.Asio-compatible *ReadStream instead of an
> istream.
> * Ability to store file uploads directly to the filesystem (ie. so you can
> support uploading huge files).
>
> Marshall, are you planning to integrate your MIME parser with cpp-netlib?
>
>
> [ Sorry for the long delay - work jumped up and bit me hard ]
>
> Yes and no. ;-)
>
> I think that the MIME routines (parser, storage, manipulation, and output)
> should be a separate library from cpp-netlib.
>

Yes, for sure. MIME parsing is generally useful enough to justify a library
in itself... Equally, I think a URL library would be useful in and of itself
too.


>  However, I have no problem with cpp-netlib using it, and I will be
> checking it into the cpp-netlib github repo so that development of the two
> can continue together.
>

This is how I saw it being done. Please let us know when you check this in!


> -- Marshall
>
> P.S. The reasoning behind this that other libraries in boost might want to
> consume/create/manipulate MIME messages.
>

eg. A CGI library. ;o)


> P.P.S. If you *completely* hate this, let me know and we can hash it out.
>

Sounds good to me.

Cheers,
Darren

Re: [cpp-netlib-devel] Proposal: Utilities Directory

[Marshall C. <mcl...@gm...>]

On Feb 11, 2010, at 9:02 AM, Darren Garvey wrote:

> Hi Dean,
> 
> On 11 February 2010 14:25, Dean Michael Berris <mik...@gm...> wrote:
> I was thinking about this a little and thought it would be cool to
> have a collection of utilities of commonly-performed actions that
> others might find useful in the library. Off the top of my head I find
> that these would be cool functions/mini-libraries to have: 
>  * MIME Parser (Marshall Clow has a cool one worthy of more attention
> and discussion, hopefully he merges it into cpp-netlib in time for
> BoostCon 2010 ;) ).
> 
> I've taken a look at this. It looks pretty cool, like it could fit the bill. Two extra features that I would find very useful are:
> 
> * Either:
>   - Ability to restart the parser - ie. support chunked data.
>   or:
>   - Ability to pass in a Boost.Asio-compatible *ReadStream instead of an istream.
> * Ability to store file uploads directly to the filesystem (ie. so you can support uploading huge files).
> 
> Marshall, are you planning to integrate your MIME parser with cpp-netlib?
> 

[ Sorry for the long delay - work jumped up and bit me hard ]

Yes and no. ;-)

I think that the MIME routines (parser, storage, manipulation, and output) should be a separate library from cpp-netlib.
However, I have no problem with cpp-netlib using it, and I will be checking it into the cpp-netlib github repo so that development of the two can continue together.

-- Marshall

P.S.	The reasoning behind this that other libraries in boost might want to consume/create/manipulate MIME messages.

P.P.S.	If you *completely* hate this, let me know and we can hash it out.

[cpp-netlib-devel] Connection info

[Nelson, E. - 2 <eri...@ba...>]

If I have a basic handler along the lines of the one in
hello_world_server.cpp

struct hello_world {
    /*<< This is the function that handles the incoming request. >>*/
    void operator() (server::request const &request,
                     server::response &response) {
        response = server::response::stock_reply(
            server::response::ok, "Hello, World!");
    }
    /*<< It's necessary to define a log function, but it's ignored in
         this example. >>*/
    void log(...) {
        // do nothing
    }
};

is there any easy way to retrieve the client ip address, and the ip
address and port that the request arrived on?

Thanks

Erik

Re: [cpp-netlib-devel] Template compile error, v0.5

[Glyn M. <gly...@gm...>]

Hello Erik,

On 24 February 2010 17:30, Nelson, Erik - 2 <eri...@ba...
> wrote:

> If I make a program like
>
>
> *******************************************
> #include "boost/network/protocol/http/client.hpp"
>
> typedef
> boost::network::http::basic_client<boost::network::tags::http_keepalive_
> 8bit_udp_resolve, 1, 1> http_client;
>
> void func()
> {
>   http_client::request request;
>   http_client client;
>   client.get(request);
> }
>
> #include "boost/network/protocol/http/server.hpp"
> ********************************************
>
> I get a compile error that I've been unable to figure out that begins
>
> 1>C:\work\boost\boost/network/protocol/http/impl/sync_connection_base.hp
> p(318) : error C2059: syntax error : '<'
> 1>
> C:\work\boost\boost/network/protocol/http/policies/pooled_connection.hpp
> (36) : see reference to class template instantiation
> 'boost::network::http::impl::sync_connection_base<Tag,version_major,vers
> ion_minor>' being compiled
>
>
>
I can confirm that I get the same error using MSVC 8.0 with the following
code:

#include "boost/network/protocol/http/client.hpp"
#include "boost/network/protocol/http/server.hpp"


int
main(int argc, char *argv[]) {
    typedef

 boost::network::http::basic_client<boost::network::tags::http_keepalive_8bit_udp_resolve,
1, 1> http_client;
    http_client client;
    return 0;
}

You only pasted part of the compiler error message, the lines following this
are:

..\..\..\boost/network/protocol/http/policies/sync_resolver.hpp(25) : error
C2039: 'type' : is not a member of '`global namespace''
..\..\..\boost/network/protocol/http/policies/sync_resolver.hpp(25) : error
C2238: unexpected token(s) preceding ';'
..\..\..\boost/network/protocol/http/policies/sync_resolver.hpp(26) : error
C2065: 'string_type' : undeclared identifier
..\..\..\boost/network/protocol/http/policies/sync_resolver.hpp(32) : error
C2061: syntax error : identifier 'string_type'
..\..\..\boost/network/protocol/http/policies/pooled_connection.hpp(28) :
error C2059: syntax error : '<'
..\..\..\boost/network/protocol/http/policies/pooled_connection.hpp(28) :
error C2039: 'type' : is not a member of '`global namespace''
..\..\..\boost/network/protocol/http/policies/pooled_connection.hpp(28) :
error C2238: unexpected token(s) preceding ';'
..\..\..\boost/network/protocol/http/policies/pooled_connection.hpp(31) :
error C2059: syntax error : ','

etc.

and the code that appears to be failing is:

typedef typename string<Tag>::type string_type;


I managed to make this compile by changing this line to:

typedef typename boost::network::string<tag>::type string_type;


but clearly this is just masking the real error because it complains about
it not finding this type in the global namespace.  My guess is an ADL error
but I don't have the time to go looking for this right now.

I have created an issue:
http://github.com/cpp-netlib/cpp-netlib/issues/issue/13

Thanks for spotting this,
Glyn

[cpp-netlib-devel] Template compile error, v0.5

[Nelson, E. - 2 <eri...@ba...>]

If I make a program like


*******************************************
#include "boost/network/protocol/http/client.hpp"

typedef
boost::network::http::basic_client<boost::network::tags::http_keepalive_
8bit_udp_resolve, 1, 1> http_client;

void func()
{
   http_client::request request;
   http_client client;
   client.get(request);
}

#include "boost/network/protocol/http/server.hpp"
********************************************

I get a compile error that I've been unable to figure out that begins

1>C:\work\boost\boost/network/protocol/http/impl/sync_connection_base.hp
p(318) : error C2059: syntax error : '<'
1>
C:\work\boost\boost/network/protocol/http/policies/pooled_connection.hpp
(36) : see reference to class template instantiation
'boost::network::http::impl::sync_connection_base<Tag,version_major,vers
ion_minor>' being compiled


For what it's worth, I get the same error if I add

#include "boost/network/protocol/http/server.hpp"

as the last line of the example 'http_client.cpp'

Has anyone else seen this?  Any hints about what I'm doing wrong?

Thanks

Erik

Re: [cpp-netlib-devel] OpenSSL and cpp-netlib

[Nelson, E. - 2 <eri...@ba...>]

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

Re: [cpp-netlib-devel] OpenSSL and cpp-netlib

[Dean M. B. <mik...@gm...>]

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

Re: [cpp-netlib-devel] OpenSSL and cpp-netlib

[Nelson, E. - 2 <eri...@ba...>]

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

Re: [cpp-netlib-devel] OpenSSL and cpp-netlib

[Dean M. B. <mik...@gm...>]

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

Re: [cpp-netlib-devel] OpenSSL and cpp-netlib

[Nelson, E. - 2 <eri...@ba...>]

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

Re: [cpp-netlib-devel] OpenSSL and cpp-netlib

[Dean M. B. <mik...@gm...>]

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

[cpp-netlib-devel] Not sure if this is important

[Nelson, E. - 2 <eri...@ba...>]

In pooled_connection.hpp it seems like lots of copies are being made of
the request...

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

makes a copy when it is called, and

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

Makes another copy when it's called.

If, for example, I do something

string body("hello");
client.put(request, body);

No fewer than four instances of the body string will exist
simultaneously... one copy will be made in client.put(), one in
connection.send_request, and another in connection.send_request_impl

I'm not sure if that's intentional or not but it seems a bit
inefficient.  It seems like there need not ever be more than the
original body.

For what it's worth, it might make sense to use boost ranges to specify
the body, thereby decoupling it from the string_type which seems to be
pervasive.  The ranges are cheap to copy since they only reference the
actual storage, and they let the user use whatever storage makes sense.
(std::string, char[], vector<char>, boost::array<char>, etc.)

Let me know if you feel like I'm spamming the list... I'm just getting
into embedding a client and server in my app and noticing a few things.
I appreciate the hard work that you put into cpp-netlib.

Erik

Re: [cpp-netlib-devel] protocol/http/traits/connection_policy.hpp question

[Nelson, E. - 2 <eri...@ba...>]

From: Nelson, Erik on Thursday, February 18, 2010 10:47 AM

>In the course of working on something unrelated, I tried to compile
this one-line file

>#include <boost/network/protocol/http/traits/connection_policy.hpp>

>And I get an error, starting off with

>1>C:\work\boost\boost/network/protocol/http/policies/sync_resolver.hpp(
2
>5) : error C2143: syntax error : missing ';' before '<'
>1>
>C:\work\boost\boost/network/protocol/http/policies/sync_resolver.hpp(71
)
>: see reference to class template instantiation
'boost::network::http::policies::sync_resolver<Tag>' being compiled

>The offending line in sync_resolver.hpp is

>typedef typename string<Tag>::type string_type;

>Which I don't understand... the 'string' can't be a std::string, since
std::string is a typedef already.  I didn't see template class 'string'
>defined anywhere within cpp-netlib.

>Can anybody comment on how this works?

I found the definition of struct string... Problem was a missing
#include

Erik

[cpp-netlib-devel] protocol/http/traits/connection_policy.hpp question

[Nelson, E. - 2 <eri...@ba...>]

In the course of working on something unrelated, I tried to compile this
one-line file

#include <boost/network/protocol/http/traits/connection_policy.hpp>

And I get an error, starting off with

1>C:\work\boost\boost/network/protocol/http/policies/sync_resolver.hpp(2
5) : error C2143: syntax error : missing ';' before '<'
1>
C:\work\boost\boost/network/protocol/http/policies/sync_resolver.hpp(71)
: see reference to class template instantiation
'boost::network::http::policies::sync_resolver<Tag>' being compiled

The offending line in sync_resolver.hpp is

typedef typename string<Tag>::type string_type;

Which I don't understand... the 'string' can't be a std::string, since
std::string is a typedef already.  I didn't see template class 'string'
defined anywhere within cpp-netlib.

Can anybody comment on how this works?

Thanks

Erik

Re: [cpp-netlib-devel] OpenSSL and cpp-netlib

[Nelson, E. - 2 <eri...@ba...>]

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

Re: [cpp-netlib-devel] OpenSSL and cpp-netlib

[Dean M. B. <mik...@gm...>]

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

Re: [cpp-netlib-devel] OpenSSL and cpp-netlib

[Nelson, E. - 2 <eri...@ba...>]

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
 

Re: [cpp-netlib-devel] OpenSSL and cpp-netlib

[Glyn M. <gly...@gm...>]

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

[cpp-netlib-devel] OpenSSL and cpp-netlib

[Nelson, E. - 2 <eri...@ba...>]

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

Re: [cpp-netlib-devel] Sending/receiving binary messages

[Divye K. <div...@gm...>]

Hello everyone,
   Been a long time and I've been busy with my acads, but I had a
contribution I had to make to this discussion:

On Wed, Feb 17, 2010 at 1:45 AM, Dean Michael Berris <mik...@gm...
> wrote:

>
> Yes, it is possible. You can already use the cpp-netlib client to
> download in HTTP 1.0 mode binary data -- there are even tests packaged
> in the library to prove it.
> <snip>
> The plan is to keep cpp-netlib as it is right now able to handle
> binary data (of course transferred in the appropriate network byte
> order) as it comes over the wire.
>
>
I'm not so sure that byte conversion is being performed or being tested by
the library. The tests do not specifically check for byte conversion issues
as they are being run on the same host. The tests simply check that binary
data is transferred "as-is" between server and client and that the end
result is the same file data. Byte order tests are still missing I guess.
Dean might be able to throw light on the library implementation of the byte
order conversion issues.

@Erik: The binary transfer test is
libs/network/test/http_localhost_tests.cpp - binary_file_query

Divye

-- 
Life is complicated. Its that simple!

Re: [cpp-netlib-devel] Sending/receiving binary messages

[Nelson, E. - 2 <eri...@ba...>]

>From Dean Michael Berris Tuesday, February 16, 2010 3:35 PM

>Ah, on the server side there's nothing stopping you from doing that.
>Having used this to do just that, I can tell you with confidence that
there's no problem in that regard. :D

If I use boost.serialization to make binary archives (assuming I'm
controlling both the client and the server) I won't be able to ship
those around okay? E.g., I always will lose the high bit of each byte in
the binary buffer?

Erik

Re: [cpp-netlib-devel] Sending/receiving binary messages

[Dean M. B. <mik...@gm...>]

On Wed, Feb 17, 2010 at 4:26 AM, Nelson, Erik - 2
<eri...@ba...> wrote:
> >From Dean Michael Berris on Tuesday, February 16, 2010 3:16 PM
>
>>Yes, it is possible. You can already use the cpp-netlib client to
> download in HTTP 1.0 mode binary data -- there are even tests packaged
> in the library to prove it.
>
> That's great!  Does it work from the server side, too?  Are there plans
> for HTTP 1.1 support?
>

On the server side, HTTP 1.1 support I'm scheduling for 0.7 -- it
might make it into 0.6 *if* I find the time to implement it. :D

>>Have you encountered a bug that's not allowing you to download binary
> data using the HTTP client?
>
> Not at all... I was just trying to understand what was possible- here's
> my original question
>

OK. :)

>
>
> ****************************
> Is there any reason I can't send a binary response?
>
> For example, the hello_world_server has
>
> response = server::response::stock_reply(server::response::ok, "Hello,
> World!");
>
> Could I fill a string with binary data and send it like this?
>
> String s("\0\0\0\0\0")
> response = server::response::stock_reply(server::response::ok, s);
>
> and get it out on the client side?  If so, would I use
> boost::network::body(response) on the client side, or something else?
> ********************************
>
>
> I haven't actually tried it- can you comment on the original question?
> I poked around in the tests but didn't find the test that has an example
> of binary transfer.
>

Ah, on the server side there's nothing stopping you from doing that.
Having used this to do just that, I can tell you with confidence that
there's no problem in that regard. :D

> Thanks

I hope this helps. If you find any glaring bugs please don't hesitate
to let us know. :D

-- 
Dean Michael Berris
cplusplus-soup.com | twitter.com/deanberris
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com