Re: [boost] [Beast] Questions Before Review
http vs WebSocket -------------------------- I noticed some strange difference in these requests : // Wrap the now-connected socket in a websocket stream websocket::streamtcp::socket& ws{sock}; // Perform the websocket handhskae ws.handshake(host, "/", ec); if(ec) return fail("handshake", ec); This one is fast and easy to use does all it needed Now HTTP is very different story http::requesthttp::string_body req; req.method(http::verb::get); req.target("/"); req.version = 11; req.set(http::field::host, host + ":" + std::to_string(sock.remote_endpoint().port())); req.set(http::field::user_agent, BEAST_VERSION_STRING); req.prepare_payload(); Most of stuff can be defined there by default: version 1.1, Host header - required by http/1.1 why should I bother? User agent put one by default unless user wants - you do all this stuff for WS handshake so why not there? Why so complicated? ----------------- Protocol Premier HTTP/1.1 example without host. Your example isn't valid HTTP /1.1 request. HTTP /1.1 unlike 1.0 requires host header Artyom
On Sat, Jul 1, 2017 at 12:27 PM, Artyom Beilis via Boost
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/handsh... 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
In any event, I'm glad to see WebSocket getting some attention :) I assume it is because despite the hipe around WS they are far less useful in reality for one simple reason - they aren't HTTP. I consider server sent events as far better solution for server side push from both client and server side, see 1 below. WS virtually never work with proxies well and require https to work properly. Especially today when SSL inspection becoming common WS are quite problematic. On the bright side it looks like WS part of beast is far more useful than HTTP one. Artyom Beilis 1: blog.cppcms.com/post/107
On Sat, Jul 1, 2017 at 1:29 PM, Artyom Beilis via Boost
1: blog.cppcms.com/post/107
On Sat, Jul 1, 2017 at 1:29 PM, Artyom Beilis via Boost
1: blog.cppcms.com/post/107
https://www.html5rocks.com/en/tutorials/eventsource/basics/ Message was cut off, sorry about that. Anyway, Beast is not limited to just web servers serving web content. WebSockets are very useful when you want a two-way channel such as for games. I'll note you did not address that use-case in your CppCMS blog post and intstead listed the common example of stock quotes, which are one-way.
participants (2)
-
Artyom Beilis -
Vinnie Falco