Re: [boost] [beast] Review

Subject: Re: [boost] [beast] Review
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2017-07-05 14:13:41

On Wed, Jul 5, 2017 at 2:31 AM, Marcel Ebmer via Boost
<boost_at_[hidden]> wrote:
> 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/8d677757645405295a1417b703c19f2d4f71d20c>

> 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