2. Boost Beast Translation (zh_Hans)
3. English
4. Zen

3 string ID 16
	Source string description type: list
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — * Receive the header first and body later. 42/10000 · 42
3 string ID 32
	Source string description type: heading
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Serializing Chunks 18/10000 · 18
16 string ID 16
	Source string description type: table title
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Message Stream Operations 25/10000 · 25
3 string ID 22
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To obtain the serialized next buffer sequence, call [link beast.ref.boost__beast__http__serializer.next `serializer::next`]. Then, call [link beast.ref.boost__beast__http__serializer.consume `serializer::consume`] to indicate the number of bytes consumed. This updates the next set of buffers to be returned, if any. `serializer::next` takes an error code parameter and invokes a visitor argument with the error code and buffer of unspecified type. In C++14 this is easily expressed with a generic lambda. The function [link beast.ref.boost__beast__http__serializer.is_done `serializer::is_done`] will return `true` when all the buffers have been produced. This C++14 example prints the buffers to standard output: 714/10000 · 714
26 string ID 26
	Source string description type: heading
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Parser Options 14/10000 · 14
3 string ID 33
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — } ``` 5/10000 · 5
3 string ID 21
	Source string description type: list
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — * Inspect incoming header fields and keep or discard them. 58/10000 · 58
3 string ID 15
	Source string description type: list
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — * Send the header first, and the body later. 44/10000 · 44
3 string ID 22
	Source string description type: table title
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — WebSocket Timeout Interface 27/10000 · 27
3 string ID 16
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The implementation does not perform queueing or buffering of messages. If desired, these features should be provided by callers. The impact of this design is that library users are in full control of the allocation strategy used to store data and the back-pressure applied on the read and write side of the underlying TCP/IP connection. 336/10000 · 336
3 string ID 16
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A WebSocket session begins when a client sends the HTTP/1.1 [@https://tools.ietf.org/html/rfc7230#section-6.7 Upgrade] request for [@https://tools.ietf.org/html/rfc6455#section-1.3 WebSocket] on an established connection, and the server sends an appropriate response indicating that the request was accepted and that the connection has been upgraded. The Upgrade request must include the [@https://tools.ietf.org/html/rfc7230#section-5.4 Host] field, and the [@https://tools.ietf.org/html/rfc7230#section-5.3 target] of the resource to request. A typical HTTP Upgrade request created and sent by the implementation will look like this: 635/10000 · 635
3 string ID 22
	Source string description type: table title
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — WebSocket Decorator Interface 29/10000 · 29
3 string ID 22
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Beast provides developers with a robust WebSocket implementation built on Boost.Asio with a consistent asynchronous model using a modern C++ approach. 150/10000 · 150
3 string ID 24
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To enable the implementation to perform the shutdown components of the close operation, the library exposes two customization points expressed as free functions associated with the next layer type: 197/10000 · 197
3 string ID 23
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The boundaries between frames of a multi-frame message are not not considered part of the message. Intermediaries such as proxies which forward the websocket traffic are free to "reframe" (split frames and combine them) the message in arbitrary ways. These intermediaries include Beast, which can reframe messages automatically in some cases depending on the options set on the stream. 385/10000 · 385
3 string ID 18
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A sent ping indicates a request that the sender wants to receive a pong. A pong is a response to a ping. Pongs may be sent unsolicited, at any time. One use for an unsolicited pong is to inform the remote peer that the session is still active after a long period of inactivity. A close frame indicates that the remote peer wishes to close the WebSocket connection. The connection is considered gracefully closed when each side has sent and received a close frame. 463/10000 · 463
3 string ID 21
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To accept incoming connections, an acceptor is used. The websocket stream may be constructed from the socket returned by the acceptor when an incoming connection is established. 177/10000 · 177
3 string ID 18
	Source string description type: section title
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Change Body Type __example__ 28/10000 · 28
4 string ID 15
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — It can be obtained as a string from the `BOOST_BEAST_VERSION` macro or a string through `BOOST_BEAST_VERSION_STRING`. 117/10000 · 117
4 string ID 176
	Source string description type: section title
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Reference 9/10000 · 9