Exit Zen
10
string ID 21
type: table cell
English
__SyncStream__
14/140 · 14
10
string ID 16
type: table cell
English
[link beast.ref.boost__beast__http__write.overload1 [*write]]
61/610 · 61
10
string ID 64
type: paragraph
English
Servers send responses, which contain a [@https://tools.ietf.org/html/rfc7231#section-6 status-code], [@https://tools.ietf.org/html/rfc7230#section-3.1.2 reason-phrase], and [@https://tools.ietf.org/html/rfc7230#section-2.6 HTTP-version]. The reason phrase is [@https://tools.ietf.org/html/rfc7230#section-3.1.2 obsolete]: clients SHOULD ignore the reason-phrase content. Here is a response which includes a body. The special [@https://tools.ietf.org/html/rfc7230#section-3.3.2 Content-Length] field informs the remote host of the size of the body which follows.
563/5630 · 563
10
string ID 92
type: paragraph
English
The concepts __ConstBufferSequence__ and __MutableBufferSequence__ describe bidirectional ranges whose value type is convertible to `const_buffer` and `mutable_buffer` respectively. These sequences allow transacting with multiple buffers in a single function call, a technique called [@https://en.wikipedia.org/wiki/Vectored_I/O ['scatter/gather I/O]]. Buffers and buffer sequences are non-owning; copies produce shallow references and not duplicates of the underlying memory. Each of these statements declares a buffer sequence:
529/5290 · 529
10
string ID 25
type: variablelist cell
English
Parsing
7/100 · 7
10
string ID 17
type: table cell
English
[link beast.ref.boost__beast__http__response `response`]
56/560 · 56
10
string ID 55
type: list
English
* [issue 3039] Added `http::basic_fields::contains` member function
* [issue 3050] Removed dependency on Boost.Preprocessor
* [issue 3048] Removed dependency on Boost.StaticAssert
179/1790 · 179
10
string ID 44
type: list
English
* `D` denotes a dynamic buffer class.
* `a` denotes a value of type `D`.
* `c` denotes a (possibly const) value of type `D`.
* `n` denotes a value of type `std::size_t`.
* `T` denotes a type meeting the requirements for __ConstBufferSequence__.
* `U` denotes a type meeting the requirements for __MutableBufferSequence__.
321/3210 · 321
10
string ID 44
type: paragraph
English
is a network programming library previously intended for Boost but not having gone through formal review. As of this writing it still uses the Boost name, namespace, and directory structure although the project states that Boost acceptance is no longer a goal. The library is based on Boost.Asio and bills itself as ['"a collection of network related routines/implementations geared towards providing a robust cross-platform networking library"]. It cites ['"Common Message Type"] as a feature. As of the branch previous linked, it uses these declarations: ``` template <class Tag> struct basic_message {
604/6040 · 604
10
string ID 39
type: table title
English
Valid expressions
17/170 · 17
10
string ID 44
type: list
English
* `a` denotes a value of type `W`.
* `h` denotes a const value of type `header<isRequest, Fields> const&`.
* `v` denotes a possibly const value of type `Body::value_type&`.
* `ec` is a value of type [link beast.ref.boost__beast__error_code `error_code&`].
* `W<T>` is the type `boost::optional<std::pair<T, bool>>`.
315/3150 · 315
10
string ID 34
type: heading
English
SyncStream
10/100 · 10
10
string ID 21
type: table cell
English
[@https://github.com/chriskohlhoff/networking-ts-impl networking-ts-impl]
73/730 · 73
10
string ID 43
type: paragraph
English
For HTTP we model the message to maximize flexibility of implementation strategies while allowing familiar verbs such as [*`read`] and [*`write`]. The HTTP interface is further driven by the needs of the WebSocket module, as a WebSocket session requires a HTTP Upgrade handshake exchange at the start. Other design goals:
321/3210 · 321
10
string ID 22
type: table cell
English
[link beast.ref.boost__beast__websocket__stream_base__decorator `stream_base::decorator`]
89/890 · 89
10
string ID 61
type: paragraph
English
When a client receives an HTTP Upgrade response from the server indicating a successful upgrade, the caller may wish to perform additional validation on the received HTTP response message. For example, to check that the response to a basic authentication challenge is valid. To achieve this, overloads of the handshake member function allow the caller to store the received HTTP message in an output reference argument of type [link beast.ref.boost__beast__websocket__response_type `response_type`] as follows:
510/5100 · 510
10
string ID 57
type: heading
English
Invoking Teardown
17/170 · 17
10
string ID 38
type: table cell
English
`reader`
8/100 · 8
10
string ID 39
type: list
English
* `G` denotes a type meeting the requirements of [*BuffersGenerator].
* `g` denotes a value of type `G`.
* `c` denotes a possibly-const value of type `G`.
* `n` is a value of type `std::size_t`.
* `ec` is a value of type [link beast.ref.boost__beast__error_code `error_code&`].
277/2770 · 277
10
string ID 16
type: variablelist cell
English
Beast uses more than Boost.Asio, it depends on various other parts of Boost. The standalone Asio is currently farther ahead than the Boost version. Keeping Beast maintained against both versions of Asio is beyond the resources of the author at the present time. Compatibility with non-Boost libraries should not be an acceptance criteria. Beast is currently designed to be a part of Boost: nothing more, nothing less. Looking at the bigger picture, it is the author's goal to propose this library for standardization. A logical track for achieving this is as follows:

[ordered_list [ Boost library acceptance. ][ Port to the Boost.Asio version of Networking-TS (This has to wait until Boost's version of Asio is updated). ][ Wait for Networking-TS to become an official part of C++. ][ Port to the standard library versions of networking (gcc, clang, msvc). ][ Develop proposed language (This can happen concurrently with steps 3 and 4) ]]
940/9400 · 940