@@ -14,10 +14,6 @@ use and embed in your own applications. All of the HTTP client implementations:
14
14
* **Assume that requests made are independent of each other. ** There currently
15
15
is no cookie or session management system built-in to cpp-netlib's HTTP client
16
16
implementations.
17
- * **Are header-only and are compiled-into your application. ** Future releases in
18
- case you want to upgrade the implementation you are using in your application
19
- will be distributed as header-only implementations, which means you have to
20
- re-compile your application to use a newer version of the implementations.
21
17
22
18
The HTTP clients all share the same API, but the internals are documented in
23
19
terms of what is different and what to expect with the different
@@ -26,6 +22,9 @@ implementations.
26
22
As of 0.9.1 the default implementation for the :mod: `cpp-netlib ` HTTP client is
27
23
asynchronous.
28
24
25
+ As of 0.11 the `Synchronous Clients `_ are now *DEPRECATED * and will be removed
26
+ in subsequent releases.
27
+
29
28
Implementations
30
29
---------------
31
30
@@ -78,6 +77,9 @@ are encountered in the performance of the HTTP requests.
78
77
.. warning :: The synchronous clients are **NOT** thread safe. You will need to do
79
78
external synchronization to use synchronous client implementations.
80
79
80
+ .. note :: As of version 0.11, all the synchronous client implementations are
81
+ deprecated. They will be removed in the next version of the library.
82
+
81
83
Asynchronous Clients
82
84
~~~~~~~~~~~~~~~~~~~~
83
85
@@ -151,6 +153,9 @@ Also, that code using the HTTP client will have use the following header:
151
153
inhibited by defining the ``BOOST_NETWORK_NO_LIB `` preprocessor macro before
152
154
including any cpp-netlib header.
153
155
156
+ .. note :: Starting version 0.11, cpp-netlib clients and server implementations
157
+ no longer support the ``BOOST_NETWORK_NO_LIB `` option.
158
+
154
159
Constructors
155
160
~~~~~~~~~~~~
156
161
@@ -264,6 +269,22 @@ and that there is an appropriately constructed response object named
264
269
body chunks be handled by the ``callback `` parameter. The signature of
265
270
``callback `` should be the following: ``void(iterator_range<char const *> const
266
271
&, boost::system::error_code const &) ``.
272
+ ``response_ = client_.post(request_, streaming_callback) ``
273
+ Perform and HTTP POST request, and have the request's body chunks be
274
+ generated by the ``streaming_callback `` which has a signature of the form:
275
+ ``bool(string_type&) ``. The provided ``string_type& `` will be streamed as
276
+ soon as the function returns. A return value of ``false `` signals the client
277
+ that the most recent invocation is the last chunk to be sent.
278
+ ``response_ = client_.post(request_, callback, streaming_callback) ``
279
+ Perform an HTTP POST request, and have the body chunks be handled by the
280
+ ``callback `` parameter. The signature of ``callback `` should be the
281
+ following: ``void(iterator_range<char const *> const &,
282
+ boost::system::error_code const &) ``. This form also has the request's body
283
+ chunks be generated by the ``streaming_callback `` which has a signature of
284
+ the form: ``bool(string_type&) ``. The provided ``string_type& `` will be
285
+ streamed as soon as the function returns. A return value of ``false ``
286
+ signals the client that the most recent invocation is the last chunk to be
287
+ sent.
267
288
``response_ = client_.put(request_) ``
268
289
Perform an HTTP PUT, use the data already set in the request object which
269
290
includes the headers, and the body.
@@ -294,6 +315,22 @@ and that there is an appropriately constructed response object named
294
315
body chunks be handled by the ``callback `` parameter. The signature of
295
316
``callback `` should be the following: ``void(iterator_range<char const *> const
296
317
&, boost::system::error_code const &) ``.
318
+ ``response_ = client_.put(request_, streaming_callback) ``
319
+ Perform and HTTP PUT request, and have the request's body chunks be
320
+ generated by the ``streaming_callback `` 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 client
323
+ that the most recent invocation is the last chunk to be sent.
324
+ ``response_ = client_.put(request_, callback, streaming_callback) ``
325
+ Perform an HTTP PUT request, and have the body chunks be handled by the
326
+ ``callback `` parameter. The signature of ``callback `` should be the
327
+ following: ``void(iterator_range<char const *> const &,
328
+ boost::system::error_code const &) ``. This form also has the request's body
329
+ chunks be generated by the ``streaming_callback `` which has a signature of
330
+ the form: ``bool(string_type&) ``. The provided ``string_type& `` will be
331
+ streamed as soon as the function returns. A return value of ``false ``
332
+ signals the client that the most recent invocation is the last chunk to be
333
+ sent.
297
334
``response_ = client_.delete_(request_) ``
298
335
Perform an HTTP DELETE request.
299
336
``response_ = client_.delete_(request_, body_handler=callback) ``
0 commit comments