msgid "" msgstr "" "Project-Id-Version: Chinese (Simplified Han script) (Boost Beast Translation " "(zh_Hans))\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2026-06-06 16:22+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: Chinese (Simplified Han script) \n" "Language: zh_Hans\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=1; plural=0;\n" "X-Generator: Weblate 2026.5\n" #. type: section title #: 10 #, fuzzy msgid "HTTP Examples" msgstr "HTTP Examples" #. type: paragraph #: 12 #, fuzzy msgid "" "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." msgstr "" "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." #. type: section title #: 18 #, fuzzy msgid "Change Body Type __example__" msgstr "Change Body Type __example__" #. type: paragraph #: 20 #, fuzzy msgid "" "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." msgstr "" "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." #. type: paragraph #: 29 #, fuzzy msgid "" "This example illustrates how a server may make the commitment of a body type " "depending on the method verb:" msgstr "" "This example illustrates how a server may make the commitment of a body type " "depending on the method verb:" #. type: section title #: 38 #, fuzzy msgid "Expect 100-continue (Client) __example__" msgstr "Expect 100-continue (Client) __example__" #. type: paragraph #: 40 #, fuzzy msgid "" "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:" msgstr "" "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:" #. type: section title #: 57 #, fuzzy msgid "Expect 100-continue (Server) __example__" msgstr "Expect 100-continue (Server) __example__" #. type: paragraph #: 59 #, fuzzy msgid "" "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:" msgstr "" "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:" #. type: section title #: 75 #, fuzzy msgid "HEAD request (Client) __example__" msgstr "HEAD request (Client) __example__" #. type: paragraph #: 77 #, fuzzy msgid "" "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:" msgstr "" "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:" #. type: section title #: 93 #, fuzzy msgid "HEAD response (Server) __example__" msgstr "HEAD response (Server) __example__" #. type: paragraph #: 95 #, fuzzy msgid "" "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." msgstr "" "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." #. type: section title #: 106 #, fuzzy msgid "HTTP Relay __example__" msgstr "HTTP Relay __example__" #. type: paragraph #: 108 #, fuzzy msgid "" "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." msgstr "" "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." #. type: paragraph #: 114 #, fuzzy msgid "" "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:" msgstr "" "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:" #. type: section title #: 126 #, fuzzy msgid "Send Child Process Output __example__" msgstr "Send Child Process Output __example__" #. type: paragraph #: 128 #, fuzzy msgid "" "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." msgstr "" "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." #. type: paragraph #: 135 #, fuzzy msgid "" "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." msgstr "" "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." #. type: paragraph #: 140 #, fuzzy msgid "" "This example reads from a child process and sends the output back in an HTTP " "response. The output of the process is sent as it becomes available:" msgstr "" "This example reads from a child process and sends the output back in an HTTP " "response. The output of the process is sent as it becomes available:"