Boost Beast Translation (zh_Hans)/Doc / Qbk / 06 Websocket / 02 Handshaking (qbk) — Chinese (Simplified Han script) @ Boost-Weblate: In this example, the server reads the initial HTTP request …

Zen

Translation

Source string description

type: paragraph

English

Chinese (Simplified Han script)

Needs editing (Needs rewriting)

Skip

Loading…

admin

String added in the repository

English

Chinese (Simplified Han script) 154 characters editedCurrent translationState: Needs editing (Needs rewriting)

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: paragraph

Unit identifier

59007

Source string location

string ID 126

String age

06/05/2026

Last updated

06/05/2026

Source string age

06/05/2026

Translation file QuickBook file

doc/qbk/06_websocket/02_handshaking_zh_Hans.qbk, string 21

Shortcut	Action
`?`	Open available keyboard shortcuts.
`Alt` + `Home`	Navigate to the first translation in the current search.
`Alt` + `End`	Navigate to the last translation in the current search.
`Alt` + `PageUp` or `Ctrl` + `↑` or `Alt` + `↑` or `Cmd` + `↑` or	Navigate to the previous translation in the current search.
`Alt` + `PageDown` or `Ctrl` + `↓` or `Alt` + `↓` or `Cmd` + `↓` or	Navigate to the next translation in the current search.
`Ctrl` + `Enter` or `Cmd` + `Enter`	Submit current form; this works the same as pressing Save and continue while editing translation.
`Ctrl` + `Shift` + `Enter` or `Cmd` + `Shift` +`Enter`	Unmark translation as Needing edit and submit it.
`Alt` + `Enter` or `Option` + `Enter`	Submit the string as a suggestion; this works the same as pressing Suggest while editing translation.
`Ctrl` + `E` or `Cmd` + `E`	Focus on translation editor.
`Ctrl` + `U` or `Cmd` + `U`	Focus on comment editor.
`Ctrl` + `M` or `Cmd` + `M`	Shows Automatic suggestions tab.
`Ctrl` + `1` to `Ctrl` + `9` or `Cmd` + `1` to `Cmd` + `9`	Copies placeable of a given number from source string.
`Ctrl` + `M` followed by `1` to `9` or `Cmd` + `M` followed by `1` to `9`	Copy the machine translation of a given number to current translation.
`Ctrl` + `I` followed by `1` to `9` or `Cmd` + `I` followed by `1` to `9`	Ignore one item in the list of failing checks.
`Ctrl` + `J` or `Cmd` + `J`	Shows the Nearby strings tab.
`Ctrl` + `S` or `Cmd` + `S`	Focus on search field.
`Ctrl` + `O` or `Cmd` + `O`	Copy the source string.
`Ctrl` + `Y` or `Cmd` + `Y`	Toggle the Needs editing checkbox.
`→`	Browse the next translation string.
`←`	Browse the previous translation string.

Key	English	Chinese (Simplified Han script)
30	Description	Description
	GET / HTTP/1.1 Host: www.example.com Upgrade: websocket Connection: upgrade Sec-WebSocket-Key: 2pGeTR0DsE4dfZs2pH+8MA== Sec-WebSocket-Version: 13 User-Agent: Boost.Beast/216	GET / HTTP/1.1 Host: www.example.com Upgrade: websocket Connection: upgrade Sec-WebSocket-Key: 2pGeTR0DsE4dfZs2pH+8MA== Sec-WebSocket-Version: 13 User-Agent: Boost.Beast/216
	The host and target parameters become part of the Host field and request-target in the resulting HTTP request. The key is generated by the implementation. Callers who wish to add, modify, or inspect fields may set the ['decorator] option on the stream (described later).	The host and target parameters become part of the Host field and request-target in the resulting HTTP request. The key is generated by the implementation. Callers who wish to add, modify, or inspect fields may set the ['decorator] option on the stream (described later).
	The [link beast.ref.boost__beast__websocket__stream `websocket::stream`] member functions [link beast.ref.boost__beast__websocket__stream.handshake `handshake`] and [link beast.ref.boost__beast__websocket__stream.async_handshake `async_handshake`] are used to send the request with the required host and target strings. This code connects to the IP address returned from a hostname lookup, then performs the WebSocket handshake in the client role.	The [link beast.ref.boost__beast__websocket__stream `websocket::stream`] member functions [link beast.ref.boost__beast__websocket__stream.handshake `handshake`] and [link beast.ref.boost__beast__websocket__stream.async_handshake `async_handshake`] are used to send the request with the required host and target strings. This code connects to the IP address returned from a hostname lookup, then performs the WebSocket handshake in the client role.
	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:	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:
	Server Role	Server Role
	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:	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:
	WebSocket Upgrade HTTP Response	WebSocket Upgrade HTTP Response
89	Wire Format	Wire Format
89	Description	Description
	HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Server: Boost.Beast	HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Server: Boost.Beast
	The [@https://tools.ietf.org/html/rfc6455#section-11.3.3 ['Sec-WebSocket-Accept]] field value is generated from the request in a fashion specified by the WebSocket protocol.	The [@https://tools.ietf.org/html/rfc6455#section-11.3.3 ['Sec-WebSocket-Accept]] field value is generated from the request in a fashion specified by the WebSocket protocol.
	The [link beast.ref.boost__beast__websocket__stream `stream`] member functions [link beast.ref.boost__beast__websocket__stream.accept `accept`] and [link beast.ref.boost__beast__websocket__stream.async_accept `async_accept`] are used to read the WebSocket HTTP Upgrade request handshake from a stream already connected to an incoming peer, and then send the WebSocket HTTP Upgrade response, as shown:	The [link beast.ref.boost__beast__websocket__stream `stream`] member functions [link beast.ref.boost__beast__websocket__stream.accept `accept`] and [link beast.ref.boost__beast__websocket__stream.async_accept `async_accept`] are used to read the WebSocket HTTP Upgrade request handshake from a stream already connected to an incoming peer, and then send the WebSocket HTTP Upgrade response, as shown:
	Handshake Buffering	Handshake Buffering
	It is possible for servers to read data from the stream and decide later that the buffered bytes should be interpreted as a WebSocket upgrade request. To address this usage, overloads of [link beast.ref.boost__beast__websocket__stream.accept `accept`] and [link beast.ref.boost__beast__websocket__stream.async_accept `async_accept`] which accept an additional buffer sequence parameter are provided.	It is possible for servers to read data from the stream and decide later that the buffered bytes should be interpreted as a WebSocket upgrade request. To address this usage, overloads of [link beast.ref.boost__beast__websocket__stream.accept `accept`] and [link beast.ref.boost__beast__websocket__stream.async_accept `async_accept`] which accept an additional buffer sequence parameter are provided.
	In this example, the server reads the initial HTTP request header into a dynamic buffer, then later uses the buffered data to attempt a websocket upgrade.	In this example, the server reads the initial HTTP request header into a dynamic buffer, then later uses the buffered data to attempt a websocket upgrade.
	Inspecting HTTP Requests	Inspecting HTTP Requests
	When implementing an HTTP server that also supports WebSocket, the server usually reads the HTTP request from the client. To detect when the incoming HTTP request is a WebSocket Upgrade request, the function [link beast.ref.boost__beast__websocket__is_upgrade `is_upgrade`] may be used.	When implementing an HTTP server that also supports WebSocket, the server usually reads the HTTP request from the client. To detect when the incoming HTTP request is a WebSocket Upgrade request, the function [link beast.ref.boost__beast__websocket__is_upgrade `is_upgrade`] may be used.
	Once the caller determines that the HTTP request is a WebSocket Upgrade, additional overloads of [link beast.ref.boost__beast__websocket__stream.accept `accept`] and [link beast.ref.boost__beast__websocket__stream.async_accept `async_accept`] are provided which receive the entire HTTP request header as an object to perform the handshake. By reading the request manually, the program can handle normal HTTP requests as well as upgrades. The program may also enforce policies based on the HTTP fields, such as Basic Authentication. In this example, the request is first read in using the HTTP algorithms, and then passed to a newly constructed stream:	Once the caller determines that the HTTP request is a WebSocket Upgrade, additional overloads of [link beast.ref.boost__beast__websocket__stream.accept `accept`] and [link beast.ref.boost__beast__websocket__stream.async_accept `async_accept`] are provided which receive the entire HTTP request header as an object to perform the handshake. By reading the request manually, the program can handle normal HTTP requests as well as upgrades. The program may also enforce policies based on the HTTP fields, such as Basic Authentication. In this example, the request is first read in using the HTTP algorithms, and then passed to a newly constructed stream:
	Subprotocols	Subprotocols
	The WebSocket protocol understands the concept of subprotocols. If the client is requesting one of a set of subprotocols it will set the header [@https://tools.ietf.org/html/rfc6455#section-11.3.4 Sec-WebSocket-Protocol] in the initial WebSocket Upgrade HTTP request. It is up to the server to parse the header and select one of the protocols to accept. The server indicates the selected protocol by setting the [@https://tools.ietf.org/html/rfc6455#section-11.3.4 Sec-WebSocket-Protocol] header in the accept header.	The WebSocket protocol understands the concept of subprotocols. If the client is requesting one of a set of subprotocols it will set the header [@https://tools.ietf.org/html/rfc6455#section-11.3.4 Sec-WebSocket-Protocol] in the initial WebSocket Upgrade HTTP request. It is up to the server to parse the header and select one of the protocols to accept. The server indicates the selected protocol by setting the [@https://tools.ietf.org/html/rfc6455#section-11.3.4 Sec-WebSocket-Protocol] header in the accept header.
	This is accomplished with a [link beast.ref.boost__beast__websocket__stream_base__decorator `decorator`].	This is accomplished with a [link beast.ref.boost__beast__websocket__stream_base__decorator `decorator`].
	The code that follows demonstrates how a server reads an HTTP request, identifies it as a WebSocket Upgrade, and then checks for a preferred matching subprotocol before performing the WebSocket handshake:	The code that follows demonstrates how a server reads an HTTP request, identifies it as a WebSocket Upgrade, and then checks for a preferred matching subprotocol before performing the WebSocket handshake:

Key	English	Chinese (Simplified Han script)
	The code that follows demonstrates how a server reads an HTTP request, identifies it as a WebSocket Upgrade, and then checks for a preferred matching subprotocol before performing the WebSocket handshake:	The code that follows demonstrates how a server reads an HTTP request, identifies it as a WebSocket Upgrade, and then checks for a preferred matching subprotocol before performing the WebSocket handshake:
	WebSocket HTTP Upgrade Request	WebSocket HTTP Upgrade Request
	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:	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:
	GET / HTTP/1.1 Host: www.example.com Upgrade: websocket Connection: upgrade Sec-WebSocket-Key: 2pGeTR0DsE4dfZs2pH+8MA== Sec-WebSocket-Version: 13 User-Agent: Boost.Beast/216	GET / HTTP/1.1 Host: www.example.com Upgrade: websocket Connection: upgrade Sec-WebSocket-Key: 2pGeTR0DsE4dfZs2pH+8MA== Sec-WebSocket-Version: 13 User-Agent: Boost.Beast/216
	The host and target parameters become part of the Host field and request-target in the resulting HTTP request. The key is generated by the implementation. Callers who wish to add, modify, or inspect fields may set the ['decorator] option on the stream (described later).	The host and target parameters become part of the Host field and request-target in the resulting HTTP request. The key is generated by the implementation. Callers who wish to add, modify, or inspect fields may set the ['decorator] option on the stream (described later).
	Handshaking	Handshaking
	Client Role	Client Role
	In this example, the server reads the initial HTTP request header into a dynamic buffer, then later uses the buffered data to attempt a websocket upgrade.	In this example, the server reads the initial HTTP request header into a dynamic buffer, then later uses the buffered data to attempt a websocket upgrade.
	Inspecting HTTP Requests	Inspecting HTTP Requests
	When implementing an HTTP server that also supports WebSocket, the server usually reads the HTTP request from the client. To detect when the incoming HTTP request is a WebSocket Upgrade request, the function [link beast.ref.boost__beast__websocket__is_upgrade `is_upgrade`] may be used.	When implementing an HTTP server that also supports WebSocket, the server usually reads the HTTP request from the client. To detect when the incoming HTTP request is a WebSocket Upgrade request, the function [link beast.ref.boost__beast__websocket__is_upgrade `is_upgrade`] may be used.
	The [link beast.ref.boost__beast__websocket__stream `websocket::stream`] member functions [link beast.ref.boost__beast__websocket__stream.handshake `handshake`] and [link beast.ref.boost__beast__websocket__stream.async_handshake `async_handshake`] are used to send the request with the required host and target strings. This code connects to the IP address returned from a hostname lookup, then performs the WebSocket handshake in the client role.	The [link beast.ref.boost__beast__websocket__stream `websocket::stream`] member functions [link beast.ref.boost__beast__websocket__stream.handshake `handshake`] and [link beast.ref.boost__beast__websocket__stream.async_handshake `async_handshake`] are used to send the request with the required host and target strings. This code connects to the IP address returned from a hostname lookup, then performs the WebSocket handshake in the client role.
	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:	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:
	Server Role	Server Role
	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:	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:
	WebSocket Upgrade HTTP Response	WebSocket Upgrade HTTP Response
	HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Server: Boost.Beast	HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Server: Boost.Beast
	The [@https://tools.ietf.org/html/rfc6455#section-11.3.3 ['Sec-WebSocket-Accept]] field value is generated from the request in a fashion specified by the WebSocket protocol.	The [@https://tools.ietf.org/html/rfc6455#section-11.3.3 ['Sec-WebSocket-Accept]] field value is generated from the request in a fashion specified by the WebSocket protocol.
	The [link beast.ref.boost__beast__websocket__stream `stream`] member functions [link beast.ref.boost__beast__websocket__stream.accept `accept`] and [link beast.ref.boost__beast__websocket__stream.async_accept `async_accept`] are used to read the WebSocket HTTP Upgrade request handshake from a stream already connected to an incoming peer, and then send the WebSocket HTTP Upgrade response, as shown:	The [link beast.ref.boost__beast__websocket__stream `stream`] member functions [link beast.ref.boost__beast__websocket__stream.accept `accept`] and [link beast.ref.boost__beast__websocket__stream.async_accept `async_accept`] are used to read the WebSocket HTTP Upgrade request handshake from a stream already connected to an incoming peer, and then send the WebSocket HTTP Upgrade response, as shown:
	Handshake Buffering	Handshake Buffering
	It is possible for servers to read data from the stream and decide later that the buffered bytes should be interpreted as a WebSocket upgrade request. To address this usage, overloads of [link beast.ref.boost__beast__websocket__stream.accept `accept`] and [link beast.ref.boost__beast__websocket__stream.async_accept `async_accept`] which accept an additional buffer sequence parameter are provided.	It is possible for servers to read data from the stream and decide later that the buffered bytes should be interpreted as a WebSocket upgrade request. To address this usage, overloads of [link beast.ref.boost__beast__websocket__stream.accept `accept`] and [link beast.ref.boost__beast__websocket__stream.async_accept `async_accept`] which accept an additional buffer sequence parameter are provided.
	Once the caller determines that the HTTP request is a WebSocket Upgrade, additional overloads of [link beast.ref.boost__beast__websocket__stream.accept `accept`] and [link beast.ref.boost__beast__websocket__stream.async_accept `async_accept`] are provided which receive the entire HTTP request header as an object to perform the handshake. By reading the request manually, the program can handle normal HTTP requests as well as upgrades. The program may also enforce policies based on the HTTP fields, such as Basic Authentication. In this example, the request is first read in using the HTTP algorithms, and then passed to a newly constructed stream:	Once the caller determines that the HTTP request is a WebSocket Upgrade, additional overloads of [link beast.ref.boost__beast__websocket__stream.accept `accept`] and [link beast.ref.boost__beast__websocket__stream.async_accept `async_accept`] are provided which receive the entire HTTP request header as an object to perform the handshake. By reading the request manually, the program can handle normal HTTP requests as well as upgrades. The program may also enforce policies based on the HTTP fields, such as Basic Authentication. In this example, the request is first read in using the HTTP algorithms, and then passed to a newly constructed stream:
	Subprotocols	Subprotocols
	The WebSocket protocol understands the concept of subprotocols. If the client is requesting one of a set of subprotocols it will set the header [@https://tools.ietf.org/html/rfc6455#section-11.3.4 Sec-WebSocket-Protocol] in the initial WebSocket Upgrade HTTP request. It is up to the server to parse the header and select one of the protocols to accept. The server indicates the selected protocol by setting the [@https://tools.ietf.org/html/rfc6455#section-11.3.4 Sec-WebSocket-Protocol] header in the accept header.	The WebSocket protocol understands the concept of subprotocols. If the client is requesting one of a set of subprotocols it will set the header [@https://tools.ietf.org/html/rfc6455#section-11.3.4 Sec-WebSocket-Protocol] in the initial WebSocket Upgrade HTTP request. It is up to the server to parse the header and select one of the protocols to accept. The server indicates the selected protocol by setting the [@https://tools.ietf.org/html/rfc6455#section-11.3.4 Sec-WebSocket-Protocol] header in the accept header.
	This is accomplished with a [link beast.ref.boost__beast__websocket__stream_base__decorator `decorator`].	This is accomplished with a [link beast.ref.boost__beast__websocket__stream_base__decorator `decorator`].
30	Wire Format	Wire Format

Translation

Things to check

Unchanged translation

Glossary

String information

Source string description

Details

Unit identifier

Source string location

String age

Last updated

Source string age

Translation file QuickBook file