Exit Zen
12
string ID 74
type: paragraph
English
Interfaces for operating on HTTP messages are structured into several layers. The highest level provides ease of use, while lower levels provide progressively more control, options, and flexibility. At the lowest level customization points are provided, where user defined types can replace parts of the implementation. The layers are arranged thusly:
351/3510 · 351
12
string ID 51
type: paragraph
English
The container offers value semantics including move and copy if supported by __Body__ and __Fields__. User defined template function parameters can accept any message, or can use partial specialization to accept just requests or responses. The default __fields__ is a provided associative container using the standard allocator and supporting modification and inspection of fields. As per __rfc7230__, a non-case-sensitive comparison is used for field names. User defined types for fields are possible. The `Body` type determines the type of the container used to represent the body as well as the algorithms for transferring buffers to and from the container. The library comes with a collection of common body types. As with fields, user defined body types are possible.
772/7720 · 772
12
string ID 29
type: table code
English
/// An HTTP/1 parser for producing a message.
template<
bool isRequest, // `true` to parse an HTTP request
class Body, // The Body type for the resulting message
class Allocator = std::allocator<char>> // The type of allocator for the header
class parser
: public basic_parser<...>;
334/3340 · 334
12
string ID 63
type: list
English
* [issue 3002] Conditionally defined `immediate_executor_type` in `async_base`
* [issue 2999] Used `handshake_timeout` for closing handshake during read operations
* [issue 3003] Added missing `cstdint` header to `detail/cpu_info.hpp`
* [issue 3016] Fixed `std::is_trivial` deprecation warnings
* [issue 3019] Fixed `-Wmaybe-uninitialized` warnings
348/3480 · 348
12
string ID 30
type: table cell
English
`B::value_type`
15/150 · 15
12
string ID 85
type: paragraph
English
This container is the base class template used to represent HTTP messages. It uses a "tag" type style specializations for a variety of trait classes, allowing for customization of the various parts of the message. For example, a user specializes `headers_container<T>` to determine what container type holds the header fields. We note some problems with the container declaration:
380/3800 · 380
12
string ID 36
type: table cell
English
`F::writer`
11/110 · 11
12
string ID 30
type: table cell
English
[link beast.ref.boost__beast__http__basic_parser.skip.overload2 `skip`]
71/710 · 71
12
string ID 38
type: list
English
* __SyncReadStream__
* __SyncWriteStream__
42/420 · 42
12
string ID 53
type: paragraph
English
This document refers to the three implementations above interchangeably and collectively as [*Networking] (or just ['networking]). The Boost.Asio and Asio flavors of Networking provide additional features not currently proposed for C++, but likely to appear in a future specification, such as:
293/2930 · 293
12
string ID 51
type: list
English
* Stay low level; don't invent a whole web server or client.
60/600 · 60
12
string ID 45
type: table cell
English
Send a buffer sequence as a complete message.
45/450 · 45
12
string ID 22
type: table cell
English
[link beast.ref.boost__beast__websocket__stream.set_option `stream::set_option`]
80/800 · 80
12
string ID 21
type: table cell
English
[link beast.ref.boost__beast__buffers_front `buffers_front`]
60/600 · 60
12
string ID 76
type: paragraph
English
For servers accepting incoming connections, the [link beast.ref.boost__beast__websocket__stream `websocket::stream`] can read the incoming upgrade request and automatically reply. If the handshake meets the requirements, the stream sends back the upgrade response with a [@https://tools.ietf.org/html/rfc6455#section-4.2.2 ['101 Switching Protocols]] status code. If the handshake does not meet the requirements, or falls outside the range of allowed parameters specified by stream options set previously by the caller, the stream sends back an HTTP response with a status code indicating an error. Depending on the keep alive setting, the connection may remain open for a subsequent handshake attempt. A typical HTTP Upgrade response created and sent by the implementation upon receiving an upgrade request handshake will look like this:
838/8380 · 838
12
string ID 36
type: table cell
English
Semantics, Pre/Post-conditions
30/300 · 30
12
string ID 17
type: table cell
English
[link beast.ref.boost__beast__file_posix `file_posix`]
54/540 · 54
12
string ID 38
type: table cell
English
`writer`
8/100 · 8
12
string ID 16
type: variablelist cell
English
The energy invested in Beast went into the design of the interfaces, not performance. That said, the most sensitive parts of Beast have been optimized or designed with optimization in mind. The slow parts of WebSocket processing have been optimized, and the HTTP parser design is lifted from another extremely popular project which has performance as a design goal (see [@https://github.com/h2o/picohttpparser]).

From: [@http://www.boost.org/development/requirements.html]

"Aim first for clarity and correctness; optimization should be only a secondary concern in most Boost libraries."

As the library matures it will undergo optimization passes; benchmarks will logically accompany this process. There is a small benchmarking program included in the tests which compares the performance of Beast's parser to the NodeJS reference parser, as well as some benchmarks which compare the performance of various Beast dynamic buffer implementations against Asio's.
961/9610 · 961
12
string ID 25
type: table cell
English
[link beast.ref.boost__beast__http__request_serializer `request_serializer`]
76/760 · 76