Boost Beast Translation (zh_Hans)/Doc / Qbk / 08 Design / 2 Http Comparison (qbk) — Chinese (Simplified Han script) @ Boost-Weblate: is a network programming library previously intended for Boost but …

Zen

Translation

Source string description

type: paragraph

English

is a network programming library previously intended for Boost but not having gone through formal review. As of this writing it still uses the Boost name, namespace, and directory structure although the project states that Boost acceptance is no longer a goal. The library is based on Boost.Asio and bills itself as ['"a collection of network related routines/implementations geared towards providing a robust cross-platform networking library"]. It cites ['"Common Message Type"] as a feature. As of the branch previous linked, it uses these declarations: ``` template <class Tag> struct basic_message {

Chinese (Simplified Han script)

Needs editing (Needs rewriting)

Skip

Loading…

admin

String added in the repository

English

Chinese (Simplified Han script) 604 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

58625

Source string location

string ID 44

String age

06/05/2026

Last updated

06/05/2026

Source string age

06/05/2026

Translation file QuickBook file

doc/qbk/08_design/2_http_comparison_zh_Hans.qbk, string 10

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)
	HTTP Comparison to Other Libraries	HTTP Comparison to Other Libraries
	There are a few C++ published libraries which implement some of the HTTP protocol. We analyze the message model chosen by those libraries and discuss the advantages and disadvantages relative to Beast.	There are a few C++ published libraries which implement some of the HTTP protocol. We analyze the message model chosen by those libraries and discuss the advantages and disadvantages relative to Beast.
	The general strategy used by the author to evaluate external libraries is as follows:	The general strategy used by the author to evaluate external libraries is as follows:
	* Review the message model. Can it represent a complete request or	* Review the message model. Can it represent a complete request or
	* Review the stream abstraction. This is the type of object, such as	* Review the stream abstraction. This is the type of object, such as
	* Check treatment of buffers. Does the library manage the buffers	* Check treatment of buffers. Does the library manage the buffers
	* How does the library handle corner cases such as trailers,	* How does the library handle corner cases such as trailers,
	Declarations examples from external libraries have been edited:	Declarations examples from external libraries have been edited:
	cpp-netlib	cpp-netlib
	is a network programming library previously intended for Boost but not having gone through formal review. As of this writing it still uses the Boost name, namespace, and directory structure although the project states that Boost acceptance is no longer a goal. The library is based on Boost.Asio and bills itself as ['"a collection of network related routines/implementations geared towards providing a robust cross-platform networking library"]. It cites ['"Common Message Type"] as a feature. As of the branch previous linked, it uses these declarations: ``` template <class Tag> struct basic_message {	is a network programming library previously intended for Boost but not having gone through formal review. As of this writing it still uses the Boost name, namespace, and directory structure although the project states that Boost acceptance is no longer a goal. The library is based on Boost.Asio and bills itself as ['"a collection of network related routines/implementations geared towards providing a robust cross-platform networking library"]. It cites ['"Common Message Type"] as a feature. As of the branch previous linked, it uses these declarations: ``` template <class Tag> struct basic_message {
82	}; ```	}; ```
	This container is the base class template used to represent HTTP messages. It uses a "tag" type style specializations for a variety of trait classes, allowing for customization of the various parts of the message. For example, a user specializes `headers_container<T>` to determine what container type holds the header fields. We note some problems with the container declaration:	This container is the base class template used to represent HTTP messages. It uses a "tag" type style specializations for a variety of trait classes, allowing for customization of the various parts of the message. For example, a user specializes `headers_container<T>` to determine what container type holds the header fields. We note some problems with the container declaration:
	* The header and body containers may only be default-constructed.	* The header and body containers may only be default-constructed.
	* No stateful allocator support.	* No stateful allocator support.
	* There is no way to defer the commitment of the type for `body_` to	* There is no way to defer the commitment of the type for `body_` to
	* The message model includes a "source" and "destination." This is	* The message model includes a "source" and "destination." This is
	* The use of `string_type` (a customization point) for source,	* The use of `string_type` (a customization point) for source,
	* The library uses specializations of `string<Tag>` to change the type	* The library uses specializations of `string<Tag>` to change the type
	* The specialized trait classes generate a proliferation of small	* The specialized trait classes generate a proliferation of small
	* The `string<Tag> customization point constrains user defined body types	* The `string<Tag> customization point constrains user defined body types
	The design of the message container in this library is cumbersome with its system of customization using trait specializations. The use of these customizations is extremely limited due to the way they are used in the container declaration, making the design overly complex without corresponding benefit.	The design of the message container in this library is cumbersome with its system of customization using trait specializations. The use of these customizations is extremely limited due to the way they are used in the container declaration, making the design overly complex without corresponding benefit.
	Boost.HTTP	Boost.HTTP
	is a library resulting from the 2014 Google Summer of Code. It was submitted for a Boost formal review and rejected in 2015. It is based on Boost.Asio, and development on the library has continued to the present. As of the branch previously linked, it uses these message declarations: ``` template<class Headers, class Body> struct basic_message {	is a library resulting from the 2014 Google Summer of Code. It was submitted for a Boost formal review and rejected in 2015. It is based on Boost.Asio, and development on the library has continued to the present. As of the branch previously linked, it uses these message declarations: ``` template<class Headers, class Body> struct basic_message {
166	private:	private:
170	};	};

	English	Chinese (Simplified Han script)	Actions
	To understand these declarations we need to first understand that cpprestsdk uses the asynchronous model defined by Microsoft's [@https://msdn.microsoft.com/en-us/library/dd504870.aspx [Concurrency Runtime]]. Identifiers from the [@https://msdn.microsoft.com/en-us/library/jj987780.aspx [`pplx` namespace]] define common asynchronous patterns such as tasks and events. The `concurrency::streams::istream` parameter and `m_data_available` data member indicates a lack of separation of concerns. The representation of HTTP messages should not be conflated with the asynchronous model used to serialize or parse those messages in the message declarations.	To understand these declarations we need to first understand that cpprestsdk uses the asynchronous model defined by Microsoft's [@https://msdn.microsoft.com/en-us/library/dd504870.aspx [Concurrency Runtime]]. Identifiers from the [@https://msdn.microsoft.com/en-us/library/jj987780.aspx [`pplx` namespace]] define common asynchronous patterns such as tasks and events. The `concurrency::streams::istream` parameter and `m_data_available` data member indicates a lack of separation of concerns. The representation of HTTP messages should not be conflated with the asynchronous model used to serialize or parse those messages in the message declarations.
	The next declaration forms the complete implementation class referenced by the handle in the public interface (which follows after): ``` /// Internal representation of an HTTP request message. class _http_request final : public http::details::http_msg_base, public std::enable_shared_from_this<_http_request> { public:	The next declaration forms the complete implementation class referenced by the handle in the public interface (which follows after): ``` /// Internal representation of an HTTP request message. class _http_request final : public http::details::http_msg_base, public std::enable_shared_from_this<_http_request> { public:
	} // namespace details ```	} // namespace details ```
	As before, we note that the implementation class for HTTP requests concerns itself more with the mechanics of sending the message asynchronously than it does with actually modeling the HTTP message as described in __rfc7230__:	As before, we note that the implementation class for HTTP requests concerns itself more with the mechanics of sending the message asynchronously than it does with actually modeling the HTTP message as described in __rfc7230__:
	* The constructor accepting `std::unique_ptr<http::details::_http_server_context`	* The constructor accepting `std::unique_ptr<http::details::_http_server_context`
	* The "cancellation token" is stored inside the message. This breaks the	* The "cancellation token" is stored inside the message. This breaks the
	* The `_reply_impl` function implies that the message implementation also	* The `_reply_impl` function implies that the message implementation also
	Finally, here is the public class which represents an HTTP request: ``` class http_request { public:	Finally, here is the public class which represents an HTTP request: ``` class http_request { public:
	It is clear from this declaration that the goal of the message model in this library is driven by its use-case (interacting with REST servers) and not to model HTTP messages generally. We note problems similar to the other declarations:	It is clear from this declaration that the goal of the message model in this library is driven by its use-case (interacting with REST servers) and not to model HTTP messages generally. We note problems similar to the other declarations:
	* There are no compile-time customization points at all. The only	* There are no compile-time customization points at all. The only
	* The extraction of the body is conflated with the asynchronous model.	* The extraction of the body is conflated with the asynchronous model.
	* No way to define an allocator for the container used when extracting	* No way to define an allocator for the container used when extracting
	* A body can only be extracted once, limiting the use of this container	* A body can only be extracted once, limiting the use of this container
	* Setting the body requires either a vector or a `concurrency::streams::istream`.	* Setting the body requires either a vector or a `concurrency::streams::istream`.
	* The HTTP request container conflates HTTP response behavior (see the	* The HTTP request container conflates HTTP response behavior (see the
	The general theme of the HTTP message model in cpprestsdk is "no user definable customizations". There is no allocator support, and no separation of concerns. It is designed to perform a specific set of behaviors. In other words, it does not follow the open/closed principle.	The general theme of the HTTP message model in cpprestsdk is "no user definable customizations". There is no allocator support, and no separation of concerns. It is designed to perform a specific set of behaviors. In other words, it does not follow the open/closed principle.
	* No support for allocators, stateful or otherwise.	* No support for allocators, stateful or otherwise.
	HTTP Comparison to Other Libraries	HTTP Comparison to Other Libraries
	There are a few C++ published libraries which implement some of the HTTP protocol. We analyze the message model chosen by those libraries and discuss the advantages and disadvantages relative to Beast.	There are a few C++ published libraries which implement some of the HTTP protocol. We analyze the message model chosen by those libraries and discuss the advantages and disadvantages relative to Beast.
	The general strategy used by the author to evaluate external libraries is as follows:	The general strategy used by the author to evaluate external libraries is as follows:
	* Review the message model. Can it represent a complete request or	* Review the message model. Can it represent a complete request or
	* Review the stream abstraction. This is the type of object, such as	* Review the stream abstraction. This is the type of object, such as
	* Check treatment of buffers. Does the library manage the buffers	* Check treatment of buffers. Does the library manage the buffers
	* How does the library handle corner cases such as trailers,	* How does the library handle corner cases such as trailers,
	Declarations examples from external libraries have been edited:	Declarations examples from external libraries have been edited:
	cpp-netlib	cpp-netlib
	is a network programming library previously intended for Boost but not having gone through formal review. As of this writing it still uses the Boost name, namespace, and directory structure although the project states that Boost acceptance is no longer a goal. The library is based on Boost.Asio and bills itself as ['"a collection of network related routines/implementations geared towards providing a robust cross-platform networking library"]. It cites ['"Common Message Type"] as a feature. As of the branch previous linked, it uses these declarations: ``` template <class Tag> struct basic_message {	is a network programming library previously intended for Boost but not having gone through formal review. As of this writing it still uses the Boost name, namespace, and directory structure although the project states that Boost acceptance is no longer a goal. The library is based on Boost.Asio and bills itself as ['"a collection of network related routines/implementations geared towards providing a robust cross-platform networking library"]. It cites ['"Common Message Type"] as a feature. As of the branch previous linked, it uses these declarations: ``` template <class Tag> struct basic_message {

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