Re: [boost] [Beast] Questions Before Review

Subject: Re: [boost] [Beast] Questions Before Review
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2017-07-01 19:49:30

On Sat, Jul 1, 2017 at 12:27 PM, Artyom Beilis via Boost
<boost_at_[hidden]> wrote:
> http vs WebSocket
> ...
> I noticed some strange difference in these requests :
> ...
>     ws.handshake(host, "/", ec);
> ...
> This one is fast and easy to use does all it needed

Yes. There is a bit of a difference between the WebSocket interface
versus HTTP. The scope of HTTP is limited to being a low level
protocol layering. However in the case of WebSocket, rfc6455 is
nowhere near as complex as rfc7230 (the HTTP specification). You might
find that WebSocket feels more "complete."

Even so, users have the ability to customize the WebSocket handshake
by using a decorator:

http://vinniefalco.github.io/beast/beast/ref/beast__websocket__stream/handshake_ex/overload3.html

This allows the User-Agent to be set. beast::websocket::stream only
uses a default User-Agent when the decorator does not set one, or if
the decorator is absent. So there is no performance penalty of setting
it versus not setting it.

In any event, I'm glad to see WebSocket getting some attention :)

> Now HTTP is very different story
> ...
> Most of stuff can be defined there by default: version 1.1

beast::http::message defaults to 1.1 instead of using an uninitialized
`int`. The example sets the version explicitly for expository
purposes. It is not a goal of Beast to have a compact user-facing
interface for building HTTP requests.

> Host header - required by http/1.1 why should I bother?

Beast doesn't have the information needed to fill out this field. But
even if it did, it should not be defaulted because...

> User agent put one by default unless user wants - you do all this stuff for WS handshake
> so why not there? Why so complicated?

Beast doesn't make odd choices on behalf of the user, its a low level
library. If you feel that Beast is too complicated, you can write your
own layer above it which makes choices for you that you think are
appropriate. If enough people agree with your choices, perhaps you
could publish it as a higher level library written on top of Beast!

That is my goal, for there to be competition in the marketplace of
ideas of what choices a higher level library might make (and such a
library should be written on top of Beast of course).

Even if we wanted the behavior you describe it would require that a
beast::http::message using basic_fields should allocate memory in its
constructor to set a field value. Beast follows the "pay for what you
use" principle. Users have shown overwhelming support for Beast's
style of not making these decisions on behalf of users.

Furthermore, the Beast message container can use any instance of the
Fields concept [1], including those which don't support insertion of
arbitrary strings. What would we do in that case?

Thanks

[1] http://vinniefalco.github.io/beast/beast/concept/Fields.html