Exit Zen
9
string ID 37
type: paragraph
English
During the development of Beast the authors have studied other software packages and in particular the comments left during the Boost Review process of other packages offering similar functionality. In this section and the FAQs that follow we attempt to answer those questions that are also applicable to Beast.
311/3110 · 311
45
string ID 45
type: table cell
English
Function
8/100 · 8
9
string ID 22
type: table cell
English
This is the type of the object passed to the decorator to represent HTTP Upgrade response.
90/900 · 90
9
string ID 21
type: table cell
English
This functions returns a new buffer sequence which, when iterated, traverses the sequence which would be formed if all of the input buffer sequences were concatenated. With this routine, multiple calls to a stream's `write_some` function may be combined into one, eliminating expensive system calls.
299/2990 · 299
9
string ID 50
type: paragraph
English
The [link beast.ref.boost__beast__websocket__stream `websocket::stream`] member functions [link beast.ref.boost__beast__websocket__stream.handshake `handshake`] and [link beast.ref.boost__beast__websocket__stream.async_handshake `async_handshake`] are used to send the request with the required host and target strings. This code connects to the IP address returned from a hostname lookup, then performs the WebSocket handshake in the client role.
447/4470 · 447
9
string ID 36
type: table title
English
Valid expressions
17/170 · 17
9
string ID 17
type: table cell
English
This implementation of __File__ uses the C++ standard library facilities obtained by including `<cstdio>`.
106/1060 · 106
9
string ID 52
type: paragraph
English
When the implementation invokes the asynchronous teardown function, it always uses an invokable completion handler. It is not necessary to specify the return type customization when creating user-defined overloads of `async_teardown`.
234/2340 · 234
9
string ID 38
type: table cell
English
Determines the type of the [link beast.ref.boost__beast__http__message.body `message::body`] member.
100/1000 · 100
9
string ID 37
type: paragraph
English
In this table:
14/140 · 14
9
string ID 16
type: variablelist cell
English
"This should work with standalone-Asio!"
40/400 · 40
25
string ID 25
type: table cell
English
Description
11/110 · 11
9
string ID 37
type: paragraph
English
In this table:
14/140 · 14
9
string ID 22
type: table cell
English
This function returns the suggested timeout settings for a given role (client or server).
89/890 · 89
9
string ID 39
type: paragraph
English
The creation and operation of the __io_context__ associated with the underlying stream is left to the callers, permitting any implementation strategy including one that does not require threads for environments where threads are unavailable. Beast WebSocket itself does not use or require threads.
297/2970 · 297
9
string ID 54
type: table cell
English
[link beast.ref.boost__beast__basic_stream `basic_stream`]
58/580 · 58
9
string ID 51
type: list
English
* `S(m) == x`
13/130 · 13
9
string ID 50
type: table cell
English
Description
11/110 · 11
9
string ID 68
type: paragraph
English
Unlike regular completion handlers used in calls to asynchronous initiation functions, the control callback only needs to be set once. The callback is not reset after being called. The same callback is used for both synchronous and asynchronous reads. The callback is passive; in order to be called, a stream read operation must be active.
339/3390 · 339
9
string ID 59
type: paragraph
English
The Expect field with the value "100-continue" in a request is special. It indicates that the after sending the message header, a client desires an immediate informational response before sending the message body, which presumably may be expensive to compute or large. This behavior is described in [@https://tools.ietf.org/html/rfc7231#section-5.1.1 rfc7231 section 5.1.1]. Handling the Expect field can be implemented easily in a server by constructing a __parser__ to read the header first, then send an informational HTTP response, and finally read the body using the same parser instance. A synchronous version of this server action looks like this:
654/6540 · 654