User avatar admin

String added in the repository
When a server receives a [@https://tools.ietf.org/html/rfc7231#section-4.3.2 HEAD request], the response should contain the entire header that would be delivered if the method was GET, except that the body is omitted.
When a server receives a [@https://tools.ietf.org/html/rfc7231#section-4.3.2 HEAD request], the response should contain the entire header that would be delivered if the method was GET, except that the body is omitted.
06/05/2026
User avatar admin

String added in the repository
HEAD response (Server) __example__
HEAD response (Server) __example__
06/05/2026
User avatar admin

String added in the repository
The [@https://tools.ietf.org/html/rfc7231#section-4.3.2 HEAD request] method indicates to the server that the client wishes to receive the entire header that would be delivered if the method was GET, except that the body is omitted. When a client wishes to receive the response to a HEAD request, it is necessary to inform the parser not to expect a body. This is done by calling [link beast.ref.boost__beast__http__basic_parser.skip `basic_parser::skip`] with the value `true`, as shown in this example:
The [@https://tools.ietf.org/html/rfc7231#section-4.3.2 HEAD request] method indicates to the server that the client wishes to receive the entire header that would be delivered if the method was GET, except that the body is omitted. When a client wishes to receive the response to a HEAD request, it is necessary to inform the parser not to expect a body. This is done by calling [link beast.ref.boost__beast__http__basic_parser.skip `basic_parser::skip`] with the value `true`, as shown in this example:
06/05/2026
User avatar admin

String added in the repository
HEAD request (Client) __example__
HEAD request (Client) __example__
06/05/2026
User avatar admin

String added in the repository
The Expect field with the value "100-continue" in a request is special. It indicates that the after sending the message header, a client desires an immediate informational response before sending the message body, which presumably may be expensive to compute or large. This behavior is described in [@https://tools.ietf.org/html/rfc7231#section-5.1.1 rfc7231 section 5.1.1]. Handling the Expect field can be implemented easily in a server by constructing a __parser__ to read the header first, then send an informational HTTP response, and finally read the body using the same parser instance. A synchronous version of this server action looks like this:
The Expect field with the value "100-continue" in a request is special. It indicates that the after sending the message header, a client desires an immediate informational response before sending the message body, which presumably may be expensive to compute or large. This behavior is described in [@https://tools.ietf.org/html/rfc7231#section-5.1.1 rfc7231 section 5.1.1]. Handling the Expect field can be implemented easily in a server by constructing a __parser__ to read the header first, then send an informational HTTP response, and finally read the body using the same parser instance. A synchronous version of this server action looks like this:
06/05/2026
User avatar admin

String added in the repository
Expect 100-continue (Server) __example__
Expect 100-continue (Server) __example__
06/05/2026
User avatar admin

String added in the repository
The Expect field with the value "100-continue" in a request is special. It indicates that the after sending the message header, a client desires an immediate informational response before sending the message body, which presumably may be expensive to compute or large. This behavior is described in [@https://tools.ietf.org/html/rfc7231#section-5.1.1 rfc7231 section 5.1.1]. Invoking the 100-continue behavior is implemented easily in a client by constructing a __serializer__ to send the header first, then receiving the server response, and finally conditionally send the body using the same serializer instance. A synchronous, simplified version (no timeout) of this client action looks like this:
The Expect field with the value "100-continue" in a request is special. It indicates that the after sending the message header, a client desires an immediate informational response before sending the message body, which presumably may be expensive to compute or large. This behavior is described in [@https://tools.ietf.org/html/rfc7231#section-5.1.1 rfc7231 section 5.1.1]. Invoking the 100-continue behavior is implemented easily in a client by constructing a __serializer__ to send the header first, then receiving the server response, and finally conditionally send the body using the same serializer instance. A synchronous, simplified version (no timeout) of this client action looks like this:
06/05/2026
User avatar admin

String added in the repository
Expect 100-continue (Client) __example__
Expect 100-continue (Client) __example__
06/05/2026
User avatar admin

String added in the repository
This example illustrates how a server may make the commitment of a body type depending on the method verb:
This example illustrates how a server may make the commitment of a body type depending on the method verb:
06/05/2026
User avatar admin

String added in the repository
Sophisticated servers may wish to defer the choice of the Body template type until after the header is available. Then, a body type may be chosen depending on the header contents. For example, depending on the verb, target path, or target query parameters. To accomplish this, a parser is declared to read in the header only, using a trivial body type such as [link beast.ref.boost__beast__http__empty_body `empty_body`]. Then, a new parser is constructed from this existing parser where the body type is conditionally determined by information from the header or elsewhere.
Sophisticated servers may wish to defer the choice of the Body template type until after the header is available. Then, a body type may be chosen depending on the header contents. For example, depending on the verb, target path, or target query parameters. To accomplish this, a parser is declared to read in the header only, using a trivial body type such as [link beast.ref.boost__beast__http__empty_body `empty_body`]. Then, a new parser is constructed from this existing parser where the body type is conditionally determined by information from the header or elsewhere.
06/05/2026
User avatar admin

String added in the repository
Change Body Type __example__
Change Body Type __example__
06/05/2026
User avatar admin

String added in the repository
These examples in this section are working functions that may be found in the examples directory. They demonstrate the usage of the library for a variety of scenarios.
These examples in this section are working functions that may be found in the examples directory. They demonstrate the usage of the library for a variety of scenarios.
06/05/2026
User avatar admin

String added in the repository
HTTP Examples
HTTP Examples
06/05/2026
User avatar admin

Resource updated
File “doc/qbk/06_websocket/01_connecting_zh_Hans.qbk” was added. 06/05/2026
User avatar admin

String added in the repository
Alternatively, the incoming connection may be accepted directly into the socket owned by the websocket stream, using this overload of the acceptor member function.
Alternatively, the incoming connection may be accepted directly into the socket owned by the websocket stream, using this overload of the acceptor member function.
06/05/2026
User avatar admin

String added in the repository
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.
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.
06/05/2026
User avatar admin

String added in the repository
Before messages can be exchanged, a websocket stream first needs to be connected, and then to have the websocket handshake performed. The stream delegates the task of establishing the connection to the next layers. For example, if the next layer is a connectible stream or socket object, it can be accessed to call the necessary function for connecting. Here we make an outbound connection as a client would do.
Before messages can be exchanged, a websocket stream first needs to be connected, and then to have the websocket handshake performed. The stream delegates the task of establishing the connection to the next layers. For example, if the next layer is a connectible stream or socket object, it can be accessed to call the necessary function for connecting. Here we make an outbound connection as a client would do.
06/05/2026
User avatar admin

String added in the repository
Connecting
Connecting
06/05/2026
User avatar admin

Resource updated
File “doc/qbk/06_websocket/05_control_frames_zh_Hans.qbk” was added. 06/05/2026
User avatar admin

String added in the repository
To ensure timely delivery of control frames, large outgoing messages can be broken up into smaller sized frames. The automatic fragment option turns on this feature, and the write buffer size option determines the maximum size of the fragments:
To ensure timely delivery of control frames, large outgoing messages can be broken up into smaller sized frames. The automatic fragment option turns on this feature, and the write buffer size option determines the maximum size of the fragments:
06/05/2026

Search