Zen

Translation

type: paragraph
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.
574/5740 · 574

Sign in to save translations.

English Chinese (Simplified Han script) Actions
HTTP Examples
HTTP Examples
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.
Change Body Type __example__
Change Body Type __example__
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.
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:
Expect 100-continue (Client) __example__
Expect 100-continue (Client) __example__
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:
Expect 100-continue (Server) __example__
Expect 100-continue (Server) __example__
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:
HEAD request (Client) __example__
HEAD request (Client) __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:
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:
HEAD response (Server) __example__
HEAD response (Server) __example__
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.
HTTP Relay __example__
HTTP Relay __example__
An HTTP proxy acts as a relay between client and server. The proxy reads a request from the client and sends it to the server, possibly adjusting some of the headers and representation of the body along the way. Then, the proxy reads a response from the server and sends it back to the client, also with the possibility of changing the headers and body representation.
An HTTP proxy acts as a relay between client and server. The proxy reads a request from the client and sends it to the server, possibly adjusting some of the headers and representation of the body along the way. Then, the proxy reads a response from the server and sends it back to the client, also with the possibility of changing the headers and body representation.
The example that follows implements a synchronous HTTP relay. It uses a fixed size buffer, to avoid reading in the entire body so that the upstream connection sees a header without unnecessary latency. This example brings together all of the concepts discussed so far, it uses both a __serializer__ and a __parser__ to achieve its goal:
The example that follows implements a synchronous HTTP relay. It uses a fixed size buffer, to avoid reading in the entire body so that the upstream connection sees a header without unnecessary latency. This example brings together all of the concepts discussed so far, it uses both a __serializer__ and a __parser__ to achieve its goal:
Send Child Process Output __example__
Send Child Process Output __example__
Sometimes it is necessary to send a message whose body is not conveniently described by a single container. For example, when implementing an HTTP relay function a robust implementation needs to present body buffers individually as they become available from the downstream host. These buffers should be fixed in size, otherwise creating the unnecessary and inefficient burden of reading the complete message body before forwarding it to the upstream host.
Sometimes it is necessary to send a message whose body is not conveniently described by a single container. For example, when implementing an HTTP relay function a robust implementation needs to present body buffers individually as they become available from the downstream host. These buffers should be fixed in size, otherwise creating the unnecessary and inefficient burden of reading the complete message body before forwarding it to the upstream host.
To enable these use-cases, the body type __buffer_body__ is provided. This body uses a caller-provided pointer and size instead of an owned container. To use this body, instantiate an instance of the serializer and fill in the pointer and size fields before calling a stream write function.
To enable these use-cases, the body type __buffer_body__ is provided. This body uses a caller-provided pointer and size instead of an owned container. To use this body, instantiate an instance of the serializer and fill in the pointer and size fields before calling a stream write function.
English Chinese (Simplified Han script) Actions
HEAD request (Client) __example__
HEAD request (Client) __example__
HTTP Examples
HTTP Examples
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.
Change Body Type __example__
Change Body Type __example__
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.
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:
Expect 100-continue (Client) __example__
Expect 100-continue (Client) __example__
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:
Expect 100-continue (Server) __example__
Expect 100-continue (Server) __example__
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:
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:
HEAD response (Server) __example__
HEAD response (Server) __example__
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.
HTTP Relay __example__
HTTP Relay __example__
An HTTP proxy acts as a relay between client and server. The proxy reads a request from the client and sends it to the server, possibly adjusting some of the headers and representation of the body along the way. Then, the proxy reads a response from the server and sends it back to the client, also with the possibility of changing the headers and body representation.
An HTTP proxy acts as a relay between client and server. The proxy reads a request from the client and sends it to the server, possibly adjusting some of the headers and representation of the body along the way. Then, the proxy reads a response from the server and sends it back to the client, also with the possibility of changing the headers and body representation.
The example that follows implements a synchronous HTTP relay. It uses a fixed size buffer, to avoid reading in the entire body so that the upstream connection sees a header without unnecessary latency. This example brings together all of the concepts discussed so far, it uses both a __serializer__ and a __parser__ to achieve its goal:
The example that follows implements a synchronous HTTP relay. It uses a fixed size buffer, to avoid reading in the entire body so that the upstream connection sees a header without unnecessary latency. This example brings together all of the concepts discussed so far, it uses both a __serializer__ and a __parser__ to achieve its goal:
Send Child Process Output __example__
Send Child Process Output __example__
Sometimes it is necessary to send a message whose body is not conveniently described by a single container. For example, when implementing an HTTP relay function a robust implementation needs to present body buffers individually as they become available from the downstream host. These buffers should be fixed in size, otherwise creating the unnecessary and inefficient burden of reading the complete message body before forwarding it to the upstream host.
Sometimes it is necessary to send a message whose body is not conveniently described by a single container. For example, when implementing an HTTP relay function a robust implementation needs to present body buffers individually as they become available from the downstream host. These buffers should be fixed in size, otherwise creating the unnecessary and inefficient burden of reading the complete message body before forwarding it to the upstream host.
To enable these use-cases, the body type __buffer_body__ is provided. This body uses a caller-provided pointer and size instead of an owned container. To use this body, instantiate an instance of the serializer and fill in the pointer and size fields before calling a stream write function.
To enable these use-cases, the body type __buffer_body__ is provided. This body uses a caller-provided pointer and size instead of an owned container. To use this body, instantiate an instance of the serializer and fill in the pointer and size fields before calling a stream write function.

Loading…

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
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
59418
Source string location
string ID 20
String age
06/05/2026
Last updated
06/05/2026
Source string age
06/05/2026
Translation file QuickBook file
doc/qbk/05_http_examples/_http_examples_zh_Hans.qbk, string 4