User avatar admin

Resource updated
File “doc/qbk/08_design/1_http_message_zh_Hans.qbk” was added. 06/05/2026
User avatar admin

String added in the repository
In conclusion, this representation for the message container is well thought out, provides comprehensive flexibility, and avoids the necessity of defining additional traits classes. User declarations of functions that accept headers or messages as parameters are easy to write in a variety of ways to accomplish different results, without forcing cumbersome SFINAE declarations everywhere.
In conclusion, this representation for the message container is well thought out, provides comprehensive flexibility, and avoids the necessity of defining additional traits classes. User declarations of functions that accept headers or messages as parameters are easy to write in a variety of ways to accomplish different results, without forcing cumbersome SFINAE declarations everywhere.
06/05/2026
User avatar admin

String added in the repository
This container is also capable of representing complete HTTP/2 messages. Not because it was explicitly designed for, but because the IETF wanted to preserve message compatibility with HTTP/1. Aside from version specific fields such as Connection, the contents of HTTP/1 and HTTP/2 messages are identical even though their serialized representation is considerably different. The message model presented in this library is ready for HTTP/2.
This container is also capable of representing complete HTTP/2 messages. Not because it was explicitly designed for, but because the IETF wanted to preserve message compatibility with HTTP/1. Aside from version specific fields such as Connection, the contents of HTTP/1 and HTTP/2 messages are identical even though their serialized representation is considerably different. The message model presented in this library is ready for HTTP/2.
06/05/2026
User avatar admin

String added in the repository
response<file_body> res; ```
response<file_body> res; ```
06/05/2026
User avatar admin

String added in the repository
This allows concise specification for the common cases, while allowing for maximum customization for edge cases: ``` request<string_body> req;
This allows concise specification for the common cases, while allowing for maximum customization for edge cases: ``` request<string_body> req;
06/05/2026
User avatar admin

String added in the repository
/// An HTTP response template<class Body, class Fields = fields> using response = message<false, Body, Fields>; ```
/// An HTTP response template<class Body, class Fields = fields> using response = message<false, Body, Fields>; ```
06/05/2026
User avatar admin

String added in the repository
/// An HTTP request template<class Body, class Fields = fields> using request = message<true, Body, Fields>;
/// An HTTP request template<class Body, class Fields = fields> using request = message<true, Body, Fields>;
06/05/2026
User avatar admin

String added in the repository
/// An HTTP message template<bool isRequest, class Body, class Fields = fields> struct message;
/// An HTTP message template<bool isRequest, class Body, class Fields = fields> struct message;
06/05/2026
User avatar admin

String added in the repository
``` /// An HTTP header template<bool isRequest, class Body, class Fields = fields> struct header;
``` /// An HTTP header template<bool isRequest, class Body, class Fields = fields> struct header;
06/05/2026
User avatar admin

String added in the repository
Now that we've accomplished our initial goals and more, there are a few more quality of life improvements to make. Users will choose different types for `Body` far more often than they will for `Fields`. Thus, we swap the order of these types and provide a default. Then, we provide type aliases for requests and responses to soften the impact of using `bool` to choose the specialization:
Now that we've accomplished our initial goals and more, there are a few more quality of life improvements to make. Users will choose different types for `Body` far more often than they will for `Fields`. Thus, we swap the order of these types and provide a default. Then, we provide type aliases for requests and responses to soften the impact of using `bool` to choose the specialization:
06/05/2026
User avatar admin

String added in the repository
}; ```
}; ```
312
06/05/2026
User avatar admin

String added in the repository
Now we add a requirement to the fields type: management of the corresponding string is delegated to the [*Fields] container, which can already be allocator aware and constructed with the necessary allocator parameter via the provided constructor overloads for `message`. The delegation implementation looks like this (only the response header specialization is shown): ``` /// An HTTP response header template<class Fields> struct header<false, Fields> : Fields {
Now we add a requirement to the fields type: management of the corresponding string is delegated to the [*Fields] container, which can already be allocator aware and constructed with the necessary allocator parameter via the provided constructor overloads for `message`. The delegation implementation looks like this (only the response header specialization is shown): ``` /// An HTTP response header template<class Fields> struct header<false, Fields> : Fields {
06/05/2026
User avatar admin

String added in the repository
The start-line data members are replaced by traditional accessors using non-owning references to string buffers. The method is stored using a simple integer instead of the entire string, for the case where the method is recognized from the set of known verb strings.
The start-line data members are replaced by traditional accessors using non-owning references to string buffers. The method is stored using a simple integer instead of the entire string, for the case where the method is recognized from the set of known verb strings.
06/05/2026
User avatar admin

String added in the repository
}; ```
}; ```
279
06/05/2026
User avatar admin

String added in the repository
/// An HTTP response header template<class Fields> struct header<false, Fields> : Fields {
/// An HTTP response header template<class Fields> struct header<false, Fields> : Fields {
271
06/05/2026
User avatar admin

String added in the repository
};
};
269
06/05/2026
User avatar admin

String added in the repository
private:
private:
06/05/2026
User avatar admin

String added in the repository
To get around this we make an interface modification and then add a requirement to the [*Fields] type. First, the interface change: ``` /// An HTTP request header template<class Fields> struct header<true, Fields> : Fields {
To get around this we make an interface modification and then add a requirement to the [*Fields] type. First, the interface change: ``` /// An HTTP request header template<class Fields> struct header<true, Fields> : Fields {
06/05/2026
User avatar admin

String added in the repository
There is now significant progress with our message container but a stumbling block remains. There is no way to control the allocator for the `std::string` members. We could add an allocator to the template parameter list of the header and message classes, use it for those strings. This is unsatisfying because of the combinatorial explosion of constructor variations needed to support the scheme. It also means that request messages could have [*four] different allocators: two for the fields and body, and two for the method and target strings. A better solution is needed.
There is now significant progress with our message container but a stumbling block remains. There is no way to control the allocator for the `std::string` members. We could add an allocator to the template parameter list of the header and message classes, use it for those strings. This is unsatisfying because of the combinatorial explosion of constructor variations needed to support the scheme. It also means that request messages could have [*four] different allocators: two for the fields and body, and two for the method and target strings. A better solution is needed.
06/05/2026
User avatar admin

String added in the repository
The solution used in the library is to treat the message like a `std::pair` for the purposes of construction, except that instead of `first` and `second` we have the `Fields` base class and `message::body` member. This means that single-argument constructors for those fields should be accessible as they are with `std::pair`, and that a mechanism identical to the pair's use of `std::piecewise_construct` should be provided. Those constructors are too complex to repeat here, but interested readers can view the declarations in the corresponding header file.
The solution used in the library is to treat the message like a `std::pair` for the purposes of construction, except that instead of `first` and `second` we have the `Fields` base class and `message::body` member. This means that single-argument constructors for those fields should be accessible as they are with `std::pair`, and that a mechanism identical to the pair's use of `std::piecewise_construct` should be provided. Those constructors are too complex to repeat here, but interested readers can view the declarations in the corresponding header file.
06/05/2026

Search