Exit Zen
2
string ID 14
type: paragraph
English
The following video presentation was delivered at [@https://cppcon.org/ CppCon] in 2017. The presentation provides a simplified explanation of the design process for the HTTP message container used in Beast. The slides and code used are available in the [@https://github.com/vinniefalco/CppCon2017 GitHub repository].
317/3170 · 317
3
string ID 31
type: paragraph
English
In this section we describe the problem of modeling HTTP messages and explain how the library arrived at its solution, with a discussion of the benefits and drawbacks of the design choices. The goal for creating a message model is to create a container with value semantics, possibly movable and/or copyable, that contains all the information needed to serialize, or all of the information captured during parsing. More formally, given:
436/4360 · 436
4
string ID 38
type: list
English
* `m` is an instance of an HTTP message container
49/490 · 49
5
string ID 40
type: list
English
* `x` is a series of octets describing a valid HTTP message in
62/620 · 62
6
string ID 43
type: list
English
* `S(m)` is a serialization function which produces a series of octets
70/700 · 70
7
string ID 46
type: list
English
* `P(x)` is a parsing function which produces a message container from
70/700 · 70
8
string ID 49
type: paragraph
English
These relations are true:
25/250 · 25
11
string ID 55
type: paragraph
English
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/4360 · 436
12
string ID 63
type: paragraph
English
Here is our first attempt at declaring some message containers:
63/630 · 63
13
string ID 97
type: paragraph
English
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/4660 · 466
14
string ID 105
type: paragraph
English
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/5140 · 514
15
string ID 116
type: paragraph
English
/// An HTTP request template<class Fields, class Body> struct message<true, Fields, Body> {
91/910 · 91
17
string ID 128
type: paragraph
English
/// An HTTP response template<bool isRequest, class Fields, class Body> struct message<false, Fields, Body> {
109/1090 · 109
19
string ID 141
type: paragraph
English
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/1750 · 175
20
string ID 147
type: paragraph
English
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/3040 · 304
22
string ID 165
type: paragraph
English
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/5780 · 578
23
string ID 178
type: paragraph
English
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/4700 · 470
194
string ID 194
type: paragraph
English
/// An HTTP response header template<class Fields> struct header<false, Fields> : Fields {
90/900 · 90
27
string ID 203
type: paragraph
English
/// An HTTP message template<bool isRequest, class Fields, class Body> struct message : header<isRequest, Fields> {
115/1150 · 115
30
string ID 215
type: paragraph
English
Note that the `message` class now has a constructor allowing messages to be constructed from a similarly typed `header`. This handles the case where the user already has the header and wants to make a commitment to the type for [*Body]. A function can be declared which accepts any header: ``` template<bool isRequest, class Fields> void f(header<isRequest, Fields>& msg); ```
376/3760 · 376