On Thu, Jul 6, 2017 at 1:32 PM, Artyom Beilis via Boost
May be there could be more hints for client/server developers. E.g. where is the best place / how is the best practice to add cookie-handling, Authentication challenges, etc.
Funnily, for someone who actually solved numerous of the issues this question can easily be rephrased as:
Now I finally learned how drive a bicycle, lets ask tips for driving semi-trailer.
And this is **the major** problem of the library.
In the CppCMS frameworks the HTTP part is less than 2.5% of the core code. The rest is the "minor" stuff like cookies, session, url parsing and much-much more. And note - I'm talking about server part only
There's no denying that "raw" HTTP is _almost_ simple before all these other "minor" things that a full-fledged server or client needs are thrown in. But I think it's important to look at the goal of the library, per the author: to enable others to write rich client and server libraries on top while it takes care of the bottom-most plumbing in the most efficient way. I think it achieves that. Hands down.
Now once you choose to use Beast you'll hit the wall very quickly as you'll have to do all tricks your own and they will consume most of your work for example URL decoding, parsing query string, parsing or generating trivial forms or handling trivial cookies. So instead of concentrating on your application issues you are going to deal with 1001 small issues that require both experience and knowledge to do them right.
The biggest problem is actually that vast majority security issues do not come from HTTP parsing at all, but rather all "minor stuff" [1] that left out of scope of the Beast.
This question you had written had popped for me the big red flag - without proper well organized tools that handle the "minor stuff" Beast users are virtually doomed to writing insecure code. Unlike most HTTP servers/clients are build with security by design - do safe stuff by default, Beast lives this ALL to end user.
This part **extremely** concerns me - as somebody who actually developed both web services and tools to make them secure and aware of unforgiving nature of WWW.
I appreciate you raising this, Artyom. Beast should be held to a high standard, especially since it's handling user-input from untrusted channels (i.e. socket buffers). So yeah, the code should be written carefully, without thorough error checks, especially around the handling of memory. Based on my informal audit of the codebase, and my interactions with Vinnie, I know that it is written carefully and am very confident that it does not contain any bugs that would compromise the security of an application built using it. With that said, I also think you're exaggerating just a little bit. I just don't think you need to be _THAT_ worried. Yes, adding full "client" or "server" support, with cookie jars, and authentication methods and tracking of origins, and who knows what else, is not for the faint of heart. Yes, some will try to implement such things themselves and they will mess it up. Spectacularly. But is that different than _any_ other library? Can't people spectacularly mess up multithreaded programming? Should we have held that against Boost.Thread? Yes, if you want a full-fledged client or server library, there are better alternatives than Beast. As Vinnie has said, Beast will never be curl, or CppCMS and it doesn't need to! The idea is to offer a robust implementation of the lowest HTTP plumbing to (a) enable robust and clean WebSocket support and (b) allow others to more quickly and easily write such full-fledged client or server libraries layered on top of Beast that are efficient without needing to worry about the bottom layer of HTTP plumbling.