Boost logo

Boost Users :

Subject: Re: [Boost-users] Help needed in learning to use Boost.Asio
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2017-10-24 13:54:48

On Tue, Oct 24, 2017 at 6:04 AM, Osman Zakir via Boost-users
<boost-users_at_[hidden]> wrote:
> Boost.Beast is a library that only provides low-level support for HTTP? But
> what does that mean, exactly?

Beast provides:

* A universal container for holding HTTP messages
* Algorithms for sending and receiving messages on streams
* A WebSocket stream implementation

> What will users not be able to do with it,

Beast does not manage the socket for you. So you have to create the
listening socket yourself, accept connections, make outgoing
connections, shut down the connection. For SSL you have to use Asio to
manage certificates and verification. But Beast will work with SSL
streams once you have them set up. You need to take care of timeouts

> and is it good to be used for creating a HTTP server and client that can
> handle at "get" and "post" requests?

I think so. Have a look at the example servers:


> I want to build a currency conversion
> app that takes rates from the web in real time, so I need a server and
> client that can handle at least that if nothing else. Though I may need a
> client for other, more advanced things later on as well.

I think this could be done in Beast, you can make a copy of the
example client and servers and modify it from there. If you have
questions or need help feel free to open an issue in the repository, I
am very responsive.

> It's an interesting name, though. Is there any special reason behind the
> name? Just wondering.

Check the 7th answer in the FAQ :)


> By the way, are there any plans on creating a good Networking library, one
> that doesn't provide just low-level HTTP support, for putting up for
> acceptance in the Boost libraries?

Yes, but my approach is to start with the low level building blocks
and use them to assemble higher and higher level libraries. Beast is
the first step. Next we need a library to check SSL certificates
against the operating system root certificate store. Then we need a
library to calculate configured proxy settings using operating system
calls. And a URI library. With that, you can start to put together a
decent HTTP client that supports OAuth. On the server side you need
some additional things like a streaming JSON parser, MIME/form
decoder, compression codec, and a few other odds and ends.

My plan is to develop these pieces as individual libraries and build
everything up into the high level solution that you are looking for.

I believe the reason that we have not seen these good high level
solutions is because no one has taken the time to decompose the
problem into standards-worthy solutions.


Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at