On Mon, Jun 26, 2017 at 12:32 AM, Vinnie Falco via Boost
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.htm...