Zen

Source string Source string

412
type: paragraph
6/10000 · 6

The string is read-only.

Key English Actions
Now we analyze the structure of the larger message container. The library uses a handle/body idiom. There are two public message container interfaces, one for requests (`http_request`) and one for responses (`http_response`). Each interface maintains a private shared pointer to an implementation class. Public member function calls are routed to the internal implementation. This is the first implementation class, which forms the base class for both the request and response implementations: ``` namespace details {
class http_msg_base { public:
protected:
306
}; ```
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:
336
private:
344
};
} // 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__:
* The constructor accepting `std::unique_ptr<http::details::_http_server_context`
* The "cancellation token" is stored inside the message. This breaks the
* 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:
407
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:
* There are no compile-time customization points at all. The only
* The extraction of the body is conflated with the asynchronous model.
* 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
* Setting the body requires either a vector or a `concurrency::streams::istream`.
* 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.
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).
Key English Actions
* The `_reply_impl` function implies that the message implementation also
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:
} // 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__:
* The constructor accepting `std::unique_ptr<http::details::_http_server_context`
* The "cancellation token" is stored inside the message. This breaks the
166
private:
170
};
254
private:
256
}; ```
306
}; ```
336
private:
344
};
407
private:
412
}; ```
82
}; ```

Loading…

User avatar admin

String added in the repository
}; ```
}; ```
412
06/05/2026
Browse all string changes

Glossary

English English
No related strings found in the glossary.

String information

Component
Boost Beast Translation (zh_Hans)/Doc / Qbk / 08 Design / 2 Http Comparison (qbk)
Key
412
Source string description
type: paragraph
Flags
read-only
Unit identifier
56577
Source string location
string ID 412
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.qbk, string 60