2. Boost Beast Translation (zh_Hans)
3. Doc / Qbk / 08 Design / 1 Http Message (qbk)
4. English
5. Zen

40 string ID 287
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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 { 463/10000 · 463
312 string ID 312
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — }; ``` 6/10000 · 6
42 string ID 315
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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: 389/10000 · 389
43 string ID 322
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — ``` /// An HTTP header template<bool isRequest, class Body, class Fields = fields> struct header; 97/10000 · 97
44 string ID 327
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — /// An HTTP message template<bool isRequest, class Body, class Fields = fields> struct message; 95/10000 · 95
45 string ID 331
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — /// An HTTP request template<class Body, class Fields = fields> using request = message<true, Body, Fields>; 108/10000 · 108
46 string ID 335
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — /// An HTTP response template<class Body, class Fields = fields> using response = message<false, Body, Fields>; ``` 115/10000 · 115
47 string ID 340
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — This allows concise specification for the common cases, while allowing for maximum customization for edge cases: ``` request<string_body> req; 142/10000 · 142
48 string ID 345
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — response<file_body> res; ``` 28/10000 · 28
49 string ID 348
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 439/10000 · 439
50 string ID 355
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 389/10000 · 389
The translation has come to an end.