<?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="zh_Hans">
    <body>
      <trans-unit xml:space="preserve" approved="no" id="0348d31aa2f92963">
        <source>HTTP Comparison to Other Libraries</source>
        <target state="needs-translation">HTTP Comparison to Other Libraries</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">10</context>
        </context-group>
        <note from="developer">type: section title</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2d49845a397548fa">
        <source>There are a few C++ published libraries which implement some of the HTTP protocol. We analyze the message model chosen by those libraries and discuss the advantages and disadvantages relative to Beast.</source>
        <target state="needs-translation">There are a few C++ published libraries which implement some of the HTTP protocol. We analyze the message model chosen by those libraries and discuss the advantages and disadvantages relative to Beast.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">12</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="56c4b5b85a298844">
        <source>The general strategy used by the author to evaluate external libraries is as follows:</source>
        <target state="needs-translation">The general strategy used by the author to evaluate external libraries is as follows:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">16</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0cf69c38edb55b76">
        <source>* Review the message model. Can it represent a complete request or</source>
        <target state="needs-translation">* Review the message model. Can it represent a complete request or</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">19</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="72acced25163b9a9">
        <source>* Review the stream abstraction. This is the type of object, such as</source>
        <target state="needs-translation">* Review the stream abstraction. This is the type of object, such as</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">23</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="376da205350a78af">
        <source>* Check treatment of buffers. Does the library manage the buffers</source>
        <target state="needs-translation">* Check treatment of buffers. Does the library manage the buffers</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">28</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b8f5d9183056323c">
        <source>* How does the library handle corner cases such as trailers,</source>
        <target state="needs-translation">* How does the library handle corner cases such as trailers,</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">31</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8474f6ee1764b124">
        <source>Declarations examples from external libraries have been edited:</source>
        <target state="needs-translation">Declarations examples from external libraries have been edited:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">35</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="853df25bcd14a8d4">
        <source>cpp-netlib</source>
        <target state="needs-translation">cpp-netlib</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">41</context>
        </context-group>
        <note from="developer">type: heading</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c08445bf21915144">
        <source>is a network programming library previously intended for Boost but not having gone through formal review. As of this writing it still uses the Boost name, namespace, and directory structure although the project states that Boost acceptance is no longer a goal. The library is based on Boost.Asio and bills itself as ['"a collection of network related routines/implementations geared towards providing a robust cross-platform networking library"]. It cites ['"Common Message Type"] as a feature. As of the branch previous linked, it uses these declarations: ``` template &lt;class Tag&gt; struct basic_message {</source>
        <target state="needs-translation">is a network programming library previously intended for Boost but not having gone through formal review. As of this writing it still uses the Boost name, namespace, and directory structure although the project states that Boost acceptance is no longer a goal. The library is based on Boost.Asio and bills itself as ['"a collection of network related routines/implementations geared towards providing a robust cross-platform networking library"]. It cites ['"Common Message Type"] as a feature. As of the branch previous linked, it uses these declarations: ``` template &lt;class Tag&gt; struct basic_message {</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">44</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="82">
        <source>}; ```</source>
        <target state="needs-translation">}; ```</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">82</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="48d3a584d56bb920">
        <source>This container is the base class template used to represent HTTP messages. It uses a "tag" type style specializations for a variety of trait classes, allowing for customization of the various parts of the message. For example, a user specializes `headers_container&lt;T&gt;` to determine what container type holds the header fields. We note some problems with the container declaration:</source>
        <target state="needs-translation">This container is the base class template used to represent HTTP messages. It uses a "tag" type style specializations for a variety of trait classes, allowing for customization of the various parts of the message. For example, a user specializes `headers_container&lt;T&gt;` to determine what container type holds the header fields. We note some problems with the container declaration:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">85</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e111a5a6d7654362">
        <source>* The header and body containers may only be default-constructed.</source>
        <target state="needs-translation">* The header and body containers may only be default-constructed.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">91</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="32d89d3718056754">
        <source>* No stateful allocator support.</source>
        <target state="needs-translation">* No stateful allocator support.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">93</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3625920b1defd773">
        <source>* There is no way to defer the commitment of the type for `body_` to</source>
        <target state="needs-translation">* There is no way to defer the commitment of the type for `body_` to</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">95</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f6337707dce19768">
        <source>* The message model includes a "source" and "destination." This is</source>
        <target state="needs-translation">* The message model includes a "source" and "destination." This is</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">98</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="62dc60a3bb9511bb">
        <source>* The use of `string_type` (a customization point) for source,</source>
        <target state="needs-translation">* The use of `string_type` (a customization point) for source,</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">102</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5979ece9b7df95bf">
        <source>* The library uses specializations of `string&lt;Tag&gt;` to change the type</source>
        <target state="needs-translation">* The library uses specializations of `string&lt;Tag&gt;` to change the type</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">112</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8711e3da40e25bc0">
        <source>* The specialized trait classes generate a proliferation of small</source>
        <target state="needs-translation">* The specialized trait classes generate a proliferation of small</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">121</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ae4811342b697f46">
        <source>* The `string&lt;Tag&gt; customization point constrains user defined body types</source>
        <target state="needs-translation">* The `string&lt;Tag&gt; customization point constrains user defined body types</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">127</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ee6a3875774b36db">
        <source>The design of the message container in this library is cumbersome with its system of customization using trait specializations. The use of these customizations is extremely limited due to the way they are used in the container declaration, making the design overly complex without corresponding benefit.</source>
        <target state="needs-translation">The design of the message container in this library is cumbersome with its system of customization using trait specializations. The use of these customizations is extremely limited due to the way they are used in the container declaration, making the design overly complex without corresponding benefit.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">132</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="dd32c91d5409110a">
        <source>Boost.HTTP</source>
        <target state="needs-translation">Boost.HTTP</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">140</context>
        </context-group>
        <note from="developer">type: heading</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="54a53919fefcf76d">
        <source>is a library resulting from the 2014 Google Summer of Code. It was submitted for a Boost formal review and rejected in 2015. It is based on Boost.Asio, and development on the library has continued to the present. As of the branch previously linked, it uses these message declarations: ``` template&lt;class Headers, class Body&gt; struct basic_message {</source>
        <target state="needs-translation">is a library resulting from the 2014 Google Summer of Code. It was submitted for a Boost formal review and rejected in 2015. It is based on Boost.Asio, and development on the library has continued to the present. As of the branch previously linked, it uses these message declarations: ``` template&lt;class Headers, class Body&gt; struct basic_message {</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">143</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="166">
        <source>private:</source>
        <target state="needs-translation">private:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">166</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="170">
        <source>};</source>
        <target state="needs-translation">};</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">170</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="63386ab9e0973380">
        <source>typedef basic_message&lt;boost::http::headers, std::vector&lt;std::uint8_t&gt;&gt; message;</source>
        <target state="needs-translation">typedef basic_message&lt;boost::http::headers, std::vector&lt;std::uint8_t&gt;&gt; message;</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">172</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="70ef9c752dd15fed">
        <source>template&lt;class Headers, class Body&gt; struct is_message&lt;basic_message&lt;Headers, Body&gt;&gt;: public std::true_type {}; ```</source>
        <target state="needs-translation">template&lt;class Headers, class Body&gt; struct is_message&lt;basic_message&lt;Headers, Body&gt;&gt;: public std::true_type {}; ```</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">174</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="978aea7df2468afe">
        <source>* This container cannot model a complete message. The ['start-line] items</source>
        <target state="needs-translation">* This container cannot model a complete message. The ['start-line] items</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">178</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8150a6ebc45010c1">
        <source>* `headers_`, `body_`, and `trailers_` may only be default-constructed,</source>
        <target state="needs-translation">* `headers_`, `body_`, and `trailers_` may only be default-constructed,</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">193</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7e5999caf959bcf6">
        <source>* There is no way to defer the commitment of the [*Body] type to after</source>
        <target state="needs-translation">* There is no way to defer the commitment of the [*Body] type to after</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">196</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="05e62f33a502a7d7">
        <source>* No stateful allocator support. This follows from the previous limitation</source>
        <target state="needs-translation">* No stateful allocator support. This follows from the previous limitation</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">200</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a632016d94c93c52">
        <source>* The trailers are stored in a separate object. Aside from the combinatorial</source>
        <target state="needs-translation">* The trailers are stored in a separate object. Aside from the combinatorial</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">204</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8ff26c41346593ad">
        <source>* The declarations imply that `std::vector` is a model of [*Body].</source>
        <target state="needs-translation">* The declarations imply that `std::vector` is a model of [*Body].</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">212</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0a96f524b6a903b5">
        <source>* The [*Body] customization point constrains user defined types to</source>
        <target state="needs-translation">* The [*Body] customization point constrains user defined types to</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">223</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8c3d5c10e67b081d">
        <source>This representation addresses a narrow range of  use cases. It has limited potential for customization and performance. It is more difficult to use because it excludes the start line fields from the model.</source>
        <target state="needs-translation">This representation addresses a narrow range of  use cases. It has limited potential for customization and performance. It is more difficult to use because it excludes the start line fields from the model.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">228</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1ba4318d6f1161a7">
        <source>C++ REST SDK (cpprestsdk)</source>
        <target state="needs-translation">C++ REST SDK (cpprestsdk)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">234</context>
        </context-group>
        <note from="developer">type: heading</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="909aa1439eecd313">
        <source>is a Microsoft project which ['"...aims to help C++ developers connect to and interact with services"]. It offers the most functionality of the libraries reviewed here, including support for Websocket services using its websocket++ dependency. It can use native APIs such as HTTP.SYS when building Windows based applications, and it can use Boost.Asio. The WebSocket module uses Boost.Asio exclusively.</source>
        <target state="needs-translation">is a Microsoft project which ['"...aims to help C++ developers connect to and interact with services"]. It offers the most functionality of the libraries reviewed here, including support for Websocket services using its websocket++ dependency. It can use native APIs such as HTTP.SYS when building Windows based applications, and it can use Boost.Asio. The WebSocket module uses Boost.Asio exclusively.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">237</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b320b78f6cf0710f">
        <source>As cpprestsdk is developed by a large corporation, it contains quite a bit of functionality and necessarily has more interfaces. We will break down the interfaces used to model messages into more manageable pieces. This is the container used to store the HTTP header fields: ``` class http_headers { public:</source>
        <target state="needs-translation">As cpprestsdk is developed by a large corporation, it contains quite a bit of functionality and necessarily has more interfaces. We will break down the interfaces used to model messages into more manageable pieces. This is the container used to store the HTTP header fields: ``` class http_headers { public:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">244</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="254">
        <source>private:</source>
        <target state="needs-translation">private:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">254</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="256">
        <source>}; ```</source>
        <target state="needs-translation">}; ```</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">256</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a1f08ea200d0161d">
        <source>This declaration is quite bare-bones. We note the typical problems of most field containers:</source>
        <target state="needs-translation">This declaration is quite bare-bones. We note the typical problems of most field containers:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">259</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="40c57198cfff2c19">
        <source>* The container may only be default-constructed.</source>
        <target state="needs-translation">* The container may only be default-constructed.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">262</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6de8eddee5633d27">
        <source>* No support for allocators, stateful or otherwise.</source>
        <target state="needs-translation">* No support for allocators, stateful or otherwise.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">264</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="157a48563e535572">
        <source>* There are no customization points at all.</source>
        <target state="needs-translation">* There are no customization points at all.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">266</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2dcaa2bbe1a426f2">
        <source>Now we analyze the structure of the larger message container. The library uses a handle/body idiom. There are two public message container interfaces, one for requests (`http_request`) and one for responses (`http_response`). Each interface maintains a private shared pointer to an implementation class. Public member function calls are routed to the internal implementation. This is the first implementation class, which forms the base class for both the request and response implementations: ``` namespace details {</source>
        <target state="needs-translation">Now we analyze the structure of the larger message container. The library uses a handle/body idiom. There are two public message container interfaces, one for requests (`http_request`) and one for responses (`http_response`). Each interface maintains a private shared pointer to an implementation class. Public member function calls are routed to the internal implementation. This is the first implementation class, which forms the base class for both the request and response implementations: ``` namespace details {</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">268</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7d7415e78e33f474">
        <source>class http_msg_base { public:</source>
        <target state="needs-translation">class http_msg_base { public:</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="0a758ffa86abf15a">
        <source>protected:</source>
        <target state="needs-translation">protected:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">294</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="306">
        <source>}; ```</source>
        <target state="needs-translation">}; ```</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">306</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="197fb0c4b41dce42">
        <source>To understand these declarations we need to first understand that cpprestsdk uses the asynchronous model defined by Microsoft's [@https://msdn.microsoft.com/en-us/library/dd504870.aspx [*Concurrency Runtime]]. Identifiers from the [@https://msdn.microsoft.com/en-us/library/jj987780.aspx [*`pplx` namespace]] define common asynchronous patterns such as tasks and events. The `concurrency::streams::istream` parameter and `m_data_available` data member indicates a lack of separation of concerns. The representation of HTTP messages should not be conflated with the asynchronous model used to serialize or parse those messages in the message declarations.</source>
        <target state="needs-translation">To understand these declarations we need to first understand that cpprestsdk uses the asynchronous model defined by Microsoft's [@https://msdn.microsoft.com/en-us/library/dd504870.aspx [*Concurrency Runtime]]. Identifiers from the [@https://msdn.microsoft.com/en-us/library/jj987780.aspx [*`pplx` namespace]] define common asynchronous patterns such as tasks and events. The `concurrency::streams::istream` parameter and `m_data_available` data member indicates a lack of separation of concerns. The representation of HTTP messages should not be conflated with the asynchronous model used to serialize or parse those messages in the message declarations.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">309</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f85d1e4ecc3cfbc6">
        <source>The next declaration forms the complete implementation class referenced by the handle in the public interface (which follows after): ``` /// Internal representation of an HTTP request message. class _http_request final : public http::details::http_msg_base, public std::enable_shared_from_this&lt;_http_request&gt; { public:</source>
        <target state="needs-translation">The next declaration forms the complete implementation class referenced by the handle in the public interface (which follows after): ``` /// Internal representation of an HTTP request message. class _http_request final : public http::details::http_msg_base, public std::enable_shared_from_this&lt;_http_request&gt; { public:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">319</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="336">
        <source>private:</source>
        <target state="needs-translation">private:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">336</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="344">
        <source>};</source>
        <target state="needs-translation">};</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">344</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0c970af7a38b31ec">
        <source>} // namespace details ```</source>
        <target state="needs-translation">} // namespace details ```</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">346</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="31423a6875f74f24">
        <source>As before, we note that the implementation class for HTTP requests concerns itself more with the mechanics of sending the message asynchronously than it does with actually modeling the HTTP message as described in __rfc7230__:</source>
        <target state="needs-translation">As before, we note that the implementation class for HTTP requests concerns itself more with the mechanics of sending the message asynchronously than it does with actually modeling the HTTP message as described in __rfc7230__:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">349</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a634eb7f0d67b291">
        <source>* The constructor accepting `std::unique_ptr&lt;http::details::_http_server_context`</source>
        <target state="needs-translation">* The constructor accepting `std::unique_ptr&lt;http::details::_http_server_context`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">353</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b87c0bd1a64039d5">
        <source>* The "cancellation token" is stored inside the message. This breaks the</source>
        <target state="needs-translation">* The "cancellation token" is stored inside the message. This breaks the</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">357</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ae12ae8e6c537262">
        <source>* The `_reply_impl` function implies that the message implementation also</source>
        <target state="needs-translation">* The `_reply_impl` function implies that the message implementation also</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">360</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="60e02f71b6ed8779">
        <source>Finally, here is the public class which represents an HTTP request: ``` class http_request { public:</source>
        <target state="needs-translation">Finally, here is the public class which represents an HTTP request: ``` class http_request { public:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">364</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="407">
        <source>private:</source>
        <target state="needs-translation">private:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">407</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="412">
        <source>}; ```</source>
        <target state="needs-translation">}; ```</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">412</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="871beb0f6a4f99a2">
        <source>It is clear from this declaration that the goal of the message model in this library is driven by its use-case (interacting with REST servers) and not to model HTTP messages generally. We note problems similar to the other declarations:</source>
        <target state="needs-translation">It is clear from this declaration that the goal of the message model in this library is driven by its use-case (interacting with REST servers) and not to model HTTP messages generally. We note problems similar to the other declarations:</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">415</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="fda4be3e18ec96ee">
        <source>* There are no compile-time customization points at all. The only</source>
        <target state="needs-translation">* There are no compile-time customization points at all. The only</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">420</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="091a244f3936f917">
        <source>* The extraction of the body is conflated with the asynchronous model.</source>
        <target state="needs-translation">* The extraction of the body is conflated with the asynchronous model.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">426</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="fd7877c28ecdba30">
        <source>* No way to define an allocator for the container used when extracting</source>
        <target state="needs-translation">* No way to define an allocator for the container used when extracting</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">428</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7b6a9e95a93e2b35">
        <source>* A body can only be extracted once, limiting the use of this container</source>
        <target state="needs-translation">* A body can only be extracted once, limiting the use of this container</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">431</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="dff25322d69eaf4b">
        <source>* Setting the body requires either a vector or a `concurrency::streams::istream`.</source>
        <target state="needs-translation">* Setting the body requires either a vector or a `concurrency::streams::istream`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">434</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a18dc6bf3f85c063">
        <source>* The HTTP request container conflates HTTP response behavior (see the</source>
        <target state="needs-translation">* The HTTP request container conflates HTTP response behavior (see the</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">437</context>
        </context-group>
        <note from="developer">type: list</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9f2a2913061338ee">
        <source>The general theme of the HTTP message model in cpprestsdk is "no user definable customizations". There is no allocator support, and no separation of concerns. It is designed to perform a specific set of behaviors. In other words, it does not follow the open/closed principle.</source>
        <target state="needs-translation">The general theme of the HTTP message model in cpprestsdk is "no user definable customizations". There is no allocator support, and no separation of concerns. It is designed to perform a specific set of behaviors. In other words, it does not follow the open/closed principle.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">442</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0ade5eb19b5651db">
        <source>Tasks in the Concurrency Runtime operate in a fashion similar to `std::future`, but with some improvements such as continuations which are not yet in the C++ standard. The costs of using a task based asynchronous interface instead of completion handlers is well documented: synchronization points along the call chain of composed task operations which cannot be optimized away. See: [@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3747.pdf [*A Universal Model for Asynchronous Operations]] (Kohlhoff).</source>
        <target state="needs-translation">Tasks in the Concurrency Runtime operate in a fashion similar to `std::future`, but with some improvements such as continuations which are not yet in the C++ standard. The costs of using a task based asynchronous interface instead of completion handlers is well documented: synchronization points along the call chain of composed task operations which cannot be optimized away. See: [@http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3747.pdf [*A Universal Model for Asynchronous Operations]] (Kohlhoff).</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">447</context>
        </context-group>
        <note from="developer">type: paragraph</note>
      </trans-unit>
    </body>
  </file>
</xliff>
