<?xml version="1.0" encoding="UTF-8"?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.1" version="1.1">
  <file original="NoName" source-language="en" datatype="plaintext" target-language="en">
    <body>
      <trans-unit xml:space="preserve" approved="no" id="1f1f194588e05551" weblate-flags="read-only">
        <source>HTTP Message Container __video__</source>
        <target state="translated">HTTP Message Container __video__</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">12</context>
        </context-group>
        <note from="developer">type: section title</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f7712460e6114338" weblate-flags="read-only">
        <source>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].</source>
        <target state="translated">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].</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">14</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="16bb034eb908e276" weblate-flags="read-only">
        <source>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:</source>
        <target state="translated">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:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">31</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="720b9e9f221dc59a" weblate-flags="read-only">
        <source>* `m` is an instance of an HTTP message container</source>
        <target state="translated">* `m` is an instance of an HTTP message container</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">38</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="49f08053047fb6f1" weblate-flags="read-only">
        <source>* `x` is a series of octets describing a valid HTTP message in</source>
        <target state="translated">* `x` is a series of octets describing a valid HTTP message in</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">40</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e7d2e5f4f59e73b8" weblate-flags="read-only">
        <source>* `S(m)` is a serialization function which produces a series of octets</source>
        <target state="translated">* `S(m)` is a serialization function which produces a series of octets</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">43</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="10be9500b0b06e6e" weblate-flags="read-only">
        <source>* `P(x)` is a parsing function which produces a message container from</source>
        <target state="translated">* `P(x)` is a parsing function which produces a message container from</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">46</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="06ddbcd6e2116884" weblate-flags="read-only">
        <source>These relations are true:</source>
        <target state="translated">These relations are true:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">49</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c635ef7f9eda4c1b" weblate-flags="read-only">
        <source>* `S(m) == x`</source>
        <target state="translated">* `S(m) == x`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">51</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7988b7328151315f" weblate-flags="read-only">
        <source>* `P(S(m)) == m`</source>
        <target state="translated">* `P(S(m)) == m`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">53</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4ca23e70fc9beead" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">55</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="325465202d9ed3f6" weblate-flags="read-only">
        <source>Here is our first attempt at declaring some message containers:</source>
        <target state="translated">Here is our first attempt at declaring some message containers:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">63</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5c8dae4b3a2b1312" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">97</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="08ca98d8750ce37f" weblate-flags="read-only">
        <source>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&lt;bool isRequest, class Fields, class Body&gt; struct message;</source>
        <target state="translated">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&lt;bool isRequest, class Fields, class Body&gt; struct message;</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">105</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b676891ef2912ad5" weblate-flags="read-only">
        <source>/// An HTTP request template&lt;class Fields, class Body&gt; struct message&lt;true, Fields, Body&gt; {</source>
        <target state="translated">/// An HTTP request template&lt;class Fields, class Body&gt; struct message&lt;true, Fields, Body&gt; {</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">116</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="126" weblate-flags="read-only">
        <source>};</source>
        <target state="translated">};</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">126</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d3b0e192f23dd337" weblate-flags="read-only">
        <source>/// An HTTP response template&lt;bool isRequest, class Fields, class Body&gt; struct message&lt;false, Fields, Body&gt; {</source>
        <target state="translated">/// An HTTP response template&lt;bool isRequest, class Fields, class Body&gt; struct message&lt;false, Fields, Body&gt; {</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">128</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="138" weblate-flags="read-only">
        <source>}; ```</source>
        <target state="translated">}; ```</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">138</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4e3e33cf807905b5" weblate-flags="read-only">
        <source>Now we can declare a function which takes any message as a parameter: ``` template&lt;bool isRequest, class Fields, class Body&gt; void f(message&lt;isRequest, Fields, Body&gt;&amp; msg); ```</source>
        <target state="translated">Now we can declare a function which takes any message as a parameter: ``` template&lt;bool isRequest, class Fields, class Body&gt; void f(message&lt;isRequest, Fields, Body&gt;&amp; msg); ```</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">141</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="92d7db1ba01b5ca7" weblate-flags="read-only">
        <source>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&lt;bool isRequest, class Fields, class Body&gt; void f(message&lt;isRequest, Fields, Body&gt;&amp; msg) {</source>
        <target state="translated">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&lt;bool isRequest, class Fields, class Body&gt; void f(message&lt;isRequest, Fields, Body&gt;&amp; msg) {</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">147</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1a3d7b198ded861c" weblate-flags="read-only">
        <source>} ```</source>
        <target state="translated">} ```</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">162</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1947702a661f62c7" weblate-flags="read-only">
        <source>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&lt;bool isRequest, class Fields&gt; struct header; ```</source>
        <target state="translated">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&lt;bool isRequest, class Fields&gt; struct header; ```</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">165</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="941dc0075db1c3a2" weblate-flags="read-only">
        <source>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&lt;class Fields&gt; struct header&lt;true, Fields&gt; : Fields {</source>
        <target state="translated">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&lt;class Fields&gt; struct header&lt;true, Fields&gt; : Fields {</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">178</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="192" weblate-flags="read-only">
        <source>};</source>
        <target state="translated">};</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">192</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="194" weblate-flags="read-only">
        <source>/// An HTTP response header template&lt;class Fields&gt; struct header&lt;false, Fields&gt; : Fields {</source>
        <target state="translated">/// An HTTP response header template&lt;class Fields&gt; struct header&lt;false, Fields&gt; : Fields {</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">194</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="201" weblate-flags="read-only">
        <source>};</source>
        <target state="translated">};</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">201</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="30adab9086fdf167" weblate-flags="read-only">
        <source>/// An HTTP message template&lt;bool isRequest, class Fields, class Body&gt; struct message : header&lt;isRequest, Fields&gt; {</source>
        <target state="translated">/// An HTTP message template&lt;bool isRequest, class Fields, class Body&gt; struct message : header&lt;isRequest, Fields&gt; {</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">203</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="211" weblate-flags="read-only">
        <source>};</source>
        <target state="translated">};</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">211</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1d11673962fb6c44" weblate-flags="read-only">
        <source>```</source>
        <target state="translated">```</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">213</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9b613968fe6f36ac" weblate-flags="read-only">
        <source>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&lt;bool isRequest, class Fields&gt; void f(header&lt;isRequest, Fields&gt;&amp; msg); ```</source>
        <target state="translated">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&lt;bool isRequest, class Fields&gt; void f(header&lt;isRequest, Fields&gt;&amp; msg); ```</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">215</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0c8474058a578728" weblate-flags="read-only">
        <source>Until now we have not given significant consideration to the constructors of the `message` class. But to achieve all our goals we will need to make sure that there are enough constructor overloads to not only provide for the special copy and move members if the instantiated types support it, but also allow the fields container and body container to be constructed with arbitrary variadic lists of parameters. This allows the container to fully support allocators.</source>
        <target state="translated">Until now we have not given significant consideration to the constructors of the `message` class. But to achieve all our goals we will need to make sure that there are enough constructor overloads to not only provide for the special copy and move members if the instantiated types support it, but also allow the fields container and body container to be constructed with arbitrary variadic lists of parameters. This allows the container to fully support allocators.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">224</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9f650a7af5c61d71" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">232</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b0336afd41cf87ff" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">241</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5f73baeafc9a702b" weblate-flags="read-only">
        <source>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&lt;class Fields&gt; struct header&lt;true, Fields&gt; : Fields {</source>
        <target state="translated">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&lt;class Fields&gt; struct header&lt;true, Fields&gt; : Fields {</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">250</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c119ede8648479dd" weblate-flags="read-only">
        <source>private:</source>
        <target state="translated">private:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">267</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="269" weblate-flags="read-only">
        <source>};</source>
        <target state="translated">};</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">269</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="271" weblate-flags="read-only">
        <source>/// An HTTP response header template&lt;class Fields&gt; struct header&lt;false, Fields&gt; : Fields {</source>
        <target state="translated">/// An HTTP response header template&lt;class Fields&gt; struct header&lt;false, Fields&gt; : Fields {</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">271</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="279" weblate-flags="read-only">
        <source>}; ```</source>
        <target state="translated">}; ```</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">279</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9d8fa975ac4afc30" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">282</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e74a5eb39fd7bc76" weblate-flags="read-only">
        <source>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&lt;class Fields&gt; struct header&lt;false, Fields&gt; : Fields {</source>
        <target state="translated">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&lt;class Fields&gt; struct header&lt;false, Fields&gt; : Fields {</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">287</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="312" weblate-flags="read-only">
        <source>}; ```</source>
        <target state="translated">}; ```</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">312</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8ffef0e72abe8cf5" weblate-flags="read-only">
        <source>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:</source>
        <target state="translated">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:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">315</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="58b9b42f27d15acc" weblate-flags="read-only">
        <source>``` /// An HTTP header template&lt;bool isRequest, class Body, class Fields = fields&gt; struct header;</source>
        <target state="translated">``` /// An HTTP header template&lt;bool isRequest, class Body, class Fields = fields&gt; struct header;</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">322</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1c6810dc6585784f" weblate-flags="read-only">
        <source>/// An HTTP message template&lt;bool isRequest, class Body, class Fields = fields&gt; struct message;</source>
        <target state="translated">/// An HTTP message template&lt;bool isRequest, class Body, class Fields = fields&gt; struct message;</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">327</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="baebf3a8480ae3b9" weblate-flags="read-only">
        <source>/// An HTTP request template&lt;class Body, class Fields = fields&gt; using request = message&lt;true, Body, Fields&gt;;</source>
        <target state="translated">/// An HTTP request template&lt;class Body, class Fields = fields&gt; using request = message&lt;true, Body, Fields&gt;;</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">331</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7fa81623254783f2" weblate-flags="read-only">
        <source>/// An HTTP response template&lt;class Body, class Fields = fields&gt; using response = message&lt;false, Body, Fields&gt;; ```</source>
        <target state="translated">/// An HTTP response template&lt;class Body, class Fields = fields&gt; using response = message&lt;false, Body, Fields&gt;; ```</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">335</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="26680c4cdeb5be18" weblate-flags="read-only">
        <source>This allows concise specification for the common cases, while allowing for maximum customization for edge cases: ``` request&lt;string_body&gt; req;</source>
        <target state="translated">This allows concise specification for the common cases, while allowing for maximum customization for edge cases: ``` request&lt;string_body&gt; req;</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">340</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1c51fe20852eec30" weblate-flags="read-only">
        <source>response&lt;file_body&gt; res; ```</source>
        <target state="translated">response&lt;file_body&gt; res; ```</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">345</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="bbce7c5940232de2" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">348</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9a3215b20377f9b2" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">355</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
    </body>
  </file>
</xliff>
