Zen

Translation

type: variablelist cell
The `websocket::stream` wraps the socket or stream that you provide (for example, a `boost::asio::ip::tcp::socket` or a `boost::asio::ssl::stream`). You establish your TLS connection using the interface on `ssl::stream` like shown in all of the Asio examples, then construct your `websocket::stream` around it.

The WebSocket implementation [*does] provide support for shutting down the TLS connection through the use of the ADL compile-time virtual functions [link beast.ref.boost__beast__websocket__teardown `teardown`] and [link beast.ref.boost__beast__websocket__async_teardown `async_teardown`]. These will properly close the connection as per rfc6455 and overloads are available for TLS streams. Callers may provide their own overloads of these functions for user-defined next layer types.
795/7950 · 795

Sign in to save translations.

English Chinese (Simplified Han script) Actions
"A built-in HTTP router?"
"A built-in HTTP router?"
We presume this means a facility to match expressions against the URI in HTTP requests, and dispatch them to calling code. The authors feel that this is a responsibility of higher level code. Beast does not try to offer a web server. That said, the server-framework example has a concept of request routing called a Service. Two services are provided, one for serving files and the other for handling WebSocket upgrade requests.
We presume this means a facility to match expressions against the URI in HTTP requests, and dispatch them to calling code. The authors feel that this is a responsibility of higher level code. Beast does not try to offer a web server. That said, the server-framework example has a concept of request routing called a Service. Two services are provided, one for serving files and the other for handling WebSocket upgrade requests.
"HTTP Cookies? Forms/File Uploads?"
"HTTP Cookies? Forms/File Uploads?"
Cookies, or managing these types of HTTP headers in general, is the responsibility of higher levels. Beast just tries to get complete messages to and from the calling code. It deals in the HTTP headers just enough to process the message body and leaves the rest to callers. However, for forms and file uploads the symmetric interface of the message class allows HTTP requests to include arbitrary body types including those needed to upload a file or fill out a form.
Cookies, or managing these types of HTTP headers in general, is the responsibility of higher levels. Beast just tries to get complete messages to and from the calling code. It deals in the HTTP headers just enough to process the message body and leaves the rest to callers. However, for forms and file uploads the symmetric interface of the message class allows HTTP requests to include arbitrary body types including those needed to upload a file or fill out a form.
"...supporting TLS (is this a feature? If not this would be a show-stopper), etc."
"...supporting TLS (is this a feature? If not this would be a show-stopper), etc."
Beast works with the Stream concept, so it automatically works with the `boost::asio::ssl::stream` that you have already set up through Asio.
Beast works with the Stream concept, so it automatically works with the `boost::asio::ssl::stream` that you have already set up through Asio.
"There should also be more examples of how to integrate the http service with getting files from the file system, generating responses CGI-style"
"There should also be more examples of how to integrate the http service with getting files from the file system, generating responses CGI-style"
The design goal for the library is to not try to invent a web server. We feel that there is a strong need for a basic implementation that models the HTTP message and provides functions to send and receive them over Asio. Such an implementation should serve as a building block upon which higher abstractions such as the aforementioned HTTP service or cgi-gateway can be built.

There are several HTTP servers in the example directory which deliver files, as well as some tested and compiled code snippets which can be used as a starting point for interfacing with other processes.
The design goal for the library is to not try to invent a web server. We feel that there is a strong need for a basic implementation that models the HTTP message and provides functions to send and receive them over Asio. Such an implementation should serve as a building block upon which higher abstractions such as the aforementioned HTTP service or cgi-gateway can be built.

There are several HTTP servers in the example directory which deliver files, as well as some tested and compiled code snippets which can be used as a starting point for interfacing with other processes.
"You should send a 100-continue to ask for the rest of the body if required."
"You should send a 100-continue to ask for the rest of the body if required."
Deciding on whether to send the "Expect: 100-continue" header or how to handle it on the server side is the caller's responsibility; Beast provides the functionality to send or inspect the header before sending or reading the body.
Deciding on whether to send the "Expect: 100-continue" header or how to handle it on the server side is the caller's responsibility; Beast provides the functionality to send or inspect the header before sending or reading the body.
"I would also like to see instances of this library being used in production. That would give some evidence that the design works in practice."
"I would also like to see instances of this library being used in production. That would give some evidence that the design works in practice."
Beast has already been on public servers receiving traffic and handling hundreds of millions of dollars' worth of financial transactions daily. The servers run [*rippled], open source software ([@https://github.com/ripple/rippled repository]) implementing the [@https://ripple.com/files/ripple_consensus_whitepaper.pdf [*Ripple Consensus Protocol]], technology provided by [@http://ripple.com Ripple].

Furthermore, the repository has grown significantly in popularity in 2017. There are many users, and some of them participate directly in the repository by reporting issues, performing testing, and in some cases submitting pull requests with code contributions.
Beast has already been on public servers receiving traffic and handling hundreds of millions of dollars' worth of financial transactions daily. The servers run [*rippled], open source software ([@https://github.com/ripple/rippled repository]) implementing the [@https://ripple.com/files/ripple_consensus_whitepaper.pdf [*Ripple Consensus Protocol]], technology provided by [@http://ripple.com Ripple].

Furthermore, the repository has grown significantly in popularity in 2017. There are many users, and some of them participate directly in the repository by reporting issues, performing testing, and in some cases submitting pull requests with code contributions.
What about WebSocket message compression?
What about WebSocket message compression?
Beast WebSocket supports the permessage-deflate extension described in [@https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-00 draft-ietf-hybi-permessage-compression-00]. The library comes with a header-only, C++11 port of ZLib's "deflate" codec used in the implementation of the permessage-deflate extension.
Beast WebSocket supports the permessage-deflate extension described in [@https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-00 draft-ietf-hybi-permessage-compression-00]. The library comes with a header-only, C++11 port of ZLib's "deflate" codec used in the implementation of the permessage-deflate extension.
Where is the WebSocket TLS/SSL interface?
Where is the WebSocket TLS/SSL interface?
The `websocket::stream` wraps the socket or stream that you provide (for example, a `boost::asio::ip::tcp::socket` or a `boost::asio::ssl::stream`). You establish your TLS connection using the interface on `ssl::stream` like shown in all of the Asio examples, then construct your `websocket::stream` around it.

The WebSocket implementation [*does] provide support for shutting down the TLS connection through the use of the ADL compile-time virtual functions [link beast.ref.boost__beast__websocket__teardown `teardown`] and [link beast.ref.boost__beast__websocket__async_teardown `async_teardown`]. These will properly close the connection as per rfc6455 and overloads are available for TLS streams. Callers may provide their own overloads of these functions for user-defined next layer types.
The `websocket::stream` wraps the socket or stream that you provide (for example, a `boost::asio::ip::tcp::socket` or a `boost::asio::ssl::stream`). You establish your TLS connection using the interface on `ssl::stream` like shown in all of the Asio examples, then construct your `websocket::stream` around it.

The WebSocket implementation [*does] provide support for shutting down the TLS connection through the use of the ADL compile-time virtual functions [link beast.ref.boost__beast__websocket__teardown `teardown`] and [link beast.ref.boost__beast__websocket__async_teardown `async_teardown`]. These will properly close the connection as per rfc6455 and overloads are available for TLS streams. Callers may provide their own overloads of these functions for user-defined next layer types.
Windows and OpenSSL: How do I install and build with OpenSSL on Microsoft Windows?
Windows and OpenSSL: How do I install and build with OpenSSL on Microsoft Windows?
An easy method is to use command-line package installers chocolatey or scoop. Examples: "choco install -y openssl --x86 --version 1.1.1.700" or "scoop install openssl@1.1.1g -a 32bit -g"

If you've installed OpenSSL to a directory with spaces in the name, it's often preferable to create a symbolic link so that you may use a simpler path, such as:

mklink /D "OpenSSL" "Program Files (x86)\\OpenSSL-Win32"

Set the environment variable OPENSSL_ROOT to the location of the new install:

set OPENSSL_ROOT=C:/OpenSSL

Then, proceed to build. Refer to beast/.dockers/windows-vs-32/Dockerfile for an example of building the test cases with OpenSSL.
An easy method is to use command-line package installers chocolatey or scoop. Examples: "choco install -y openssl --x86 --version 1.1.1.700" or "scoop install openssl@1.1.1g -a 32bit -g"

If you've installed OpenSSL to a directory with spaces in the name, it's often preferable to create a symbolic link so that you may use a simpler path, such as:

mklink /D "OpenSSL" "Program Files (x86)\\OpenSSL-Win32"

Set the environment variable OPENSSL_ROOT to the location of the new install:

set OPENSSL_ROOT=C:/OpenSSL

Then, proceed to build. Refer to beast/.dockers/windows-vs-32/Dockerfile for an example of building the test cases with OpenSSL.
English Chinese (Simplified Han script) Actions
The server-framework example demonstrates how to implement a server that supports TLS using certificates. There are also websocket and HTTP client examples which use TLS. Furthermore, management of certificates is beyond the scope of the public interfaces of the library. Asio already provides documentation, interfaces, and examples for performing these tasks - Beast does not intend to reinvent them or to redundantly provide this information.
The server-framework example demonstrates how to implement a server that supports TLS using certificates. There are also websocket and HTTP client examples which use TLS. Furthermore, management of certificates is beyond the scope of the public interfaces of the library. Asio already provides documentation, interfaces, and examples for performing these tasks - Beast does not intend to reinvent them or to redundantly provide this information.
"A built-in HTTP router?"
"A built-in HTTP router?"
We presume this means a facility to match expressions against the URI in HTTP requests, and dispatch them to calling code. The authors feel that this is a responsibility of higher level code. Beast does not try to offer a web server. That said, the server-framework example has a concept of request routing called a Service. Two services are provided, one for serving files and the other for handling WebSocket upgrade requests.
We presume this means a facility to match expressions against the URI in HTTP requests, and dispatch them to calling code. The authors feel that this is a responsibility of higher level code. Beast does not try to offer a web server. That said, the server-framework example has a concept of request routing called a Service. Two services are provided, one for serving files and the other for handling WebSocket upgrade requests.
"HTTP Cookies? Forms/File Uploads?"
"HTTP Cookies? Forms/File Uploads?"
Cookies, or managing these types of HTTP headers in general, is the responsibility of higher levels. Beast just tries to get complete messages to and from the calling code. It deals in the HTTP headers just enough to process the message body and leaves the rest to callers. However, for forms and file uploads the symmetric interface of the message class allows HTTP requests to include arbitrary body types including those needed to upload a file or fill out a form.
Cookies, or managing these types of HTTP headers in general, is the responsibility of higher levels. Beast just tries to get complete messages to and from the calling code. It deals in the HTTP headers just enough to process the message body and leaves the rest to callers. However, for forms and file uploads the symmetric interface of the message class allows HTTP requests to include arbitrary body types including those needed to upload a file or fill out a form.
"...supporting TLS (is this a feature? If not this would be a show-stopper), etc."
"...supporting TLS (is this a feature? If not this would be a show-stopper), etc."
Beast works with the Stream concept, so it automatically works with the `boost::asio::ssl::stream` that you have already set up through Asio.
Beast works with the Stream concept, so it automatically works with the `boost::asio::ssl::stream` that you have already set up through Asio.
"There should also be more examples of how to integrate the http service with getting files from the file system, generating responses CGI-style"
"There should also be more examples of how to integrate the http service with getting files from the file system, generating responses CGI-style"
The design goal for the library is to not try to invent a web server. We feel that there is a strong need for a basic implementation that models the HTTP message and provides functions to send and receive them over Asio. Such an implementation should serve as a building block upon which higher abstractions such as the aforementioned HTTP service or cgi-gateway can be built.

There are several HTTP servers in the example directory which deliver files, as well as some tested and compiled code snippets which can be used as a starting point for interfacing with other processes.
The design goal for the library is to not try to invent a web server. We feel that there is a strong need for a basic implementation that models the HTTP message and provides functions to send and receive them over Asio. Such an implementation should serve as a building block upon which higher abstractions such as the aforementioned HTTP service or cgi-gateway can be built.

There are several HTTP servers in the example directory which deliver files, as well as some tested and compiled code snippets which can be used as a starting point for interfacing with other processes.
"You should send a 100-continue to ask for the rest of the body if required."
"You should send a 100-continue to ask for the rest of the body if required."
Deciding on whether to send the "Expect: 100-continue" header or how to handle it on the server side is the caller's responsibility; Beast provides the functionality to send or inspect the header before sending or reading the body.
Deciding on whether to send the "Expect: 100-continue" header or how to handle it on the server side is the caller's responsibility; Beast provides the functionality to send or inspect the header before sending or reading the body.
Beast has already been on public servers receiving traffic and handling hundreds of millions of dollars' worth of financial transactions daily. The servers run [*rippled], open source software ([@https://github.com/ripple/rippled repository]) implementing the [@https://ripple.com/files/ripple_consensus_whitepaper.pdf [*Ripple Consensus Protocol]], technology provided by [@http://ripple.com Ripple].

Furthermore, the repository has grown significantly in popularity in 2017. There are many users, and some of them participate directly in the repository by reporting issues, performing testing, and in some cases submitting pull requests with code contributions.
Beast has already been on public servers receiving traffic and handling hundreds of millions of dollars' worth of financial transactions daily. The servers run [*rippled], open source software ([@https://github.com/ripple/rippled repository]) implementing the [@https://ripple.com/files/ripple_consensus_whitepaper.pdf [*Ripple Consensus Protocol]], technology provided by [@http://ripple.com Ripple].

Furthermore, the repository has grown significantly in popularity in 2017. There are many users, and some of them participate directly in the repository by reporting issues, performing testing, and in some cases submitting pull requests with code contributions.
What about WebSocket message compression?
What about WebSocket message compression?
Beast WebSocket supports the permessage-deflate extension described in [@https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-00 draft-ietf-hybi-permessage-compression-00]. The library comes with a header-only, C++11 port of ZLib's "deflate" codec used in the implementation of the permessage-deflate extension.
Beast WebSocket supports the permessage-deflate extension described in [@https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-00 draft-ietf-hybi-permessage-compression-00]. The library comes with a header-only, C++11 port of ZLib's "deflate" codec used in the implementation of the permessage-deflate extension.
Where is the WebSocket TLS/SSL interface?
Where is the WebSocket TLS/SSL interface?
The `websocket::stream` wraps the socket or stream that you provide (for example, a `boost::asio::ip::tcp::socket` or a `boost::asio::ssl::stream`). You establish your TLS connection using the interface on `ssl::stream` like shown in all of the Asio examples, then construct your `websocket::stream` around it.

The WebSocket implementation [*does] provide support for shutting down the TLS connection through the use of the ADL compile-time virtual functions [link beast.ref.boost__beast__websocket__teardown `teardown`] and [link beast.ref.boost__beast__websocket__async_teardown `async_teardown`]. These will properly close the connection as per rfc6455 and overloads are available for TLS streams. Callers may provide their own overloads of these functions for user-defined next layer types.
The `websocket::stream` wraps the socket or stream that you provide (for example, a `boost::asio::ip::tcp::socket` or a `boost::asio::ssl::stream`). You establish your TLS connection using the interface on `ssl::stream` like shown in all of the Asio examples, then construct your `websocket::stream` around it.

The WebSocket implementation [*does] provide support for shutting down the TLS connection through the use of the ADL compile-time virtual functions [link beast.ref.boost__beast__websocket__teardown `teardown`] and [link beast.ref.boost__beast__websocket__async_teardown `async_teardown`]. These will properly close the connection as per rfc6455 and overloads are available for TLS streams. Callers may provide their own overloads of these functions for user-defined next layer types.
Windows and OpenSSL: How do I install and build with OpenSSL on Microsoft Windows?
Windows and OpenSSL: How do I install and build with OpenSSL on Microsoft Windows?
An easy method is to use command-line package installers chocolatey or scoop. Examples: "choco install -y openssl --x86 --version 1.1.1.700" or "scoop install openssl@1.1.1g -a 32bit -g"

If you've installed OpenSSL to a directory with spaces in the name, it's often preferable to create a symbolic link so that you may use a simpler path, such as:

mklink /D "OpenSSL" "Program Files (x86)\\OpenSSL-Win32"

Set the environment variable OPENSSL_ROOT to the location of the new install:

set OPENSSL_ROOT=C:/OpenSSL

Then, proceed to build. Refer to beast/.dockers/windows-vs-32/Dockerfile for an example of building the test cases with OpenSSL.
An easy method is to use command-line package installers chocolatey or scoop. Examples: "choco install -y openssl --x86 --version 1.1.1.700" or "scoop install openssl@1.1.1g -a 32bit -g"

If you've installed OpenSSL to a directory with spaces in the name, it's often preferable to create a symbolic link so that you may use a simpler path, such as:

mklink /D "OpenSSL" "Program Files (x86)\\OpenSSL-Win32"

Set the environment variable OPENSSL_ROOT to the location of the new install:

set OPENSSL_ROOT=C:/OpenSSL

Then, proceed to build. Refer to beast/.dockers/windows-vs-32/Dockerfile for an example of building the test cases with OpenSSL.

Loading…

User avatar admin

String added in the repository
The `websocket::stream` wraps the socket or stream that you provide (for example, a `boost::asio::ip::tcp::socket` or a `boost::asio::ssl::stream`). You establish your TLS connection using the interface on `ssl::stream` like shown in all of the Asio examples, then construct your `websocket::stream` around it.

The WebSocket implementation [*does] provide support for shutting down the TLS connection through the use of the ADL compile-time virtual functions [link beast.ref.boost__beast__websocket__teardown `teardown`] and [link beast.ref.boost__beast__websocket__async_teardown `async_teardown`]. These will properly close the connection as per rfc6455 and overloads are available for TLS streams. Callers may provide their own overloads of these functions for user-defined next layer types.
The `websocket::stream` wraps the socket or stream that you provide (for example, a `boost::asio::ip::tcp::socket` or a `boost::asio::ssl::stream`). You establish your TLS connection using the interface on `ssl::stream` like shown in all of the Asio examples, then construct your `websocket::stream` around it.

The WebSocket implementation [*does] provide support for shutting down the TLS connection through the use of the ADL compile-time virtual functions [link beast.ref.boost__beast__websocket__teardown `teardown`] and [link beast.ref.boost__beast__websocket__async_teardown `async_teardown`]. These will properly close the connection as per rfc6455 and overloads are available for TLS streams. Callers may provide their own overloads of these functions for user-defined next layer types.
06/05/2026
Browse all string changes

Things to check

Unchanged translation

Source and translation are identical.

Reset

Glossary

English Chinese (Simplified Han script)
No related strings found in the glossary.

String information

Source string description
type: variablelist cell
Unit identifier
59160
Source string location
string ID 16
String age
06/05/2026
Last updated
06/05/2026
Source string age
06/05/2026
Translation file QuickBook file
doc/qbk/08_design/4_faq_zh_Hans.qbk, string 32