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

7 string ID 46
	Source string description type: list
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — * `P(x)` is a parsing function which produces a message container from 70/10000 · 70
8 string ID 49
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — These relations are true: 25/10000 · 25
9 string ID 51
	Source string description type: list
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — * `S(m) == x` 13/10000 · 13
10 string ID 53
	Source string description type: list
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — * `P(S(m)) == m` 16/10000 · 16
11 string ID 55
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — We would also like our message container to have customization points permitting the following: allocator awareness, user-defined containers to represent header fields, and user-defined types and algorithms to represent the body. And finally, because requests and responses have different fields in the ['start-line], we would like the containers for requests and responses to be represented by different types for function overloading. 436/10000 · 436
12 string ID 63
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Here is our first attempt at declaring some message containers: 63/10000 · 63
13 string ID 97
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — These containers are capable of representing everything in the model of HTTP requests and responses described in __rfc7230__. Request and response objects are different types. The user can choose the container used to represent the fields. And the user can choose the [*Body] type, which is a concept defining not only the type of `body` member but also the algorithms used to transfer information in and out of that member when performing serialization and parsing. 466/10000 · 466
14 string ID 105
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — However, a problem arises. How do we write a function which can accept an object that is either a request or a response? As written, the only obvious solution is to make the message a template type. Additional traits classes would then be needed to make sure that the passed object has a valid type which meets the requirements. These unnecessary complexities are bypassed by making each container a partial specialization: ``` /// An HTTP message template<bool isRequest, class Fields, class Body> struct message; 514/10000 · 514
15 string ID 116
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — /// An HTTP request template<class Fields, class Body> struct message<true, Fields, Body> { 91/10000 · 91
126 string ID 126
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — }; 2/10000 · 2
17 string ID 128
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — /// An HTTP response template<bool isRequest, class Fields, class Body> struct message<false, Fields, Body> { 109/10000 · 109
138 string ID 138
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — }; ``` 6/10000 · 6
19 string ID 141
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Now we can declare a function which takes any message as a parameter: ``` template<bool isRequest, class Fields, class Body> void f(message<isRequest, Fields, Body>& msg); ``` 175/10000 · 175
20 string ID 147
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — This function can manipulate the fields common to requests and responses. If it needs to access the other fields, it can use overloads with partial specialization, or in C++17 a `constexpr` expression: ``` template<bool isRequest, class Fields, class Body> void f(message<isRequest, Fields, Body>& msg) { 304/10000 · 304
21 string ID 162
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — } ``` 5/10000 · 5
22 string ID 165
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Often, in non-trivial HTTP applications, we want to read the HTTP header and examine its contents before choosing a type for [*Body]. To accomplish this, there needs to be a way to model the header portion of a message. And we'd like to do this in a way that allows functions which take the header as a parameter, to also accept a type representing the whole message (the function will see just the header part). This suggests inheritance, by splitting a new base class off of the message: ``` /// An HTTP message header template<bool isRequest, class Fields> struct header; ``` 578/10000 · 578
23 string ID 178
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Code which accesses the fields has to laboriously mention the `fields` member, so we'll not only make `header` a base class but we'll make a quality of life improvement and derive the header from the fields for notational convenience. In order to properly support all forms of construction of [*Fields] there will need to be a set of suitable constructor overloads (not shown): ``` /// An HTTP request header template<class Fields> struct header<true, Fields> : Fields { 470/10000 · 470
192 string ID 192
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — }; 2/10000 · 2
194 string ID 194
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — /// An HTTP response header template<class Fields> struct header<false, Fields> : Fields { 90/10000 · 90
201 string ID 201
	Source string description type: paragraph
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — }; 2/10000 · 2