Exit Zen
40
string ID 72
type: table cell
English
[path_link example/websocket/client/coro-ssl/websocket_client_coro_ssl.cpp websocket_client_coro_ssl.cpp]
105/1050 · 105
40
string ID 371
type: heading
English
Using Networking
16/160 · 16
40
string ID 186
type: heading
English
Usage
5/100 · 5
40
string ID 215
type: heading
English
Boost 1.82
10/100 · 10
40
string ID 176
type: list
English
* [link beast.ref.boost__beast__file_posix `file_posix`]
* [link beast.ref.boost__beast__file_stdio `file_stdio`]
* [link beast.ref.boost__beast__file_win32 `file_win32`]
170/1700 · 170
256
string ID 256
type: paragraph
English
}; ```
6/100 · 6
40
string ID 36
type: table cell
English
Adjusts the [@https://tools.ietf.org/html/rfc7230#section-6.1 [*Connection]] field value depending on the values of `v` and `b`. The field value is treated as [@https://tools.ietf.org/html/rfc7230#section-6.1 ['connection-option]] (rfc7230).

[itemized_list [ If `(v < 11 && b)`, then all "close" tokens present in the value are removed, and the "keep-alive" token is added to the value if it is not already present. ][ If `(v < 11 && ! b)`, then all "close" and "keep-alive" tokens present in the value are removed.

][ If `(v == 11 && b)`, then all "keep-alive" and "close" tokens present in the value are removed. ][ If `(v == 11 && ! b)`, then all "keep-alive" tokens present in the value are removed, and the "close" token is added to the value if it is not already present. ]]

If the result of adjusting the field value produces an empty string, the field is removed from the container.
893/8930 · 893
40
string ID 170
type: paragraph
English
The buffers provide different guarantees regarding the allocated memory; stable means that existing mutable and const_buffers obtained by calling `data` or `prepare`, will remain valid.
185/1850 · 185
40
string ID 287
type: paragraph
English
Now we add a requirement to the fields type: management of the corresponding string is delegated to the [*Fields] container, which can already be allocator aware and constructed with the necessary allocator parameter via the provided constructor overloads for `message`. The delegation implementation looks like this (only the response header specialization is shown): ``` /// An HTTP response header template<class Fields> struct header<false, Fields> : Fields {
463/4630 · 463
40
string ID 177
type: list
English
* Sign the Server CSR using our CA:
35/350 · 35
41
string ID 224
type: table cell
English
Input
5/100 · 5
41
string ID 72
type: table cell
English
WebSocket, C++20 coroutine
26/260 · 26
41
string ID 373
type: paragraph
English
Most library stream algorithms require a __socket__, __ssl_stream__, or other __Stream__ object that has already established communication with a remote peer. This example is provided as a reminder of how to work with sockets:
226/2260 · 226
41
string ID 188
type: paragraph
English
These examples show how to create and fill in request and response objects: Here we build an [@https://tools.ietf.org/html/rfc7231#section-4.3.1 HTTP GET] request with an empty message body:
190/1900 · 190
41
string ID 219
type: list
English
* [issue 2475] Add `error_code`s use source_location
52/520 · 52
41
string ID 259
type: paragraph
English
This declaration is quite bare-bones. We note the typical problems of most field containers:
92/920 · 92
41
string ID 224
type: heading
English
Exemplar
8/100 · 8
41
string ID 173
type: paragraph
English
Note that copies always requires a new call to `data` and `prepare`.`
69/690 · 69
312
string ID 312
type: paragraph
English
}; ```
6/100 · 6
41
string ID 179
type: paragraph
English
``` openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -copy_extensions copy -days 365 -out server.crt ```
113/1130 · 113