Zen

Translation

type: paragraph
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.
275/2750 · 275

Sign in to save translations.

Key English Chinese (Simplified Han script) Actions
} // 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:
407
private:
private:
412
}; ```
}; ```
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.
Tasks in the Concurrency Runtime operate in a fashion similar to `std::future`, but with some improvements such as continuations which are not yet in the C++ standard. The costs of using a task based asynchronous interface instead of completion handlers is well documented: synchronization points along the call chain of composed task operations which cannot be optimized away. See: [@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3747.pdf [*A Universal Model for Asynchronous Operations]] (Kohlhoff).
Tasks in the Concurrency Runtime operate in a fashion similar to `std::future`, but with some improvements such as continuations which are not yet in the C++ standard. The costs of using a task based asynchronous interface instead of completion handlers is well documented: synchronization points along the call chain of composed task operations which cannot be optimized away. See: [@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3747.pdf [*A Universal Model for Asynchronous Operations]] (Kohlhoff).
English Chinese (Simplified Han script) Actions
} // 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.
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 {
typedef basic_message<boost::http::headers, std::vector<std::uint8_t>> message;
typedef basic_message<boost::http::headers, std::vector<std::uint8_t>> message;
template<class Headers, class Body> struct is_message<basic_message<Headers, Body>>: public std::true_type {}; ```
template<class Headers, class Body> struct is_message<basic_message<Headers, Body>>: public std::true_type {}; ```
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 {

Loading…

User avatar admin

String added in the repository
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.
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
58683
Source string location
string ID 442
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 68