On Wed, Jul 5, 2017 at 2:31 AM, Marcel Ebmer via Boost
Here's my Review:
Thanks you!
Required message properties like method and target have to be set from outside. This makes me as a library user afraid of forgetting something vital.
message will have constructor variations for setting the header values https://github.com/vinniefalco/Beast/commit/8d677757645405295a1417b703c19f2d...
The same holds for prepare_payload(). If I forget to call prepare_payload() or forget to set one of the required message properties or fields
WebSocket control frames are automagically responded to. Iff there's an active read(). Basically, having an active read() at almost all times is a requirement of any correct program using Beast. Even though I enjoy the help from the library, and the requirement is usually met, I found this specific behaviour to be inconsequent.
What's the call to action? What change is being proposed?
There should be a utility in the library to do the draining for me.
willfix https://github.com/vinniefalco/Beast/issues/564
However, there's no apparent reason why (e.g.) request targets shouldn't be URL-decoded, and why form data should not be parsed into a map of some kind. The way I see it, none of this added funtionality would interfere with the library's design.
"out of scope": that dreaded phrase that no one wants to hear :) The features you described are arbitrary. Why forms and not basic authentication? Why URL decoding but not a full URI parser? Why a full URI parser but no handling for redirects? What about supporting proxies? Anything that I add is going to satisfy some users and disappoint others. That's why I'd like to keep Beast as it is, a low level protocol layering on top of Asio. I am carefully and strategically adding things to Beast where it makes sense. For example, based on feedback I am making file_body a public interface. Taking advantage of platform specific optimizations to send files as HTTP message payloads is most certainly in scope. Dealing with the actual content of the message, is not - subject to the caveat that Beast must understand enough of the message to reliably get it from one end to the other. That's why I could accept the argument that supporting alternate status-lines (e.g. "ICY 200 OK\r\n") should be in-scope. That doesn't mean that I won't be building new higher level features (I'm already working on a URL decoder) but I think they belong in a separate library with its own documentation, tests, CI infrastructure, and also separate Boost formal review process. Still, there's only so much I can do - HTTP is a MASSIVE domain!. The only reason I was able to get Beast to where it is at was by being strict on what features I would support. I'm hopeful that other people will build on top of Beast and propose their own new libraries to fill in these gaps. Every so often, students or interns come to the mailing list and ask how they can help. Here's an idea, port this library to modern C++ and Beast: http://www.codesink.org/mimetic_mime_library.html Thanks