Menu

[r108]: / branches / docs / libs / network / doc / http.qbk  Maximize  Restore  History

Download this file

113 lines (73 with data), 4.3 kB

[/
  (C) Copyright 2008 Glyn Matthews.
  Distributed under the Boost Software License, Version 1.0.
  (See accompanying file LICENSE_1_0.txt or copy at
  http://www.boost.org/LICENSE_1_0.txt).
]


[section:http HTTP]
The __cnl__ provides direct support for HTTP.  A motivating example will show how it's intended to work:

 #include <boost/network/protocol/http.hpp>
 #include <iostream>

 int
 main(int argc, char *argv[]) {
     using boost::network;

     http::request request("http://www.boost.org/");
     http::client client;
     http::response response = client.get(request);

     // print response headers
     headers_range<http::response>::type hdrs = headers(response);
     boost::range_iterator<headers_range<http::response>::type>::type
         it = boost::begin(hdrs), end = boost::end(hdrs);
     for (; it != end; ++it) {
         std::cout << it->first << ": " << it->second << std::endl;
     }

     // print response body
     std::cout << body(response) << std::endl;
     return 0;
 }


Before walking through exactly what is happening in this example, the principle components are described below:

[heading HTTP Request]

 #include <boost/network/protocol/http/request.hpp>

The [^request] encapsulates information about the request and the resource.

[heading HTTP Client]

 #include <boost/network/protocol/http/client.hpp>

The [^client] encapsulates the connection-mapping logic between the domain and the underlying socket.  Access to a resource is managed through the [^client] object.

[heading HTTP Response]

 #include <boost/network/protocol/http/response.hpp>

The [^response] encapsulates the data received from the server.

[heading Walkthrough]

 http::request request("http://www.boost.org/");

This line frames the request for the resource __boost_org__.  This is slightly different to what one would normally expect from a request type, but there are good reasons for this.  Consider a [^request] object as the base unit of data used to instruct the client what to do.

 http::client client;

Then a client is created that handles all HTTP requests and responses.

 http::response response = client.get(request);

The client performs the requests on the developer's behalf.  This might initially appear counter-intuitive, since the methods GET, POST, PUT and DELETE are associated with a request to an HTTP server.

There are several advantages to this design:

# A [^client] object manages the connection, unencumbering the developer with this task, allowing them to better craft requests;
# A [^request] can be used with any instance of the [^client] without binding the [^client] to any destination;
# By decoupling the method from the [^request] object it allows developers to create requests that may be re-used (e.g. perform a HEAD first; if the the headers don't fulfil a certain criteria, perform a GET using the same resource).

 // print response headers
 headers_range<http::response>::type hdrs = headers(response);
 boost::range_iterator<headers_range<http::response>::type>::type
     it = boost::begin(hdrs), end = boost::end(hdrs);
 for (; it != end; ++it) 
    std::cout << it->first << ": " << it->second << std::endl;
 }

 // print response body
 std::cout << body(response) << std::endl;

Once the request has been made, and the [^client] returns a [^response] object, the rest is simple.  This example outputs all the response headers and body, in this case just the Boost homepage.


[heading Using [^http::client]]

The [^http::client] supports the following operations:

* [^http::client::head]
* [^http::client::get]
* [^http::client::post]
* [^http::client::put]
* [^http::client::delete_]

HTTP features can be enabled by using constructor arguments:

* [^http::client(http::client::cache_resolved)]
* [^http::client(http::client::follow_redirect)]

[h5 [^http::client::cache_resolved]]
This argument enables the caching of resolved endpoints and prevents the client from resolving IP addresses of previously resolved hostnames.

[h5 [^http::client::follow_redirect(s)]]
[^http::client::follow_redirects] / [^http::client::follow_redirect] follow HTTP redirect(s) (300..307) by looking at the "Location" header provided by the response(s); headers present in the original request are preserved in the subsequent request(s).

[endsect]