Re: [boost] [Beast] Questions Before Review

Subject: Re: [boost] [Beast] Questions Before Review
From: Artyom Beilis (artyom.beilis_at_[hidden])
Date: 2017-06-27 20:30:46

On Mon, Jun 26, 2017 at 12:32 AM, Vinnie Falco via Boost
<boost_at_[hidden]> wrote:
> On Sun, Jun 25, 2017 at 2:02 PM, Artyom Beilis via Boost
>> I understand that you work on base of Boost.Asio - which itself has
>> unacceptable compilation times but having for web
>> application development may be serious deal breaker for big projects.
>
> I'll note that the very first complaint during the Boost.Http review
> (2015) was that the library is not header-only.

Actually I was one of the guys who told that header only version
is bad. I still consider it a huge design flaw.

>>> Can I implement same server code for both SSL and non SSL HTTP protocol
>>> without use of templates in the class itself?
>
> If you can do it with Asio then you can do it with Beast.

I didn't see how to do it with Asio.

> Typically
> this is done with type erasure for the main template parameters which
> are 1. the stream object, 2. the buffer sequence, and 3. the
> completion handler. You can do the same with Beast, except that you
> will also need to make a commitment to one type for requests and one
> type for responses. This makes some of Beast's cool template driven
> features not work but it seems like you're okay with that tradeoff.
>

Can you provide an example?

>> Who are the potential users of the library?
>
> Beast is primarily aimed at library writers, although it frequently
> satisfies high level application developers even with its verbose
> interfaces since the alternatives are objectively worse.
>

Can you give examples of high level application users?
It was pointed that ripple uses beast. What it used for?
What is implemented using Beast?

I looked to API with thoughts of implementing some basic
things that used by http clients/servers (Very basic)...

- How do I get the query string (the thing after "?" in URL)
- Content type parsing? (see for example [1])
- Cookie - I found a constant representing a header... i.e. parsing on my.
- multipart-form data parsing? Generation? urlencode/decode?

I understand not to have high level form handling (validation, setting)
but being able to parse urlencoded string or get cookies as key/pair values
is sort of very basic thing.

If it is barely HTTP headers parser what do I need it for? Parsing
HTTP headers is quite trivial stuff. The tricky one of understanding
what is send and how to handle it.

Additional Points
---------------------

Looking over examples I noticed that the library user needs to manage
all timeouts/keep alive connections. Am I right?

>> If I need to send a simple http request to server it does not seem
>> to do simple enough job (see your FAQ) so I'll probably be better
>> with feature rich libcurl.
>
> Beast is definitely not a replacement for libcurl, and likely will
> never be.
> [snip]
> However, someone eventually is going to make a better libcurl by
> writing it on top of Beast,

Or wrapping excellent well supported and debugged library
with good C++ interface. BTW I used libcurl a lot and it
was and is the Wwiss army knife in all related to URL requests.

>> If I need to implement complex web server/service I don't have
>> cookies, sessions, forms, html?
>> ...
>> If I need to implement RESTful API do I have all stuff like URL mapping of
>> different paths to callbacks, protocol abstraction http/https
>> (basic stuff - I don't see it there correct me if I wrong)
>
> Everything you described is out of scope for Beast. I'm hopeful that
> the existence of Beast will inspire programmers to create new higher
> level libraries to solve the problems you listed in a composable and
> interoperable way.

Question?

Why should I choose to write something over beast
when there quite a lot of good solutions providing much
more (higher level interface)

I mean it feels like addresses very small niche of users that would
most likely write their own HTTP parsers  that would exactly
fit their needs.

>
>> Is it for web server developers?
>
> You can build a web server with Beast. But as you pointed out, you
> will have to either write for yourself or find in other libraries some
> important pieces like a URI parser, cookies, authentication, codecs
> for the various Content-Encoding, a multi-part/mime library, and so on
> and so forth.
>

Which basically the 99% of entire work that need to be done...

> Obviously we would all be happy if these things existed already with
> perfect C++ friendly interfaces and with composability and
> interoperability in mind but they don't. Beast is the first down
> payment on that dream.
>

Actually there are lots of...

Client side: curl/curl++, poco, QHttp
Server side: CppCMS. Wt, tntnet and more

What is important they provide way more useful stuff
besides being integrated to Boost.Asio.

I'm not telling this to discourage you I'm telling it
because Beast looks to me more like a tiny layer
above socket or an assembly language for HTTP
handling.

>> Can you please give more accurate description of who is this
>> library intended for?
>
> Its a fair question although I thought the Introduction in the
> documentation gave a pretty good idea. Its sort of a hard question to
> answer because really we have never seen a library like this before
> which is so low level so I think people just don't know what to think
> of it especially when they start comparing it to other libraries or
> applications whose descriptions include the word "HTTP"
>
> The library is intended for anyone who wants to build something
> resembling a high level library that exists today, such as Boost.Http,
> cpprestsdk, cppnetlib, CppCMS, or any of those libraries which
> implement either an HTTP client or an HTTP server. Instead of
> reinventing the HTTP protocol code from scratch Beast gives you a
> running start. It takes care of all the boring details of reading and
> writing HTTP messages so that you can write your library at a higher
> level.

As somebody who actually wrote http parser and lots of boring
details the HTTP parser was the _simplest and easiest_ thing
to implement. What I had to work hard on it?

- How to manage application life time, timeouts, errors, sync/async
io,
- How to handle huge contents in secure way (consider uploading 10GB file)
- How to parse cookies, content type etc in safe way.

And I'm not talking about basic higher level stuff like forms CSRF, security
sessions etc.

I mean HTTP itself was tiny part of the problem, the hard problems
that may interest the library/framework develop are out of Beast scope.

Regards,

   Artyom Beilis

[1] http://cppcms.com/cppcms_ref/latest/classcppcms_1_1http_1_1content__type.html