@@ -25,6 +25,23 @@ asynchronous.
2525As of 0.11 the `Synchronous Clients`_ are now *DEPRECATED* and will be removed
2626in subsequent releases.
2727
28+ Features
29+ --------
30+
31+ The HTTP client implementation supports requesting secure HTTP (HTTPS) content
32+ only in the following situations:
33+
34+ * **Client libraries are built with ``BOOST_NETWORK_ENABLE_HTTPS``.** This
35+ tells the implementation to use HTTPS-specific code to handle HTTPS-based
36+ content when making connections associated with HTTPS URI's. This requires
37+ a dependency on OpenSSL_.
38+ * **The ``BOOST_NETWORK_ENABLE_HTTPS`` macro is set when compiling user
39+ code.** It is best to define this either at compile-time of all code using
40+ the library, or before including any of the client headers.
41+
42+ .. _OpenSSL: http://www.openssl.org/
43+
44+
2845Implementations
2946---------------
3047
@@ -71,7 +88,7 @@ behave as a fully synchronous client.
7188
7289The synchronous client implements all the operations of the client underneath
7390the interface all block to wait for I/O to finish. All the member methods are
74- synchronous and will block until the response object is ready or throws iferros
91+ synchronous and will block until the response object is ready or throws iferrors
7592are encountered in the performance of the HTTP requests.
7693
7794.. warning:: The synchronous clients are **NOT** thread safe. You will need to do
@@ -126,6 +143,9 @@ operations on responses. In code, usage should look like the following:
126143
127144A common mistake is to declare the client inside the try block which invokes
128145undefined behavior when errors arise from the handling of response objects.
146+ Previous examples cited by the documentation showed the short version of the
147+ code which didn't bother moving the ``http::client`` object outside of the same
148+ ``try`` block where the request/response objects are being used.
129149
130150Member Functions
131151----------------
@@ -137,7 +157,7 @@ In this section we assume that the following typedef is in effect:
137157 typedef boost::network::http::basic_client<
138158 boost::network::http::tags::http_default_8bit_udp_resolve
139159 , 1
140- ,1
160+ , 1
141161 >
142162 client;
143163
@@ -290,6 +310,17 @@ and that there is an appropriately constructed response object named
290310 body chunks be handled by the ``callback`` parameter. The signature of
291311 ``callback`` should be the following: ``void(iterator_range<char const *> const
292312 &, boost::system::error_code const &)``.
313+ ``response_ = client_.post(request_, body, content_type, callback, streaming_callback)``
314+ The body and content_type parameters are of type
315+ ``boost::network::string<Tag>::type`` where ``Tag`` is the HTTP Client's
316+ ``Tag``. This uses the request object's other headers. Have the response
317+ body chunks be handled by the ``callback`` parameter. The signature of
318+ ``callback`` should be the following: ``void(iterator_range<char const *> const
319+ &, boost::system::error_code const &)``. The ``streaming_callback``
320+ argument should have a which has a signature of the form:
321+ ``bool(string_type&)``. The provided ``string_type&`` will be streamed as
322+ soon as the function returns. A return value of ``false`` signals the
323+ client that the most recent invocation is the last chunk to be sent.
293324``response_ = client_.post(request_, streaming_callback)``
294325 Perform and HTTP POST request, and have the request's body chunks be
295326 generated by the ``streaming_callback`` which has a signature of the form:
@@ -329,13 +360,25 @@ and that there is an appropriately constructed response object named
329360 The body and content_type parameters are of type
330361 ``boost::network::string<Tag>::type`` where ``Tag`` is the HTTP Client's
331362 ``Tag``. This uses the request object's other headers.
332- ``response_ = client_.put(request_, body, content_type,body_handler= callback)``
363+ ``response_ = client_.put(request_, body, content_type, callback)``
333364 The body and content_type parameters are of type
334365 ``boost::network::string<Tag>::type`` where ``Tag`` is the HTTP Client's
335366 ``Tag``. This uses the request object's other headers. Have the response
336367 body chunks be handled by the ``callback`` parameter. The signature of
337368 ``callback`` should be the following: ``void(iterator_range<char const *> const
338369 &, boost::system::error_code const &)``.
370+ ``response_ = client_.put(request_, body, content_type, callback, streaming_callback)``
371+ The body and content_type parameters are of type
372+ ``boost::network::string<Tag>::type`` where ``Tag`` is the HTTP Client's
373+ ``Tag``. This uses the request object's other headers. Have the response
374+ body chunks be handled by the ``callback`` parameter. The signature of
375+ ``callback`` should be the following: ``void(iterator_range<char const *> const
376+ &, boost::system::error_code const &)``. This form also has the request's body
377+ chunks be generated by the ``streaming_callback`` which has a signature of
378+ the form: ``bool(string_type&)``. The provided ``string_type&`` will be
379+ streamed as soon as the function returns. A return value of ``false``
380+ signals the client that the most recent invocation is the last chunk to be
381+ sent
339382``response_ = client_.put(request_, streaming_callback)``
340383 Perform and HTTP PUT request, and have the request's body chunks be
341384 generated by the ``streaming_callback`` which has a signature of the form: