Exit Zen
14
string ID 16
type: variablelist cell
English
The name "Boost.Http" or "Boost.WebSocket" would mislead users into believing they could perform an HTTP request on a URL or put up a WebSocket client or server in a couple of lines of code. Where would the core utilities go? Very likely it would step on the owner of Boost.Asio's toes to put things in the boost/asio directory; at the very least, it would create unrequested, additional work for the foreign repository.

"Beast" is sufficiently vague as to not suggest any particular functionality, while acting as a memorable umbrella term for a family of low level containers and algorithms. People in the know or with a need for low-level network protocol operations will have no trouble finding it, and the chances of luring a novice into a bad experience are greatly reduced. There is precedent for proper names: "Hana", "Fusion", "Phoenix", and "Spirit" come to mind. Is "Beast" really any worse than say, "mp11" for example? Beast also already has a growing body of users and attention from the open source community, the name Beast comes up in reddit posts and StackOverflow as the answer to questions about which HTTP or WebSocket library to use.
1156/11560 · 1156
14
string ID 25
type: table cell
English
[link beast.ref.boost__beast__http__response_serializer `response_serializer`]
78/780 · 78
14
string ID 64
type: paragraph
English
However, this code is correct:
30/300 · 30
14
string ID 92
type: paragraph
English
The function [@boost:/doc/html/boost_asio/reference/make_strand.html `make_strand`] returns a strand constructed from an execution context or executor. When a [@boost:/doc/html/boost_asio/reference/strand.html `net::strand`] is chosen for the stream's executor, all completion handlers which do not already have an associated executor will use the strand. This is both a notational convenience (no need for `strand::wrap` or `bind_executor` at call sites) and a measure of safety, as it is no longer possible to forget to use the strand.
537/5370 · 537
14
string ID 105
type: paragraph
English
However, a problem arises. How do we write a function which can accept an object that is either a request or a response? As written, the only obvious solution is to make the message a template type. Additional traits classes would then be needed to make sure that the passed object has a valid type which meets the requirements. These unnecessary complexities are bypassed by making each container a partial specialization: ``` /// An HTTP message template<bool isRequest, class Fields, class Body> struct message;
514/5140 · 514
14
string ID 77
type: paragraph
English
When a stream is constructed, any arguments provided to the constructor are forwarded to the next layer object's constructor. This declares a stream over a plain TCP/IP socket using an I/O context:
197/1970 · 197
14
string ID 97
type: paragraph
English
When a close frame is received by during a read operation, the implementation will automatically respond with a close frame and then shut down the underlying connection before returning. In this case, the read operation will complete with the code [link beast.ref.boost__beast__websocket__error `error::closed`]. This indicates to the caller that the connection has been closed cleanly.
386/3860 · 386
14
string ID 106
type: section title
English
HTTP Relay __example__
22/220 · 22
14
string ID 44
type: table cell
English
[link beast.ref.boost__beast__bind_front_handler `bind_front_handler`]
70/700 · 70
14
string ID 57
type: paragraph
English
Beast requires:
15/150 · 15
14
string ID 46
type: table cell
English
[link beast.ref.boost__beast__close_socket `close_socket`]
58/580 · 58
15
string ID 47
type: table cell
English
[link beast.ref.boost__beast__http__chunk_header `chunk_header`]
64/640 · 64
15
string ID 96
type: paragraph
English
The boilerplate is all done, and now we need to implement the function call operator that turns this composed operation a completion handler with the signature `void(error_code, std::size_t)` which is exactly the signature needed when performing asynchronous reads. This function is a transformation of the synchronous version of `detect_ssl` above, but with the inversion of flow that characterizes code written in the callback style:
435/4350 · 435
25
string ID 25
type: table cell
English
HTTP, coroutine
15/150 · 15
15
string ID 21
type: table cell
English
Supports buffer-oriented asynchronous writes.
45/450 · 45
103
string ID 103
type: heading
English
Special Fields
14/140 · 14
15
string ID 162
type: paragraph
English
A ['synchronous stream algorithm] is written as a function template accepting a stream object meeting the named requirements for synchronous reading, writing, or both. This example shows an algorithm which writes text and uses exceptions to indicate errors:
257/2570 · 257
15
string ID 80
type: table cell
English
At the highest level, these free functions send or receive a complete HTTP message in one call. They are designed for ease of use: [link beast.ref.boost__beast__http__read.overload4 `read`], [link beast.ref.boost__beast__http__write.overload4 `write`], [link beast.ref.boost__beast__http__async_read.overload2 `async_read`], and [link beast.ref.boost__beast__http__async_write.overload2 `async_write`].
402/4020 · 402
15
string ID 29
type: table cell
English
[link beast.ref.boost__beast__http__response_parser `response_parser`]
70/700 · 70
15
string ID 30
type: table cell
English
If present, indicates that the body can be parsed. The type must meet the requirements of __BodyReader__. The implementation constructs an object of this type to obtain buffers into which parsed body octets are placed.
218/2180 · 218