2017-07-20 08:01:46 -07:00
|
|
|
//
|
2017-07-24 09:42:36 -07:00
|
|
|
// Copyright (c) 2016-2017 Vinnie Falco (vinnie dot falco at gmail dot com)
|
2017-07-20 08:01:46 -07:00
|
|
|
//
|
|
|
|
// 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)
|
|
|
|
//
|
2017-07-20 13:40:34 -07:00
|
|
|
// Official repository: https://github.com/boostorg/beast
|
|
|
|
//
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-20 13:40:34 -07:00
|
|
|
#ifndef BOOST_BEAST_WEBSOCKET_STREAM_HPP
|
|
|
|
#define BOOST_BEAST_WEBSOCKET_STREAM_HPP
|
|
|
|
|
|
|
|
#include <boost/beast/config.hpp>
|
|
|
|
#include <boost/beast/websocket/error.hpp>
|
|
|
|
#include <boost/beast/websocket/option.hpp>
|
2017-08-04 13:31:24 -07:00
|
|
|
#include <boost/beast/websocket/role.hpp>
|
2017-07-20 13:40:34 -07:00
|
|
|
#include <boost/beast/websocket/rfc6455.hpp>
|
|
|
|
#include <boost/beast/websocket/detail/frame.hpp>
|
|
|
|
#include <boost/beast/websocket/detail/hybi13.hpp>
|
|
|
|
#include <boost/beast/websocket/detail/mask.hpp>
|
|
|
|
#include <boost/beast/websocket/detail/pausation.hpp>
|
|
|
|
#include <boost/beast/websocket/detail/pmd_extension.hpp>
|
|
|
|
#include <boost/beast/websocket/detail/utf8_checker.hpp>
|
|
|
|
#include <boost/beast/core/async_result.hpp>
|
|
|
|
#include <boost/beast/core/static_buffer.hpp>
|
|
|
|
#include <boost/beast/core/string.hpp>
|
|
|
|
#include <boost/beast/core/detail/type_traits.hpp>
|
|
|
|
#include <boost/beast/http/empty_body.hpp>
|
|
|
|
#include <boost/beast/http/message.hpp>
|
|
|
|
#include <boost/beast/http/string_body.hpp>
|
|
|
|
#include <boost/beast/http/detail/type_traits.hpp>
|
|
|
|
#include <boost/beast/zlib/deflate_stream.hpp>
|
|
|
|
#include <boost/beast/zlib/inflate_stream.hpp>
|
2017-07-20 08:01:46 -07:00
|
|
|
#include <algorithm>
|
|
|
|
#include <cstdint>
|
2017-06-24 12:11:46 -07:00
|
|
|
#include <functional>
|
2017-07-20 08:01:46 -07:00
|
|
|
#include <limits>
|
2017-04-25 10:12:43 -07:00
|
|
|
#include <type_traits>
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-20 13:40:34 -07:00
|
|
|
namespace boost {
|
2017-07-20 08:01:46 -07:00
|
|
|
namespace beast {
|
|
|
|
namespace websocket {
|
|
|
|
|
2017-06-24 10:13:17 -07:00
|
|
|
namespace detail {
|
|
|
|
class frame_test;
|
|
|
|
}
|
|
|
|
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
/// The type of object holding HTTP Upgrade requests
|
2017-06-05 07:20:58 -07:00
|
|
|
using request_type = http::request<http::empty_body>;
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
/// The type of object holding HTTP Upgrade responses
|
2017-06-05 07:20:58 -07:00
|
|
|
using response_type = http::response<http::string_body>;
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-06-24 12:11:46 -07:00
|
|
|
/** The type of received control frame.
|
|
|
|
|
|
|
|
Values of this type are passed to the control frame
|
|
|
|
callback set using @ref stream::control_callback.
|
|
|
|
*/
|
|
|
|
enum class frame_type
|
|
|
|
{
|
|
|
|
/// A close frame was received
|
|
|
|
close,
|
|
|
|
|
|
|
|
/// A ping frame was received
|
|
|
|
ping,
|
|
|
|
|
|
|
|
/// A pong frame was received
|
|
|
|
pong
|
|
|
|
};
|
2017-06-24 10:13:17 -07:00
|
|
|
|
2017-07-20 08:01:46 -07:00
|
|
|
//--------------------------------------------------------------------
|
|
|
|
|
|
|
|
/** Provides message-oriented functionality using WebSocket.
|
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
The @ref stream class template provides asynchronous and blocking
|
2017-07-20 08:01:46 -07:00
|
|
|
message-oriented functionality necessary for clients and servers
|
|
|
|
to utilize the WebSocket protocol.
|
2017-04-27 17:21:57 -07:00
|
|
|
|
|
|
|
For asynchronous operations, the application must ensure
|
|
|
|
that they are are all performed within the same implicit
|
|
|
|
or explicit strand.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-06-20 21:28:17 -07:00
|
|
|
@par Thread Safety
|
|
|
|
@e Distinct @e objects: Safe.@n
|
|
|
|
@e Shared @e objects: Unsafe.
|
|
|
|
|
2017-07-20 08:01:46 -07:00
|
|
|
@par Example
|
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
To use the @ref stream template with an `ip::tcp::socket`,
|
|
|
|
you would write:
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
@code
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
websocket::stream<ip::tcp::socket> ws{io_service};
|
2017-07-20 08:01:46 -07:00
|
|
|
@endcode
|
|
|
|
Alternatively, you can write:
|
|
|
|
@code
|
2017-06-08 19:55:42 -07:00
|
|
|
ip::tcp::socket sock{io_service};
|
|
|
|
websocket::stream<ip::tcp::socket&> ws{sock};
|
2017-07-20 08:01:46 -07:00
|
|
|
@endcode
|
|
|
|
|
2017-06-20 21:28:17 -07:00
|
|
|
@tparam NextLayer The type representing the next layer, to which
|
|
|
|
data will be read and written during operations. For synchronous
|
|
|
|
operations, the type must support the @b SyncStream concept.
|
|
|
|
For asynchronous operations, the type must support the
|
|
|
|
@b AsyncStream concept.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-09-25 11:19:51 -04:00
|
|
|
@note A stream object must not be moved or destroyed while there
|
|
|
|
are pending asynchronous operations associated with it.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
@par Concepts
|
2017-05-10 12:03:00 -07:00
|
|
|
@b AsyncStream,
|
|
|
|
@b DynamicBuffer,
|
|
|
|
@b SyncStream
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
|
|
|
template<class NextLayer>
|
2017-06-24 10:13:17 -07:00
|
|
|
class stream
|
2017-07-20 08:01:46 -07:00
|
|
|
{
|
2017-06-24 10:13:17 -07:00
|
|
|
friend class detail::frame_test;
|
2016-05-15 16:22:25 -04:00
|
|
|
friend class stream_test;
|
2017-07-14 12:11:44 -07:00
|
|
|
friend class frame_test;
|
|
|
|
|
2017-07-15 17:05:24 -07:00
|
|
|
/* The read buffer has to be at least as large
|
|
|
|
as the largest possible control frame including
|
|
|
|
the frame header.
|
|
|
|
*/
|
|
|
|
static std::size_t constexpr max_control_frame_size = 2 + 8 + 4 + 125;
|
|
|
|
static std::size_t constexpr tcp_frame_size = 1536;
|
|
|
|
|
2017-07-14 12:11:44 -07:00
|
|
|
struct op {};
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-15 17:05:24 -07:00
|
|
|
// tokens are used to order reads and writes
|
|
|
|
class token
|
|
|
|
{
|
|
|
|
unsigned char id_ = 1;
|
|
|
|
explicit token(unsigned char id) : id_(id) {}
|
|
|
|
public:
|
|
|
|
token() = default;
|
|
|
|
token(token const&) = default;
|
|
|
|
operator bool() const { return id_ != 0; }
|
|
|
|
bool operator==(token const& t) { return id_ == t.id_; }
|
|
|
|
bool operator!=(token const& t) { return id_ != t.id_; }
|
|
|
|
token unique() { token t{id_++}; if(id_ == 0) ++id_; return t; }
|
|
|
|
void reset() { id_ = 0; }
|
|
|
|
};
|
|
|
|
|
2017-07-14 12:11:44 -07:00
|
|
|
using control_cb_type =
|
|
|
|
std::function<void(frame_type, string_view)>;
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-06-24 10:13:17 -07:00
|
|
|
// State information for the message being received
|
|
|
|
//
|
|
|
|
struct rd_t
|
|
|
|
{
|
2017-07-15 17:05:24 -07:00
|
|
|
detail::frame_header fh; // current frame header
|
|
|
|
detail::prepared_key key; // current stateful mask key
|
|
|
|
std::uint64_t size; // total size of current message so far
|
|
|
|
std::uint64_t remain; // message frame bytes left in current frame
|
2017-08-13 06:48:38 -07:00
|
|
|
detail::frame_streambuf fb; // to write control frames (during reads)
|
2017-07-15 17:05:24 -07:00
|
|
|
detail::utf8_checker utf8; // to validate utf8
|
|
|
|
|
|
|
|
// A small, circular buffer to read frame headers.
|
|
|
|
// This improves performance by avoiding small reads.
|
|
|
|
static_buffer<+tcp_frame_size> buf;
|
|
|
|
|
2017-06-24 10:13:17 -07:00
|
|
|
// opcode of current message being read
|
|
|
|
detail::opcode op;
|
|
|
|
|
|
|
|
// `true` if the next frame is a continuation.
|
|
|
|
bool cont;
|
|
|
|
|
2017-07-15 17:05:24 -07:00
|
|
|
bool done; // set when a message is done
|
2017-06-24 10:13:17 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
// State information for the message being sent
|
|
|
|
//
|
|
|
|
struct wr_t
|
|
|
|
{
|
|
|
|
// `true` if next frame is a continuation,
|
|
|
|
// `false` if next frame starts a new message
|
|
|
|
bool cont;
|
|
|
|
|
|
|
|
// `true` if this message should be auto-fragmented
|
|
|
|
// This gets set to the auto-fragment option at the beginning
|
|
|
|
// of sending a message, so that the option can be changed
|
|
|
|
// mid-send without affecting the current message.
|
|
|
|
bool autofrag;
|
|
|
|
|
|
|
|
// `true` if this message should be compressed.
|
|
|
|
// This gets set to the compress option at the beginning of
|
|
|
|
// of sending a message, so that the option can be changed
|
|
|
|
// mid-send without affecting the current message.
|
|
|
|
bool compress;
|
|
|
|
|
|
|
|
// Size of the write buffer.
|
|
|
|
// This gets set to the write buffer size option at the
|
|
|
|
// beginning of sending a message, so that the option can be
|
|
|
|
// changed mid-send without affecting the current message.
|
|
|
|
std::size_t buf_size;
|
|
|
|
|
|
|
|
// The write buffer. Used for compression and masking.
|
|
|
|
// The buffer is allocated or reallocated at the beginning of
|
|
|
|
// sending a message.
|
|
|
|
std::unique_ptr<std::uint8_t[]> buf;
|
2017-08-12 20:50:23 -07:00
|
|
|
|
|
|
|
detail::fh_streambuf fb;
|
2017-06-24 10:13:17 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
// State information for the permessage-deflate extension
|
|
|
|
struct pmd_t
|
|
|
|
{
|
|
|
|
// `true` if current read message is compressed
|
|
|
|
bool rd_set;
|
|
|
|
|
|
|
|
zlib::deflate_stream zo;
|
|
|
|
zlib::inflate_stream zi;
|
|
|
|
};
|
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
NextLayer stream_; // the wrapped stream
|
2017-07-14 12:11:44 -07:00
|
|
|
detail::maskgen maskgen_; // source of mask keys
|
|
|
|
std::size_t rd_msg_max_ =
|
|
|
|
16 * 1024 * 1024; // max message size
|
|
|
|
bool wr_autofrag_ = true; // auto fragment
|
|
|
|
std::size_t wr_buf_size_ = 4096; // write buffer size
|
|
|
|
std::size_t rd_buf_size_ = 4096; // read buffer size
|
|
|
|
detail::opcode wr_opcode_ =
|
|
|
|
detail::opcode::text; // outgoing message type
|
|
|
|
control_cb_type ctrl_cb_; // control callback
|
|
|
|
role_type role_; // server or client
|
|
|
|
bool failed_; // the connection failed
|
|
|
|
|
2017-07-14 12:22:37 -07:00
|
|
|
bool rd_close_; // read close frame
|
2017-07-14 12:11:44 -07:00
|
|
|
bool wr_close_; // sent close frame
|
2017-07-15 17:05:24 -07:00
|
|
|
token wr_block_; // op currenly writing
|
2017-08-13 10:59:23 -07:00
|
|
|
token rd_block_; // op currenly reading
|
2017-07-14 12:11:44 -07:00
|
|
|
|
|
|
|
ping_data* ping_data_; // where to put the payload
|
|
|
|
detail::pausation rd_op_; // paused read op
|
|
|
|
detail::pausation wr_op_; // paused write op
|
|
|
|
detail::pausation ping_op_; // paused ping op
|
|
|
|
detail::pausation close_op_; // paused close op
|
2017-08-13 10:59:23 -07:00
|
|
|
detail::pausation r_rd_op_; // paused read op (read)
|
|
|
|
detail::pausation r_close_op_; // paused close op (read)
|
2017-07-14 12:11:44 -07:00
|
|
|
close_reason cr_; // set from received close frame
|
|
|
|
rd_t rd_; // read state
|
|
|
|
wr_t wr_; // write state
|
|
|
|
|
2017-06-24 10:13:17 -07:00
|
|
|
// If not engaged, then permessage-deflate is not
|
|
|
|
// enabled for the currently active session.
|
|
|
|
std::unique_ptr<pmd_t> pmd_;
|
|
|
|
|
|
|
|
// Local options for permessage-deflate
|
|
|
|
permessage_deflate pmd_opts_;
|
|
|
|
|
|
|
|
// Offer for clients, negotiated result for servers
|
|
|
|
detail::pmd_offer pmd_config_;
|
|
|
|
|
2017-07-15 17:05:24 -07:00
|
|
|
token t_;
|
|
|
|
|
2017-07-20 08:01:46 -07:00
|
|
|
public:
|
|
|
|
/// The type of the next layer.
|
|
|
|
using next_layer_type =
|
|
|
|
typename std::remove_reference<NextLayer>::type;
|
|
|
|
|
|
|
|
/// The type of the lowest layer.
|
|
|
|
using lowest_layer_type =
|
2017-05-23 11:45:44 -07:00
|
|
|
typename get_lowest_layer<next_layer_type>::type;
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-14 12:11:44 -07:00
|
|
|
/** Destructor
|
|
|
|
|
|
|
|
Destroys the stream and all associated resources.
|
|
|
|
|
|
|
|
@note A stream object must not be destroyed while there
|
|
|
|
are pending asynchronous operations associated with it.
|
|
|
|
*/
|
|
|
|
~stream() = default;
|
|
|
|
|
2017-07-12 07:05:27 -07:00
|
|
|
/** Constructor
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-14 12:11:44 -07:00
|
|
|
If `NextLayer` is move constructible, this function
|
2016-04-30 13:00:33 -04:00
|
|
|
will move-construct a new stream from the existing stream.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-04-30 13:00:33 -04:00
|
|
|
@note The behavior of move assignment on or from streams
|
|
|
|
with active or pending operations is undefined.
|
|
|
|
*/
|
2017-07-20 08:01:46 -07:00
|
|
|
stream(stream&&) = default;
|
|
|
|
|
2017-07-12 07:05:27 -07:00
|
|
|
/** Assignment
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-06-12 05:01:24 -07:00
|
|
|
If `NextLayer` is move assignable, this function
|
|
|
|
will move-assign a new stream from the existing stream.
|
2016-04-30 13:00:33 -04:00
|
|
|
|
|
|
|
@note The behavior of move assignment on or from streams
|
|
|
|
with active or pending operations is undefined.
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
|
|
|
stream& operator=(stream&&) = default;
|
|
|
|
|
2017-06-12 05:01:24 -07:00
|
|
|
/** Constructor
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-15 16:22:25 -04:00
|
|
|
This constructor creates a websocket stream and initializes
|
2017-07-20 08:01:46 -07:00
|
|
|
the next layer object.
|
|
|
|
|
|
|
|
@throws Any exceptions thrown by the NextLayer constructor.
|
|
|
|
|
2016-05-15 16:22:25 -04:00
|
|
|
@param args The arguments to be passed to initialize the
|
2017-07-20 08:01:46 -07:00
|
|
|
next layer object. The arguments are forwarded to the next
|
|
|
|
layer's constructor.
|
|
|
|
*/
|
|
|
|
template<class... Args>
|
|
|
|
explicit
|
|
|
|
stream(Args&&... args);
|
|
|
|
|
2017-07-15 17:05:24 -07:00
|
|
|
//--------------------------------------------------------------------------
|
|
|
|
|
2017-06-12 05:01:24 -07:00
|
|
|
/** Return the `io_service` associated with the stream
|
2017-06-08 17:36:31 -07:00
|
|
|
|
2017-06-12 05:01:24 -07:00
|
|
|
This function may be used to obtain the `io_service` object
|
2017-06-08 18:03:10 -07:00
|
|
|
that the stream uses to dispatch handlers for asynchronous
|
|
|
|
operations.
|
2017-06-08 17:36:31 -07:00
|
|
|
|
2017-06-08 18:03:10 -07:00
|
|
|
@return A reference to the io_service object that the stream
|
2017-06-12 05:01:24 -07:00
|
|
|
will use to dispatch handlers.
|
2017-06-08 18:03:10 -07:00
|
|
|
*/
|
|
|
|
boost::asio::io_service&
|
|
|
|
get_io_service()
|
|
|
|
{
|
|
|
|
return stream_.get_io_service();
|
|
|
|
}
|
2017-06-08 17:36:31 -07:00
|
|
|
|
2017-06-12 05:01:24 -07:00
|
|
|
/** Get a reference to the next layer
|
2017-06-08 17:36:31 -07:00
|
|
|
|
2017-06-08 18:03:10 -07:00
|
|
|
This function returns a reference to the next layer
|
|
|
|
in a stack of stream layers.
|
2017-06-08 17:36:31 -07:00
|
|
|
|
2017-06-08 18:03:10 -07:00
|
|
|
@return A reference to the next layer in the stack of
|
2017-06-12 05:01:24 -07:00
|
|
|
stream layers.
|
2017-06-08 17:36:31 -07:00
|
|
|
*/
|
2017-06-08 18:03:10 -07:00
|
|
|
next_layer_type&
|
|
|
|
next_layer()
|
2017-06-08 17:36:31 -07:00
|
|
|
{
|
2017-07-27 15:40:10 -07:00
|
|
|
return stream_;
|
2017-06-08 17:36:31 -07:00
|
|
|
}
|
|
|
|
|
2017-06-12 05:01:24 -07:00
|
|
|
/** Get a reference to the next layer
|
2017-06-08 18:03:10 -07:00
|
|
|
|
|
|
|
This function returns a reference to the next layer in a
|
|
|
|
stack of stream layers.
|
|
|
|
|
|
|
|
@return A reference to the next layer in the stack of
|
2017-06-12 05:01:24 -07:00
|
|
|
stream layers.
|
2017-06-08 18:03:10 -07:00
|
|
|
*/
|
|
|
|
next_layer_type const&
|
|
|
|
next_layer() const
|
2017-06-08 17:36:31 -07:00
|
|
|
{
|
2017-07-27 15:40:10 -07:00
|
|
|
return stream_;
|
2017-06-08 18:03:10 -07:00
|
|
|
}
|
|
|
|
|
2017-06-12 05:01:24 -07:00
|
|
|
/** Get a reference to the lowest layer
|
2017-06-08 18:03:10 -07:00
|
|
|
|
|
|
|
This function returns a reference to the lowest layer
|
|
|
|
in a stack of stream layers.
|
|
|
|
|
|
|
|
@return A reference to the lowest layer in the stack of
|
2017-06-12 05:01:24 -07:00
|
|
|
stream layers.
|
2017-06-08 18:03:10 -07:00
|
|
|
*/
|
|
|
|
lowest_layer_type&
|
|
|
|
lowest_layer()
|
|
|
|
{
|
|
|
|
return stream_.lowest_layer();
|
|
|
|
}
|
|
|
|
|
2017-06-12 05:01:24 -07:00
|
|
|
/** Get a reference to the lowest layer
|
2017-06-08 18:03:10 -07:00
|
|
|
|
|
|
|
This function returns a reference to the lowest layer
|
|
|
|
in a stack of stream layers.
|
|
|
|
|
|
|
|
@return A reference to the lowest layer in the stack of
|
|
|
|
stream layers. Ownership is not transferred to the caller.
|
|
|
|
*/
|
|
|
|
lowest_layer_type const&
|
|
|
|
lowest_layer() const
|
|
|
|
{
|
|
|
|
return stream_.lowest_layer();
|
2017-06-08 17:36:31 -07:00
|
|
|
}
|
|
|
|
|
2017-07-15 17:05:24 -07:00
|
|
|
//--------------------------------------------------------------------------
|
|
|
|
//
|
|
|
|
// Observers
|
|
|
|
//
|
|
|
|
//--------------------------------------------------------------------------
|
|
|
|
|
|
|
|
/** Returns `true` if the latest message data indicates binary.
|
|
|
|
|
|
|
|
This function informs the caller of whether the last
|
|
|
|
received message frame represents a message with the
|
|
|
|
binary opcode.
|
|
|
|
|
|
|
|
If there is no last message frame, the return value is
|
|
|
|
undefined.
|
|
|
|
*/
|
|
|
|
bool
|
|
|
|
got_binary() const
|
|
|
|
{
|
|
|
|
return rd_.op == detail::opcode::binary;
|
|
|
|
}
|
|
|
|
|
|
|
|
/** Returns `true` if the latest message data indicates text.
|
|
|
|
|
|
|
|
This function informs the caller of whether the last
|
|
|
|
received message frame represents a message with the
|
|
|
|
text opcode.
|
|
|
|
|
|
|
|
If there is no last message frame, the return value is
|
|
|
|
undefined.
|
|
|
|
*/
|
|
|
|
bool
|
|
|
|
got_text() const
|
|
|
|
{
|
|
|
|
return ! got_binary();
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Returns `true` if the last completed read finished the current message.
|
|
|
|
bool
|
|
|
|
is_message_done() const
|
|
|
|
{
|
|
|
|
return rd_.done;
|
|
|
|
}
|
|
|
|
|
|
|
|
/** Returns the close reason received from the peer.
|
|
|
|
|
|
|
|
This is only valid after a read completes with error::closed.
|
|
|
|
*/
|
|
|
|
close_reason const&
|
|
|
|
reason() const
|
|
|
|
{
|
|
|
|
return cr_;
|
|
|
|
}
|
|
|
|
|
|
|
|
/** Returns a suggested maximum buffer size for the next call to read.
|
|
|
|
|
|
|
|
This function returns a reasonable upper limit on the number
|
|
|
|
of bytes for the size of the buffer passed in the next call
|
|
|
|
to read. The number is determined by the state of the current
|
|
|
|
frame and whether or not the permessage-deflate extension is
|
|
|
|
enabled.
|
|
|
|
|
2017-08-01 20:15:07 -07:00
|
|
|
@param initial_size A non-zero size representing the caller's
|
|
|
|
desired buffer size for when there is no information which may
|
|
|
|
be used to calculate a more specific value. For example, when
|
|
|
|
reading the first frame header of a message.
|
2017-07-15 17:05:24 -07:00
|
|
|
*/
|
|
|
|
std::size_t
|
|
|
|
read_size_hint(
|
|
|
|
std::size_t initial_size = +tcp_frame_size) const;
|
|
|
|
|
|
|
|
/** Returns a suggested maximum buffer size for the next call to read.
|
|
|
|
|
|
|
|
This function returns a reasonable upper limit on the number
|
|
|
|
of bytes for the size of the buffer passed in the next call
|
|
|
|
to read. The number is determined by the state of the current
|
|
|
|
frame and whether or not the permessage-deflate extension is
|
|
|
|
enabled.
|
|
|
|
|
|
|
|
@param buffer The buffer which will be used for reading. The
|
|
|
|
implementation will query the buffer to obtain the optimum
|
|
|
|
size of a subsequent call to `buffer.prepare` based on the
|
|
|
|
state of the current frame, if any.
|
|
|
|
*/
|
|
|
|
template<class DynamicBuffer
|
2017-07-20 13:40:34 -07:00
|
|
|
#if ! BOOST_BEAST_DOXYGEN
|
2017-07-15 17:05:24 -07:00
|
|
|
, class = typename std::enable_if<
|
|
|
|
! std::is_integral<DynamicBuffer>::value>::type
|
|
|
|
#endif
|
|
|
|
>
|
|
|
|
std::size_t
|
|
|
|
read_size_hint(
|
|
|
|
DynamicBuffer& buffer) const;
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------------
|
|
|
|
//
|
|
|
|
// Settings
|
|
|
|
//
|
|
|
|
//--------------------------------------------------------------------------
|
|
|
|
|
2016-10-24 18:41:25 -04:00
|
|
|
/// Set the permessage-deflate extension options
|
|
|
|
void
|
|
|
|
set_option(permessage_deflate const& o);
|
|
|
|
|
|
|
|
/// Get the permessage-deflate extension options
|
|
|
|
void
|
|
|
|
get_option(permessage_deflate& o)
|
|
|
|
{
|
|
|
|
o = pmd_opts_;
|
|
|
|
}
|
|
|
|
|
2017-06-08 18:03:10 -07:00
|
|
|
/** Set the automatic fragmentation option.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-06-08 18:03:10 -07:00
|
|
|
Determines if outgoing message payloads are broken up into
|
|
|
|
multiple pieces.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-06-08 18:03:10 -07:00
|
|
|
When the automatic fragmentation size is turned on, outgoing
|
|
|
|
message payloads are broken up into multiple frames no larger
|
|
|
|
than the write buffer size.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-06-08 18:03:10 -07:00
|
|
|
The default setting is to fragment messages.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-12 07:05:27 -07:00
|
|
|
@param value A `bool` indicating if auto fragmentation should be on.
|
2017-06-08 18:27:32 -07:00
|
|
|
|
2017-06-08 18:03:10 -07:00
|
|
|
@par Example
|
|
|
|
Setting the automatic fragmentation option:
|
|
|
|
@code
|
|
|
|
ws.auto_fragment(true);
|
|
|
|
@endcode
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
2017-06-08 18:03:10 -07:00
|
|
|
void
|
2017-07-12 07:05:27 -07:00
|
|
|
auto_fragment(bool value)
|
2017-07-20 08:01:46 -07:00
|
|
|
{
|
2017-07-12 07:05:27 -07:00
|
|
|
wr_autofrag_ = value;
|
2017-07-20 08:01:46 -07:00
|
|
|
}
|
|
|
|
|
2017-06-08 18:03:10 -07:00
|
|
|
/// Returns `true` if the automatic fragmentation option is set.
|
|
|
|
bool
|
|
|
|
auto_fragment() const
|
2017-07-20 08:01:46 -07:00
|
|
|
{
|
2017-06-08 18:03:10 -07:00
|
|
|
return wr_autofrag_;
|
2017-07-20 08:01:46 -07:00
|
|
|
}
|
|
|
|
|
2017-06-08 18:03:10 -07:00
|
|
|
/** Set the binary message option.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-06-08 18:03:10 -07:00
|
|
|
This controls whether or not outgoing message opcodes
|
|
|
|
are set to binary or text. The setting is only applied
|
|
|
|
at the start when a caller begins a new message. Changing
|
|
|
|
the opcode after a message is started will only take effect
|
|
|
|
after the current message being sent is complete.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-06-08 18:03:10 -07:00
|
|
|
The default setting is to send text messages.
|
|
|
|
|
2017-07-12 07:05:27 -07:00
|
|
|
@param value `true` if outgoing messages should indicate
|
2017-06-08 18:27:32 -07:00
|
|
|
binary, or `false` if they should indicate text.
|
|
|
|
|
2017-06-08 18:03:10 -07:00
|
|
|
@par Example
|
|
|
|
Setting the message type to binary.
|
|
|
|
@code
|
|
|
|
ws.binary(true);
|
|
|
|
@endcode
|
2017-06-08 18:27:32 -07:00
|
|
|
*/
|
2017-06-08 18:03:10 -07:00
|
|
|
void
|
2017-07-12 07:05:27 -07:00
|
|
|
binary(bool value)
|
2017-07-20 08:01:46 -07:00
|
|
|
{
|
2017-07-12 07:05:27 -07:00
|
|
|
wr_opcode_ = value ?
|
2017-06-08 21:01:35 -07:00
|
|
|
detail::opcode::binary :
|
|
|
|
detail::opcode::text;
|
2017-07-20 08:01:46 -07:00
|
|
|
}
|
|
|
|
|
2017-06-08 18:03:10 -07:00
|
|
|
/// Returns `true` if the binary message option is set.
|
|
|
|
bool
|
|
|
|
binary() const
|
2017-07-20 08:01:46 -07:00
|
|
|
{
|
2017-06-08 21:01:35 -07:00
|
|
|
return wr_opcode_ == detail::opcode::binary;
|
2017-07-20 08:01:46 -07:00
|
|
|
}
|
|
|
|
|
2017-07-28 12:04:55 -07:00
|
|
|
/** Set a callback to be invoked on each incoming control frame.
|
2017-06-08 19:28:12 -07:00
|
|
|
|
2017-06-24 12:11:46 -07:00
|
|
|
Sets the callback to be invoked whenever a ping, pong,
|
|
|
|
or close control frame is received during a call to one
|
|
|
|
of the following functions:
|
2017-06-08 19:28:12 -07:00
|
|
|
|
|
|
|
@li @ref beast::websocket::stream::read
|
2017-07-15 17:05:24 -07:00
|
|
|
@li @ref beast::websocket::stream::read_some
|
2017-06-08 19:28:12 -07:00
|
|
|
@li @ref beast::websocket::stream::async_read
|
2017-07-15 17:05:24 -07:00
|
|
|
@li @ref beast::websocket::stream::async_read_some
|
2017-06-08 19:28:12 -07:00
|
|
|
|
|
|
|
Unlike completion handlers, the callback will be invoked
|
2017-06-24 12:11:46 -07:00
|
|
|
for each control frame during a call to any synchronous
|
|
|
|
or asynchronous read function. The operation is passive,
|
|
|
|
with no associated error code, and triggered by reads.
|
2017-06-08 19:28:12 -07:00
|
|
|
|
2017-07-28 12:04:55 -07:00
|
|
|
For close frames, the close reason code may be obtained by
|
|
|
|
calling the function @ref reason.
|
|
|
|
|
|
|
|
@param cb The function object to call, which must be
|
|
|
|
invocable with this equivalent signature:
|
2017-06-08 19:28:12 -07:00
|
|
|
@code
|
|
|
|
void
|
|
|
|
callback(
|
2017-06-24 12:11:46 -07:00
|
|
|
frame_type kind, // The type of frame
|
|
|
|
string_view payload // The payload in the frame
|
2017-06-08 19:28:12 -07:00
|
|
|
);
|
|
|
|
@endcode
|
2017-07-28 12:04:55 -07:00
|
|
|
The implementation type-erases the callback without requiring
|
|
|
|
a dynamic allocation. For this reason, the callback object is
|
|
|
|
passed by a non-constant reference.
|
2017-06-24 12:11:46 -07:00
|
|
|
If the read operation which receives the control frame is
|
|
|
|
an asynchronous operation, the callback will be invoked using
|
2017-06-08 19:28:12 -07:00
|
|
|
the same method as that used to invoke the final handler.
|
|
|
|
|
2017-06-24 12:11:46 -07:00
|
|
|
@note It is not necessary to send a close frame upon receipt
|
|
|
|
of a close frame. The implementation does this automatically.
|
|
|
|
Attempting to send a close frame after a close frame is
|
|
|
|
received will result in undefined behavior.
|
2017-07-28 12:04:55 -07:00
|
|
|
*/
|
|
|
|
template<class Callback>
|
|
|
|
void
|
|
|
|
control_callback(Callback& cb)
|
|
|
|
{
|
|
|
|
// Callback may not be constant, caller is responsible for
|
|
|
|
// managing the lifetime of the callback. Copies are not made.
|
|
|
|
BOOST_STATIC_ASSERT(! std::is_const<Callback>::value);
|
|
|
|
|
|
|
|
ctrl_cb_ = std::ref(cb);
|
|
|
|
}
|
|
|
|
|
|
|
|
/** Reset the control frame callback.
|
2017-06-24 12:11:46 -07:00
|
|
|
|
2017-07-28 12:04:55 -07:00
|
|
|
This function removes any previously set control frame callback.
|
2017-06-08 19:28:12 -07:00
|
|
|
*/
|
|
|
|
void
|
2017-07-28 12:04:55 -07:00
|
|
|
control_callback()
|
2017-06-08 19:28:12 -07:00
|
|
|
{
|
2017-07-28 12:04:55 -07:00
|
|
|
ctrl_cb_ = {};
|
2017-06-08 19:28:12 -07:00
|
|
|
}
|
|
|
|
|
2017-06-08 18:22:25 -07:00
|
|
|
/** Set the maximum incoming message size option.
|
|
|
|
|
|
|
|
Sets the largest permissible incoming message size. Message
|
|
|
|
frame fields indicating a size that would bring the total
|
|
|
|
message size over this limit will cause a protocol failure.
|
|
|
|
|
|
|
|
The default setting is 16 megabytes. A value of zero indicates
|
|
|
|
a limit of the maximum value of a `std::uint64_t`.
|
|
|
|
|
|
|
|
@par Example
|
|
|
|
Setting the maximum read message size.
|
|
|
|
@code
|
|
|
|
ws.read_message_max(65536);
|
|
|
|
@endcode
|
|
|
|
|
2017-07-12 07:05:27 -07:00
|
|
|
@param amount The limit on the size of incoming messages.
|
2017-06-08 18:22:25 -07:00
|
|
|
*/
|
|
|
|
void
|
2017-07-12 07:05:27 -07:00
|
|
|
read_message_max(std::size_t amount)
|
2017-06-08 18:22:25 -07:00
|
|
|
{
|
2017-07-12 07:05:27 -07:00
|
|
|
rd_msg_max_ = amount;
|
2017-06-08 18:22:25 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Returns the maximum incoming message size setting.
|
|
|
|
std::size_t
|
|
|
|
read_message_max() const
|
|
|
|
{
|
|
|
|
return rd_msg_max_;
|
|
|
|
}
|
|
|
|
|
2017-06-08 18:27:32 -07:00
|
|
|
/** Set the write buffer size option.
|
|
|
|
|
|
|
|
Sets the size of the write buffer used by the implementation to
|
|
|
|
send frames. The write buffer is needed when masking payload data
|
|
|
|
in the client role, compressing frames, or auto-fragmenting message
|
|
|
|
data.
|
|
|
|
|
|
|
|
Lowering the size of the buffer can decrease the memory requirements
|
|
|
|
for each connection, while increasing the size of the buffer can reduce
|
|
|
|
the number of calls made to the next layer to write data.
|
|
|
|
|
|
|
|
The default setting is 4096. The minimum value is 8.
|
|
|
|
|
|
|
|
The write buffer size can only be changed when the stream is not
|
|
|
|
open. Undefined behavior results if the option is modified after a
|
|
|
|
successful WebSocket handshake.
|
|
|
|
|
|
|
|
@par Example
|
|
|
|
Setting the write buffer size.
|
|
|
|
@code
|
|
|
|
ws.write_buffer_size(8192);
|
|
|
|
@endcode
|
|
|
|
|
2017-07-12 07:05:27 -07:00
|
|
|
@param amount The size of the write buffer in bytes.
|
2017-06-08 18:27:32 -07:00
|
|
|
*/
|
|
|
|
void
|
2017-07-12 07:05:27 -07:00
|
|
|
write_buffer_size(std::size_t amount)
|
2017-06-08 18:27:32 -07:00
|
|
|
{
|
2017-07-12 07:05:27 -07:00
|
|
|
if(amount < 8)
|
2017-06-08 18:27:32 -07:00
|
|
|
BOOST_THROW_EXCEPTION(std::invalid_argument{
|
|
|
|
"write buffer size underflow"});
|
2017-07-12 07:05:27 -07:00
|
|
|
wr_buf_size_ = amount;
|
2017-06-08 18:27:32 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
/// Returns the size of the write buffer.
|
|
|
|
std::size_t
|
|
|
|
write_buffer_size() const
|
|
|
|
{
|
|
|
|
return wr_buf_size_;
|
|
|
|
}
|
|
|
|
|
2017-06-08 19:55:42 -07:00
|
|
|
/** Set the text message option.
|
|
|
|
|
|
|
|
This controls whether or not outgoing message opcodes
|
|
|
|
are set to binary or text. The setting is only applied
|
|
|
|
at the start when a caller begins a new message. Changing
|
|
|
|
the opcode after a message is started will only take effect
|
|
|
|
after the current message being sent is complete.
|
|
|
|
|
|
|
|
The default setting is to send text messages.
|
|
|
|
|
2017-07-12 07:05:27 -07:00
|
|
|
@param value `true` if outgoing messages should indicate
|
2017-06-08 19:55:42 -07:00
|
|
|
text, or `false` if they should indicate binary.
|
|
|
|
|
|
|
|
@par Example
|
|
|
|
Setting the message type to text.
|
|
|
|
@code
|
|
|
|
ws.text(true);
|
|
|
|
@endcode
|
|
|
|
*/
|
|
|
|
void
|
2017-07-12 07:05:27 -07:00
|
|
|
text(bool value)
|
2017-06-08 19:55:42 -07:00
|
|
|
{
|
2017-07-12 07:05:27 -07:00
|
|
|
wr_opcode_ = value ?
|
2017-06-08 21:01:35 -07:00
|
|
|
detail::opcode::text :
|
|
|
|
detail::opcode::binary;
|
2017-06-08 19:55:42 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Returns `true` if the text message option is set.
|
|
|
|
bool
|
|
|
|
text() const
|
|
|
|
{
|
2017-06-08 21:01:35 -07:00
|
|
|
return wr_opcode_ == detail::opcode::text;
|
2017-06-08 19:55:42 -07:00
|
|
|
}
|
|
|
|
|
2017-07-15 17:05:24 -07:00
|
|
|
//--------------------------------------------------------------------------
|
|
|
|
//
|
2017-07-27 15:40:10 -07:00
|
|
|
// Handshaking (Client)
|
2017-07-15 17:05:24 -07:00
|
|
|
//
|
|
|
|
//--------------------------------------------------------------------------
|
2017-06-08 19:55:42 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Send an HTTP WebSocket Upgrade request and receive the response.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to synchronously send the WebSocket
|
|
|
|
upgrade HTTP request. The call blocks until one of the
|
|
|
|
following conditions is true:
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The request is sent and the response is received.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li An error occurs on the stream
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is implemented in terms of one or more calls to the
|
|
|
|
next layer's `read_some` and `write_some` functions.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The operation is successful if the received HTTP response indicates
|
|
|
|
a successful HTTP Upgrade (represented by a Status-Code of 101,
|
|
|
|
"switching protocols").
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param host The name of the remote host,
|
|
|
|
required by the HTTP protocol.
|
|
|
|
|
|
|
|
@param target The Request Target, which may not be empty,
|
|
|
|
required by the HTTP protocol.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-10-04 18:00:11 -04:00
|
|
|
@throws system_error Thrown on failure.
|
2017-07-27 15:40:10 -07:00
|
|
|
|
|
|
|
@par Example
|
|
|
|
@code
|
|
|
|
websocket::stream<ip::tcp::socket> ws{io_service};
|
|
|
|
...
|
|
|
|
try
|
|
|
|
{
|
|
|
|
ws.handshake("localhost", "/");
|
|
|
|
}
|
|
|
|
catch(...)
|
|
|
|
{
|
|
|
|
// An error occurred.
|
|
|
|
}
|
|
|
|
@endcode
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
|
|
|
void
|
2017-07-27 15:40:10 -07:00
|
|
|
handshake(
|
|
|
|
string_view host,
|
|
|
|
string_view target);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Send an HTTP WebSocket Upgrade request and receive the response.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to synchronously send the WebSocket
|
|
|
|
upgrade HTTP request. The call blocks until one of the
|
|
|
|
following conditions is true:
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The request is sent and the response is received.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li An error occurs on the stream
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is implemented in terms of one or more calls to the
|
|
|
|
next layer's `read_some` and `write_some` functions.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The operation is successful if the received HTTP response indicates
|
|
|
|
a successful HTTP Upgrade (represented by a Status-Code of 101,
|
|
|
|
"switching protocols").
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param res The HTTP Upgrade response returned by the remote
|
|
|
|
endpoint.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param host The name of the remote host,
|
|
|
|
required by the HTTP protocol.
|
|
|
|
|
|
|
|
@param target The Request Target, which may not be empty,
|
|
|
|
required by the HTTP protocol.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@throws system_error Thrown on failure.
|
2017-07-27 15:40:10 -07:00
|
|
|
|
|
|
|
@par Example
|
|
|
|
@code
|
|
|
|
websocket::stream<ip::tcp::socket> ws{io_service};
|
|
|
|
...
|
|
|
|
try
|
|
|
|
{
|
|
|
|
response_type res;
|
|
|
|
ws.handshake(res, "localhost", "/");
|
|
|
|
}
|
|
|
|
catch(...)
|
|
|
|
{
|
|
|
|
// An error occurred.
|
|
|
|
}
|
|
|
|
@endcode
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
*/
|
|
|
|
void
|
2017-07-27 15:40:10 -07:00
|
|
|
handshake(
|
|
|
|
response_type& res,
|
|
|
|
string_view host,
|
|
|
|
string_view target);
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Send an HTTP WebSocket Upgrade request and receive the response.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to synchronously send the WebSocket
|
|
|
|
upgrade HTTP request. The call blocks until one of the
|
|
|
|
following conditions is true:
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The request is sent and the response is received.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li An error occurs on the stream
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is implemented in terms of one or more calls to the
|
|
|
|
next layer's `read_some` and `write_some` functions.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The operation is successful if the received HTTP response indicates
|
|
|
|
a successful HTTP Upgrade (represented by a Status-Code of 101,
|
|
|
|
"switching protocols").
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param host The name of the remote host,
|
|
|
|
required by the HTTP protocol.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param target The Request Target, which may not be empty,
|
|
|
|
required by the HTTP protocol.
|
|
|
|
|
|
|
|
@param decorator A function object which will be called to modify
|
|
|
|
the HTTP request object generated by the implementation. This
|
|
|
|
could be used to set the User-Agent field, subprotocols, or other
|
|
|
|
application or HTTP specific fields. The object will be called
|
|
|
|
with this equivalent signature:
|
|
|
|
@code void decorator(
|
|
|
|
request_type& req
|
|
|
|
); @endcode
|
|
|
|
|
|
|
|
@throws system_error Thrown on failure.
|
|
|
|
|
|
|
|
@par Example
|
|
|
|
@code
|
|
|
|
websocket::stream<ip::tcp::socket> ws{io_service};
|
|
|
|
...
|
|
|
|
try
|
|
|
|
{
|
|
|
|
ws.handshake("localhost", "/",
|
|
|
|
[](request_type& req)
|
|
|
|
{
|
|
|
|
req.set(field::user_agent, "Beast");
|
|
|
|
});
|
|
|
|
}
|
|
|
|
catch(...)
|
|
|
|
{
|
|
|
|
// An error occurred.
|
|
|
|
}
|
|
|
|
@endcode
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class RequestDecorator>
|
2017-07-20 08:01:46 -07:00
|
|
|
void
|
2017-07-27 15:40:10 -07:00
|
|
|
handshake_ex(
|
|
|
|
string_view host,
|
|
|
|
string_view target,
|
|
|
|
RequestDecorator const& decorator);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Send an HTTP WebSocket Upgrade request and receive the response.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to synchronously send the WebSocket
|
|
|
|
upgrade HTTP request. The call blocks until one of the
|
|
|
|
following conditions is true:
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The request is sent and the response is received.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li An error occurs on the stream
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is implemented in terms of one or more calls to the
|
|
|
|
next layer's `read_some` and `write_some` functions.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The operation is successful if the received HTTP response indicates
|
|
|
|
a successful HTTP Upgrade (represented by a Status-Code of 101,
|
|
|
|
"switching protocols").
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param res The HTTP Upgrade response returned by the remote
|
|
|
|
endpoint.
|
|
|
|
|
|
|
|
@param host The name of the remote host,
|
|
|
|
required by the HTTP protocol.
|
|
|
|
|
|
|
|
@param target The Request Target, which may not be empty,
|
|
|
|
required by the HTTP protocol.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@param decorator A function object which will be called to modify
|
2017-07-27 15:40:10 -07:00
|
|
|
the HTTP request object generated by the implementation. This
|
|
|
|
could be used to set the User-Agent field, subprotocols, or other
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
application or HTTP specific fields. The object will be called
|
|
|
|
with this equivalent signature:
|
|
|
|
@code void decorator(
|
2017-07-27 15:40:10 -07:00
|
|
|
request_type& req
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
); @endcode
|
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@throws system_error Thrown on failure.
|
|
|
|
|
|
|
|
@par Example
|
|
|
|
@code
|
|
|
|
websocket::stream<ip::tcp::socket> ws{io_service};
|
|
|
|
...
|
|
|
|
try
|
|
|
|
{
|
|
|
|
response_type res;
|
|
|
|
ws.handshake(res, "localhost", "/",
|
|
|
|
[](request_type& req)
|
|
|
|
{
|
|
|
|
req.set(field::user_agent, "Beast");
|
|
|
|
});
|
|
|
|
}
|
|
|
|
catch(...)
|
|
|
|
{
|
|
|
|
// An error occurred.
|
|
|
|
}
|
|
|
|
@endcode
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class RequestDecorator>
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
void
|
2017-07-27 15:40:10 -07:00
|
|
|
handshake_ex(
|
|
|
|
response_type& res,
|
|
|
|
string_view host,
|
|
|
|
string_view target,
|
|
|
|
RequestDecorator const& decorator);
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Send an HTTP WebSocket Upgrade request and receive the response.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to synchronously send the WebSocket
|
|
|
|
upgrade HTTP request. The call blocks until one of the
|
|
|
|
following conditions is true:
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The request is sent and the response is received.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li An error occurs on the stream
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is implemented in terms of one or more calls to the
|
|
|
|
next layer's `read_some` and `write_some` functions.
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The operation is successful if the received HTTP response indicates
|
|
|
|
a successful HTTP Upgrade (represented by a Status-Code of 101,
|
|
|
|
"switching protocols").
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param host The name of the remote host,
|
|
|
|
required by the HTTP protocol.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param target The Request Target, which may not be empty,
|
|
|
|
required by the HTTP protocol.
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param ec Set to indicate what error occurred, if any.
|
|
|
|
|
|
|
|
@par Example
|
|
|
|
@code
|
|
|
|
websocket::stream<ip::tcp::socket> ws{io_service};
|
|
|
|
...
|
|
|
|
error_code ec;
|
|
|
|
ws.handshake(host, target, ec);
|
|
|
|
if(ec)
|
|
|
|
{
|
|
|
|
// An error occurred.
|
|
|
|
}
|
|
|
|
@endcode
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
2017-04-25 10:12:43 -07:00
|
|
|
void
|
2017-07-27 15:40:10 -07:00
|
|
|
handshake(
|
|
|
|
string_view host,
|
|
|
|
string_view target,
|
|
|
|
error_code& ec);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Send an HTTP WebSocket Upgrade request and receive the response.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to synchronously send the WebSocket
|
|
|
|
upgrade HTTP request. The call blocks until one of the
|
|
|
|
following conditions is true:
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The request is sent and the response is received.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li An error occurs on the stream
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is implemented in terms of one or more calls to the
|
|
|
|
next layer's `read_some` and `write_some` functions.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The operation is successful if the received HTTP response indicates
|
|
|
|
a successful HTTP Upgrade (represented by a Status-Code of 101,
|
|
|
|
"switching protocols").
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param res The HTTP Upgrade response returned by the remote
|
|
|
|
endpoint. If `ec` is set, the returned value is undefined.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param host The name of the remote host,
|
|
|
|
required by the HTTP protocol.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param target The Request Target, which may not be empty,
|
|
|
|
required by the HTTP protocol.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param ec Set to indicate what error occurred, if any.
|
|
|
|
|
|
|
|
@par Example
|
|
|
|
@code
|
|
|
|
websocket::stream<ip::tcp::socket> ws{io_service};
|
|
|
|
...
|
|
|
|
error_code ec;
|
|
|
|
response_type res;
|
|
|
|
ws.handshake(res, host, target, ec);
|
|
|
|
if(ec)
|
|
|
|
{
|
|
|
|
// An error occurred.
|
|
|
|
}
|
|
|
|
@endcode
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
*/
|
|
|
|
void
|
2017-07-27 15:40:10 -07:00
|
|
|
handshake(
|
|
|
|
response_type& res,
|
|
|
|
string_view host,
|
|
|
|
string_view target,
|
|
|
|
error_code& ec);
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Send an HTTP WebSocket Upgrade request and receive the response.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to synchronously send the WebSocket
|
|
|
|
upgrade HTTP request. The call blocks until one of the
|
|
|
|
following conditions is true:
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The request is sent and the response is received.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li An error occurs on the stream
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is implemented in terms of one or more calls to the
|
|
|
|
next layer's `read_some` and `write_some` functions.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The operation is successful if the received HTTP response indicates
|
|
|
|
a successful HTTP Upgrade (represented by a Status-Code of 101,
|
|
|
|
"switching protocols").
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param host The name of the remote host,
|
|
|
|
required by the HTTP protocol.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param target The Request Target, which may not be empty,
|
|
|
|
required by the HTTP protocol.
|
|
|
|
|
|
|
|
@param decorator A function object which will be called to modify
|
|
|
|
the HTTP request object generated by the implementation. This
|
|
|
|
could be used to set the User-Agent field, subprotocols, or other
|
|
|
|
application or HTTP specific fields. The object will be called
|
|
|
|
with this equivalent signature:
|
|
|
|
@code void decorator(
|
|
|
|
request_type& req
|
|
|
|
); @endcode
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-04-25 10:12:43 -07:00
|
|
|
@param ec Set to indicate what error occurred, if any.
|
2017-07-27 15:40:10 -07:00
|
|
|
|
|
|
|
@par Example
|
|
|
|
@code
|
|
|
|
websocket::stream<ip::tcp::socket> ws{io_service};
|
|
|
|
...
|
|
|
|
error_code ec;
|
|
|
|
ws.handshake("localhost", "/",
|
|
|
|
[](request_type& req)
|
|
|
|
{
|
|
|
|
req.set(field::user_agent, "Beast");
|
|
|
|
},
|
|
|
|
ec);
|
|
|
|
if(ec)
|
|
|
|
{
|
|
|
|
// An error occurred.
|
|
|
|
}
|
|
|
|
@endcode
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class RequestDecorator>
|
2017-07-20 08:01:46 -07:00
|
|
|
void
|
2017-07-27 15:40:10 -07:00
|
|
|
handshake_ex(
|
|
|
|
string_view host,
|
|
|
|
string_view target,
|
|
|
|
RequestDecorator const& decorator,
|
2017-07-12 07:05:27 -07:00
|
|
|
error_code& ec);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Send an HTTP WebSocket Upgrade request and receive the response.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to synchronously send the WebSocket
|
|
|
|
upgrade HTTP request. The call blocks until one of the
|
|
|
|
following conditions is true:
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The request is sent and the response is received.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li An error occurs on the stream
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is implemented in terms of one or more calls to the
|
|
|
|
next layer's `read_some` and `write_some` functions.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The operation is successful if the received HTTP response indicates
|
|
|
|
a successful HTTP Upgrade (represented by a Status-Code of 101,
|
|
|
|
"switching protocols").
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param res The HTTP Upgrade response returned by the remote
|
|
|
|
endpoint.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param host The name of the remote host,
|
|
|
|
required by the HTTP protocol.
|
|
|
|
|
|
|
|
@param target The Request Target, which may not be empty,
|
|
|
|
required by the HTTP protocol.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@param decorator A function object which will be called to modify
|
2017-07-27 15:40:10 -07:00
|
|
|
the HTTP request object generated by the implementation. This
|
|
|
|
could be used to set the User-Agent field, subprotocols, or other
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
application or HTTP specific fields. The object will be called
|
|
|
|
with this equivalent signature:
|
|
|
|
@code void decorator(
|
2017-07-27 15:40:10 -07:00
|
|
|
request_type& req
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
); @endcode
|
|
|
|
|
|
|
|
@param ec Set to indicate what error occurred, if any.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@par Example
|
|
|
|
@code
|
|
|
|
websocket::stream<ip::tcp::socket> ws{io_service};
|
|
|
|
...
|
|
|
|
error_code ec;
|
|
|
|
response_type res;
|
|
|
|
ws.handshake(res, "localhost", "/",
|
|
|
|
[](request_type& req)
|
|
|
|
{
|
|
|
|
req.set(field::user_agent, "Beast");
|
|
|
|
},
|
|
|
|
ec);
|
|
|
|
if(ec)
|
|
|
|
{
|
|
|
|
// An error occurred.
|
|
|
|
}
|
|
|
|
@endcode
|
|
|
|
*/
|
|
|
|
template<class RequestDecorator>
|
|
|
|
void
|
|
|
|
handshake_ex(
|
|
|
|
response_type& res,
|
|
|
|
string_view host,
|
|
|
|
string_view target,
|
|
|
|
RequestDecorator const& decorator,
|
|
|
|
error_code& ec);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Start an asynchronous operation to send an upgrade request and receive the response.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to asynchronously send the HTTP WebSocket
|
|
|
|
upgrade request and receive the HTTP WebSocket Upgrade response.
|
|
|
|
This function call always returns immediately. The asynchronous
|
|
|
|
operation will continue until one of the following conditions is
|
|
|
|
true:
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The request is sent and the response is received.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li An error occurs on the stream
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This operation is implemented in terms of one or more calls to the
|
|
|
|
next layer's `async_read_some` and `async_write_some` functions, and
|
|
|
|
is known as a <em>composed operation</em>. The program must ensure
|
|
|
|
that the stream performs no other operations until this operation
|
|
|
|
completes.
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The operation is successful if the received HTTP response indicates
|
|
|
|
a successful HTTP Upgrade (represented by a Status-Code of 101,
|
|
|
|
"switching protocols").
|
|
|
|
|
|
|
|
@param host The name of the remote host, required by
|
|
|
|
the HTTP protocol. Copies may be made as needed.
|
|
|
|
|
|
|
|
@param target The Request Target, which may not be empty,
|
|
|
|
required by the HTTP protocol. Copies of this parameter may
|
|
|
|
be made as needed.
|
|
|
|
|
|
|
|
@param handler The handler to be called when the request completes.
|
|
|
|
Copies will be made of the handler as required. The equivalent
|
|
|
|
function signature of the handler must be:
|
|
|
|
@code void handler(
|
|
|
|
error_code const& ec // Result of operation
|
|
|
|
); @endcode
|
|
|
|
Regardless of whether the asynchronous operation completes
|
|
|
|
immediately or not, the handler will not be invoked from within
|
|
|
|
this function. Invocation of the handler will be performed in a
|
|
|
|
manner equivalent to using `boost::asio::io_service::post`.
|
2017-04-25 10:12:43 -07:00
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class HandshakeHandler>
|
|
|
|
#if BOOST_BEAST_DOXYGEN
|
|
|
|
void_or_deduced
|
|
|
|
#else
|
|
|
|
async_return_type<
|
|
|
|
HandshakeHandler, void(error_code)>
|
|
|
|
#endif
|
|
|
|
async_handshake(
|
|
|
|
string_view host,
|
|
|
|
string_view target,
|
|
|
|
HandshakeHandler&& handler);
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Start an asynchronous operation to send an upgrade request and receive the response.
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to asynchronously send the HTTP WebSocket
|
|
|
|
upgrade request and receive the HTTP WebSocket Upgrade response.
|
|
|
|
This function call always returns immediately. The asynchronous
|
|
|
|
operation will continue until one of the following conditions is
|
|
|
|
true:
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The request is sent and the response is received.
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li An error occurs on the stream
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This operation is implemented in terms of one or more calls to the
|
|
|
|
next layer's `async_read_some` and `async_write_some` functions, and
|
|
|
|
is known as a <em>composed operation</em>. The program must ensure
|
|
|
|
that the stream performs no other operations until this operation
|
|
|
|
completes.
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The operation is successful if the received HTTP response indicates
|
|
|
|
a successful HTTP Upgrade (represented by a Status-Code of 101,
|
|
|
|
"switching protocols").
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param res The HTTP Upgrade response returned by the remote
|
|
|
|
endpoint. The caller must ensure this object is valid for at
|
|
|
|
least until the completion handler is invoked.
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param host The name of the remote host, required by
|
|
|
|
the HTTP protocol. Copies may be made as needed.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param target The Request Target, which may not be empty,
|
|
|
|
required by the HTTP protocol. Copies of this parameter may
|
|
|
|
be made as needed.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param handler The handler to be called when the request completes.
|
|
|
|
Copies will be made of the handler as required. The equivalent
|
|
|
|
function signature of the handler must be:
|
|
|
|
@code void handler(
|
|
|
|
error_code const& ec // Result of operation
|
|
|
|
); @endcode
|
|
|
|
Regardless of whether the asynchronous operation completes
|
|
|
|
immediately or not, the handler will not be invoked from within
|
|
|
|
this function. Invocation of the handler will be performed in a
|
|
|
|
manner equivalent to using `boost::asio::io_service::post`.
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class HandshakeHandler>
|
|
|
|
#if BOOST_BEAST_DOXYGEN
|
|
|
|
void_or_deduced
|
|
|
|
#else
|
|
|
|
async_return_type<
|
|
|
|
HandshakeHandler, void(error_code)>
|
|
|
|
#endif
|
|
|
|
async_handshake(
|
|
|
|
response_type& res,
|
|
|
|
string_view host,
|
|
|
|
string_view target,
|
|
|
|
HandshakeHandler&& handler);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Start an asynchronous operation to send an upgrade request and receive the response.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to asynchronously send the HTTP WebSocket
|
|
|
|
upgrade request and receive the HTTP WebSocket Upgrade response.
|
|
|
|
This function call always returns immediately. The asynchronous
|
|
|
|
operation will continue until one of the following conditions is
|
|
|
|
true:
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The request is sent and the response is received.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li An error occurs on the stream
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This operation is implemented in terms of one or more calls to the
|
|
|
|
next layer's `async_read_some` and `async_write_some` functions, and
|
|
|
|
is known as a <em>composed operation</em>. The program must ensure
|
|
|
|
that the stream performs no other operations until this operation
|
|
|
|
completes.
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The operation is successful if the received HTTP response indicates
|
|
|
|
a successful HTTP Upgrade (represented by a Status-Code of 101,
|
|
|
|
"switching protocols").
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param host The name of the remote host, required by
|
|
|
|
the HTTP protocol. Copies may be made as needed.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param target The Request Target, which may not be empty,
|
|
|
|
required by the HTTP protocol. Copies of this parameter may
|
|
|
|
be made as needed.
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param decorator A function object which will be called to modify
|
|
|
|
the HTTP request object generated by the implementation. This
|
|
|
|
could be used to set the User-Agent field, subprotocols, or other
|
|
|
|
application or HTTP specific fields. The object will be called
|
|
|
|
with this equivalent signature:
|
|
|
|
@code void decorator(
|
|
|
|
request_type& req
|
|
|
|
); @endcode
|
|
|
|
|
|
|
|
@param handler The handler to be called when the request completes.
|
|
|
|
Copies will be made of the handler as required. The equivalent
|
|
|
|
function signature of the handler must be:
|
|
|
|
@code void handler(
|
|
|
|
error_code const& ec // Result of operation
|
|
|
|
); @endcode
|
|
|
|
Regardless of whether the asynchronous operation completes
|
|
|
|
immediately or not, the handler will not be invoked from within
|
|
|
|
this function. Invocation of the handler will be performed in a
|
|
|
|
manner equivalent to using `boost::asio::io_service::post`.
|
2017-04-25 10:12:43 -07:00
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class RequestDecorator, class HandshakeHandler>
|
|
|
|
#if BOOST_BEAST_DOXYGEN
|
|
|
|
void_or_deduced
|
|
|
|
#else
|
|
|
|
async_return_type<
|
|
|
|
HandshakeHandler, void(error_code)>
|
|
|
|
#endif
|
|
|
|
async_handshake_ex(
|
|
|
|
string_view host,
|
|
|
|
string_view target,
|
|
|
|
RequestDecorator const& decorator,
|
|
|
|
HandshakeHandler&& handler);
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Start an asynchronous operation to send an upgrade request and receive the response.
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to asynchronously send the HTTP WebSocket
|
|
|
|
upgrade request and receive the HTTP WebSocket Upgrade response.
|
|
|
|
This function call always returns immediately. The asynchronous
|
|
|
|
operation will continue until one of the following conditions is
|
|
|
|
true:
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The request is sent and the response is received.
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li An error occurs on the stream
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This operation is implemented in terms of one or more calls to the
|
|
|
|
next layer's `async_read_some` and `async_write_some` functions, and
|
|
|
|
is known as a <em>composed operation</em>. The program must ensure
|
|
|
|
that the stream performs no other operations until this operation
|
|
|
|
completes.
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The operation is successful if the received HTTP response indicates
|
|
|
|
a successful HTTP Upgrade (represented by a Status-Code of 101,
|
|
|
|
"switching protocols").
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param res The HTTP Upgrade response returned by the remote
|
|
|
|
endpoint. The caller must ensure this object is valid for at
|
|
|
|
least until the completion handler is invoked.
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param host The name of the remote host, required by
|
|
|
|
the HTTP protocol. Copies may be made as needed.
|
|
|
|
|
|
|
|
@param target The Request Target, which may not be empty,
|
|
|
|
required by the HTTP protocol. Copies of this parameter may
|
|
|
|
be made as needed.
|
2017-04-25 10:12:43 -07:00
|
|
|
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
@param decorator A function object which will be called to modify
|
2017-07-27 15:40:10 -07:00
|
|
|
the HTTP request object generated by the implementation. This
|
|
|
|
could be used to set the User-Agent field, subprotocols, or other
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
application or HTTP specific fields. The object will be called
|
|
|
|
with this equivalent signature:
|
|
|
|
@code void decorator(
|
2017-07-27 15:40:10 -07:00
|
|
|
request_type& req
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
); @endcode
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param handler The handler to be called when the request completes.
|
|
|
|
Copies will be made of the handler as required. The equivalent
|
|
|
|
function signature of the handler must be:
|
|
|
|
@code void handler(
|
|
|
|
error_code const& ec // Result of operation
|
|
|
|
); @endcode
|
|
|
|
Regardless of whether the asynchronous operation completes
|
|
|
|
immediately or not, the handler will not be invoked from within
|
|
|
|
this function. Invocation of the handler will be performed in a
|
|
|
|
manner equivalent to using `boost::asio::io_service::post`.
|
2017-04-25 10:12:43 -07:00
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class RequestDecorator, class HandshakeHandler>
|
|
|
|
#if BOOST_BEAST_DOXYGEN
|
|
|
|
void_or_deduced
|
|
|
|
#else
|
|
|
|
async_return_type<
|
|
|
|
HandshakeHandler, void(error_code)>
|
|
|
|
#endif
|
|
|
|
async_handshake_ex(
|
|
|
|
response_type& res,
|
|
|
|
string_view host,
|
|
|
|
string_view target,
|
|
|
|
RequestDecorator const& decorator,
|
|
|
|
HandshakeHandler&& handler);
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
//--------------------------------------------------------------------------
|
|
|
|
//
|
|
|
|
// Handshaking (Server)
|
|
|
|
//
|
|
|
|
//--------------------------------------------------------------------------
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Read and respond to a WebSocket HTTP Upgrade request.
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to synchronously read an HTTP WebSocket
|
|
|
|
Upgrade request and send the HTTP response. The call blocks
|
|
|
|
until one of the following conditions is true:
|
|
|
|
|
|
|
|
@li The request is received and the response finishes sending.
|
2017-04-25 10:12:43 -07:00
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
This function is implemented in terms of one or more calls to
|
|
|
|
the next layer's `read_some` and `write_some` functions.
|
2017-04-25 10:12:43 -07:00
|
|
|
|
|
|
|
If the stream receives a valid HTTP WebSocket Upgrade request,
|
|
|
|
an HTTP response is sent back indicating a successful upgrade.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
When this call returns, the stream is then ready to send and
|
|
|
|
receive WebSocket protocol frames and messages.
|
2017-07-27 15:40:10 -07:00
|
|
|
If the HTTP Upgrade request is invalid or cannot be satisfied,
|
|
|
|
an HTTP response is sent indicating the reason and status code
|
|
|
|
(typically 400, "Bad Request"). This counts as a failure.
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The implementation uses fixed size internal storage to
|
|
|
|
receive the request. If the request is too large, the error
|
|
|
|
@ref error::buffer_overflow will be indicated. Applications
|
|
|
|
that wish to receive larger requests should first read the
|
|
|
|
request using their own buffer and a suitable overload of
|
|
|
|
@ref http::read or @ref http::async_read, then call @ref accept
|
|
|
|
or @ref async_accept with the request.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@throws system_error Thrown on failure.
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
void
|
2017-07-27 15:40:10 -07:00
|
|
|
accept();
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Read and respond to a WebSocket HTTP Upgrade request.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to synchronously read an HTTP WebSocket
|
|
|
|
Upgrade request and send the HTTP response. The call blocks
|
|
|
|
until one of the following conditions is true:
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The request is received and the response finishes sending.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
@li An error occurs on the stream.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
This function is implemented in terms of one or more calls to
|
|
|
|
the next layer's `read_some` and `write_some` functions.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-04-25 10:12:43 -07:00
|
|
|
If the stream receives a valid HTTP WebSocket Upgrade request,
|
|
|
|
an HTTP response is sent back indicating a successful upgrade.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
When this call returns, the stream is then ready to send and
|
|
|
|
receive WebSocket protocol frames and messages.
|
2017-04-25 10:12:43 -07:00
|
|
|
If the HTTP Upgrade request is invalid or cannot be satisfied,
|
|
|
|
an HTTP response is sent indicating the reason and status code
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
(typically 400, "Bad Request"). This counts as a failure.
|
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The implementation uses fixed size internal storage to
|
|
|
|
receive the request. If the request is too large, the error
|
|
|
|
@ref error::buffer_overflow will be indicated. Applications
|
|
|
|
that wish to receive larger requests should first read the
|
|
|
|
request using their own buffer and a suitable overload of
|
|
|
|
@ref http::read or @ref http::async_read, then call @ref accept
|
|
|
|
or @ref async_accept with the request.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@param decorator A function object which will be called to modify
|
|
|
|
the HTTP response object delivered by the implementation. This
|
|
|
|
could be used to set the Server field, subprotocols, or other
|
|
|
|
application or HTTP specific fields. The object will be called
|
|
|
|
with this equivalent signature:
|
|
|
|
@code void decorator(
|
|
|
|
response_type& res
|
|
|
|
); @endcode
|
|
|
|
|
|
|
|
@throws system_error Thrown on failure.
|
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class ResponseDecorator>
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
void
|
2017-07-27 15:40:10 -07:00
|
|
|
accept_ex(ResponseDecorator const& decorator);
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Read and respond to a WebSocket HTTP Upgrade request.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to synchronously read an HTTP WebSocket
|
|
|
|
Upgrade request and send the HTTP response. The call blocks
|
|
|
|
until one of the following conditions is true:
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The request is received and the response finishes sending.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
|
|
|
This function is implemented in terms of one or more calls to
|
|
|
|
the next layer's `read_some` and `write_some` functions.
|
|
|
|
|
|
|
|
If the stream receives a valid HTTP WebSocket Upgrade request,
|
|
|
|
an HTTP response is sent back indicating a successful upgrade.
|
|
|
|
When this call returns, the stream is then ready to send and
|
|
|
|
receive WebSocket protocol frames and messages.
|
|
|
|
If the HTTP Upgrade request is invalid or cannot be satisfied,
|
|
|
|
an HTTP response is sent indicating the reason and status code
|
|
|
|
(typically 400, "Bad Request"). This counts as a failure.
|
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The implementation uses fixed size internal storage to
|
|
|
|
receive the request. If the request is too large, the error
|
|
|
|
@ref error::buffer_overflow will be indicated. Applications
|
|
|
|
that wish to receive larger requests should first read the
|
|
|
|
request using their own buffer and a suitable overload of
|
|
|
|
@ref http::read or @ref http::async_read, then call @ref accept
|
|
|
|
or @ref async_accept with the request.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@param ec Set to indicate what error occurred, if any.
|
|
|
|
*/
|
|
|
|
void
|
2017-07-27 15:40:10 -07:00
|
|
|
accept(error_code& ec);
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Read and respond to a WebSocket HTTP Upgrade request.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to synchronously read an HTTP WebSocket
|
|
|
|
Upgrade request and send the HTTP response. The call blocks
|
|
|
|
until one of the following conditions is true:
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The request is received and the response finishes sending.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
|
|
|
This function is implemented in terms of one or more calls to
|
|
|
|
the next layer's `read_some` and `write_some` functions.
|
|
|
|
|
|
|
|
If the stream receives a valid HTTP WebSocket Upgrade request,
|
|
|
|
an HTTP response is sent back indicating a successful upgrade.
|
|
|
|
When this call returns, the stream is then ready to send and
|
|
|
|
receive WebSocket protocol frames and messages.
|
|
|
|
If the HTTP Upgrade request is invalid or cannot be satisfied,
|
|
|
|
an HTTP response is sent indicating the reason and status code
|
|
|
|
(typically 400, "Bad Request"). This counts as a failure.
|
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The implementation uses fixed size internal storage to
|
|
|
|
receive the request. If the request is too large, the error
|
|
|
|
@ref error::buffer_overflow will be indicated. Applications
|
|
|
|
that wish to receive larger requests should first read the
|
|
|
|
request using their own buffer and a suitable overload of
|
|
|
|
@ref http::read or @ref http::async_read, then call @ref accept
|
|
|
|
or @ref async_accept with the request.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@param decorator A function object which will be called to modify
|
|
|
|
the HTTP response object delivered by the implementation. This
|
|
|
|
could be used to set the Server field, subprotocols, or other
|
|
|
|
application or HTTP specific fields. The object will be called
|
|
|
|
with this equivalent signature:
|
|
|
|
@code void decorator(
|
|
|
|
response_type& res
|
|
|
|
); @endcode
|
|
|
|
|
|
|
|
@param ec Set to indicate what error occurred, if any.
|
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class ResponseDecorator>
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
void
|
2017-07-27 15:40:10 -07:00
|
|
|
accept_ex(
|
|
|
|
ResponseDecorator const& decorator,
|
|
|
|
error_code& ec);
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Read and respond to a WebSocket HTTP Upgrade request.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to synchronously read an HTTP WebSocket
|
|
|
|
Upgrade request and send the HTTP response. The call blocks
|
|
|
|
until one of the following conditions is true:
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-06-03 18:40:28 -07:00
|
|
|
@li The request is received and the response finishes sending.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is implemented in terms of one or more calls to
|
|
|
|
the next layer's `read_some` and `write_some` functions.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
If the stream receives a valid HTTP WebSocket Upgrade request,
|
|
|
|
an HTTP response is sent back indicating a successful upgrade.
|
2017-07-27 15:40:10 -07:00
|
|
|
When this call returns, the stream is then ready to send and
|
|
|
|
receive WebSocket protocol frames and messages.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
If the HTTP Upgrade request is invalid or cannot be satisfied,
|
|
|
|
an HTTP response is sent indicating the reason and status code
|
2017-07-27 15:40:10 -07:00
|
|
|
(typically 400, "Bad Request"). This counts as a failure.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The implementation uses fixed size internal storage to
|
|
|
|
receive the request. If the request is too large, the error
|
|
|
|
@ref error::buffer_overflow will be indicated. Applications
|
|
|
|
that wish to receive larger requests should first read the
|
|
|
|
request using their own buffer and a suitable overload of
|
|
|
|
@ref http::read or @ref http::async_read, then call @ref accept
|
|
|
|
or @ref async_accept with the request.
|
|
|
|
|
|
|
|
@param buffers Caller provided data that has already been
|
|
|
|
received on the stream. The implementation will copy the
|
|
|
|
caller provided data before the function returns.
|
|
|
|
|
|
|
|
@throws system_error Thrown on failure.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class ConstBufferSequence>
|
2017-07-20 13:40:34 -07:00
|
|
|
#if BOOST_BEAST_DOXYGEN
|
2017-07-27 15:40:10 -07:00
|
|
|
void
|
2017-05-23 15:50:15 -07:00
|
|
|
#else
|
2017-07-27 15:40:10 -07:00
|
|
|
typename std::enable_if<! http::detail::is_header<
|
|
|
|
ConstBufferSequence>::value>::type
|
2017-05-23 15:50:15 -07:00
|
|
|
#endif
|
2017-07-27 15:40:10 -07:00
|
|
|
accept(ConstBufferSequence const& buffers);
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Read and respond to a WebSocket HTTP Upgrade request.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to synchronously read an HTTP WebSocket
|
|
|
|
Upgrade request and send the HTTP response. The call blocks
|
|
|
|
until one of the following conditions is true:
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-06-03 18:40:28 -07:00
|
|
|
@li The request is received and the response finishes sending.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is implemented in terms of one or more calls to
|
|
|
|
the next layer's `read_some` and `write_some` functions.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
If the stream receives a valid HTTP WebSocket Upgrade request,
|
|
|
|
an HTTP response is sent back indicating a successful upgrade.
|
2017-07-27 15:40:10 -07:00
|
|
|
When this call returns, the stream is then ready to send and
|
|
|
|
receive WebSocket protocol frames and messages.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
If the HTTP Upgrade request is invalid or cannot be satisfied,
|
|
|
|
an HTTP response is sent indicating the reason and status code
|
2017-07-27 15:40:10 -07:00
|
|
|
(typically 400, "Bad Request"). This counts as a failure.
|
|
|
|
|
|
|
|
The implementation uses fixed size internal storage to
|
|
|
|
receive the request. If the request is too large, the error
|
|
|
|
@ref error::buffer_overflow will be indicated. Applications
|
|
|
|
that wish to receive larger requests should first read the
|
|
|
|
request using their own buffer and a suitable overload of
|
|
|
|
@ref http::read or @ref http::async_read, then call @ref accept
|
|
|
|
or @ref async_accept with the request.
|
|
|
|
|
|
|
|
@param buffers Caller provided data that has already been
|
|
|
|
received on the stream. The implementation will copy the
|
|
|
|
caller provided data before the function returns.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@param decorator A function object which will be called to modify
|
|
|
|
the HTTP response object delivered by the implementation. This
|
|
|
|
could be used to set the Server field, subprotocols, or other
|
|
|
|
application or HTTP specific fields. The object will be called
|
|
|
|
with this equivalent signature:
|
|
|
|
@code void decorator(
|
|
|
|
response_type& res
|
|
|
|
); @endcode
|
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@throws system_error Thrown on failure.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class ConstBufferSequence,
|
|
|
|
class ResponseDecorator>
|
2017-07-20 13:40:34 -07:00
|
|
|
#if BOOST_BEAST_DOXYGEN
|
2017-07-27 15:40:10 -07:00
|
|
|
void
|
2017-05-23 15:50:15 -07:00
|
|
|
#else
|
2017-07-27 15:40:10 -07:00
|
|
|
typename std::enable_if<! http::detail::is_header<
|
|
|
|
ConstBufferSequence>::value>::type
|
2017-05-23 15:50:15 -07:00
|
|
|
#endif
|
2017-07-27 15:40:10 -07:00
|
|
|
accept_ex(
|
|
|
|
ConstBufferSequence const& buffers,
|
|
|
|
ResponseDecorator const& decorator);
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Read and respond to a WebSocket HTTP Upgrade request.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to synchronously read an HTTP WebSocket
|
|
|
|
Upgrade request and send the HTTP response. The call blocks
|
|
|
|
until one of the following conditions is true:
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-06-03 18:40:28 -07:00
|
|
|
@li The request is received and the response finishes sending.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is implemented in terms of one or more calls to
|
|
|
|
the next layer's `read_some` and `write_some` functions.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
If the stream receives a valid HTTP WebSocket Upgrade request,
|
|
|
|
an HTTP response is sent back indicating a successful upgrade.
|
2017-07-27 15:40:10 -07:00
|
|
|
When this call returns, the stream is then ready to send and
|
|
|
|
receive WebSocket protocol frames and messages.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
If the HTTP Upgrade request is invalid or cannot be satisfied,
|
|
|
|
an HTTP response is sent indicating the reason and status code
|
2017-07-27 15:40:10 -07:00
|
|
|
(typically 400, "Bad Request"). This counts as a failure.
|
|
|
|
|
|
|
|
The implementation uses fixed size internal storage to
|
|
|
|
receive the request. If the request is too large, the error
|
|
|
|
@ref error::buffer_overflow will be indicated. Applications
|
|
|
|
that wish to receive larger requests should first read the
|
|
|
|
request using their own buffer and a suitable overload of
|
|
|
|
@ref http::read or @ref http::async_read, then call @ref accept
|
|
|
|
or @ref async_accept with the request.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@param buffers Caller provided data that has already been
|
2017-07-27 15:40:10 -07:00
|
|
|
received on the stream. The implementation will copy the
|
|
|
|
caller provided data before the function returns.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param ec Set to indicate what error occurred, if any.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class ConstBufferSequence>
|
2017-07-20 13:40:34 -07:00
|
|
|
#if BOOST_BEAST_DOXYGEN
|
2017-07-27 15:40:10 -07:00
|
|
|
void
|
|
|
|
#else
|
|
|
|
typename std::enable_if<! http::detail::is_header<
|
|
|
|
ConstBufferSequence>::value>::type
|
2017-05-23 15:50:15 -07:00
|
|
|
#endif
|
2017-07-27 15:40:10 -07:00
|
|
|
accept(
|
|
|
|
ConstBufferSequence const& buffers,
|
|
|
|
error_code& ec);
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Read and respond to a WebSocket HTTP Upgrade request.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to synchronously read an HTTP WebSocket
|
|
|
|
Upgrade request and send the HTTP response. The call blocks
|
|
|
|
until one of the following conditions is true:
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-06-03 18:40:28 -07:00
|
|
|
@li The request is received and the response finishes sending.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is implemented in terms of one or more calls to
|
|
|
|
the next layer's `read_some` and `write_some` functions.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
If the stream receives a valid HTTP WebSocket Upgrade request,
|
|
|
|
an HTTP response is sent back indicating a successful upgrade.
|
2017-07-27 15:40:10 -07:00
|
|
|
When this call returns, the stream is then ready to send and
|
|
|
|
receive WebSocket protocol frames and messages.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
If the HTTP Upgrade request is invalid or cannot be satisfied,
|
|
|
|
an HTTP response is sent indicating the reason and status code
|
2017-07-27 15:40:10 -07:00
|
|
|
(typically 400, "Bad Request"). This counts as a failure.
|
|
|
|
|
|
|
|
The implementation uses fixed size internal storage to
|
|
|
|
receive the request. If the request is too large, the error
|
|
|
|
@ref error::buffer_overflow will be indicated. Applications
|
|
|
|
that wish to receive larger requests should first read the
|
|
|
|
request using their own buffer and a suitable overload of
|
|
|
|
@ref http::read or @ref http::async_read, then call @ref accept
|
|
|
|
or @ref async_accept with the request.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@param buffers Caller provided data that has already been
|
2017-07-27 15:40:10 -07:00
|
|
|
received on the stream. The implementation will copy the
|
|
|
|
caller provided data before the function returns.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@param decorator A function object which will be called to modify
|
|
|
|
the HTTP response object delivered by the implementation. This
|
|
|
|
could be used to set the Server field, subprotocols, or other
|
|
|
|
application or HTTP specific fields. The object will be called
|
|
|
|
with this equivalent signature:
|
|
|
|
@code void decorator(
|
|
|
|
response_type& res
|
|
|
|
); @endcode
|
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param ec Set to indicate what error occurred, if any.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class ConstBufferSequence, class ResponseDecorator>
|
2017-07-20 13:40:34 -07:00
|
|
|
#if BOOST_BEAST_DOXYGEN
|
2017-07-27 15:40:10 -07:00
|
|
|
void
|
2017-05-23 15:50:15 -07:00
|
|
|
#else
|
2017-07-27 15:40:10 -07:00
|
|
|
typename std::enable_if<! http::detail::is_header<
|
|
|
|
ConstBufferSequence>::value>::type
|
2017-05-23 15:50:15 -07:00
|
|
|
#endif
|
2017-07-27 15:40:10 -07:00
|
|
|
accept_ex(
|
|
|
|
ConstBufferSequence const& buffers,
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
ResponseDecorator const& decorator,
|
2017-07-27 15:40:10 -07:00
|
|
|
error_code& ec);
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Respond to a WebSocket HTTP Upgrade request
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to synchronously send the HTTP response
|
|
|
|
to an HTTP request possibly containing a WebSocket Upgrade.
|
|
|
|
The call blocks until one of the following conditions is true:
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-06-03 18:40:28 -07:00
|
|
|
@li The response finishes sending.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is implemented in terms of one or more calls to
|
|
|
|
the next layer's `read_some` and `write_some` functions.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
If the stream receives a valid HTTP WebSocket Upgrade request,
|
|
|
|
an HTTP response is sent back indicating a successful upgrade.
|
2017-07-27 15:40:10 -07:00
|
|
|
When this call returns, the stream is then ready to send and
|
|
|
|
receive WebSocket protocol frames and messages.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
If the HTTP Upgrade request is invalid or cannot be satisfied,
|
|
|
|
an HTTP response is sent indicating the reason and status code
|
2017-07-27 15:40:10 -07:00
|
|
|
(typically 400, "Bad Request"). This counts as a failure.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@param req An object containing the HTTP Upgrade request.
|
2017-07-27 15:40:10 -07:00
|
|
|
Ownership is not transferred, the implementation will not
|
|
|
|
access this object from other threads.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@throws system_error Thrown on failure.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class Body, class Allocator>
|
|
|
|
void
|
|
|
|
accept(http::request<Body,
|
|
|
|
http::basic_fields<Allocator>> const& req);
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Respond to a WebSocket HTTP Upgrade request
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to synchronously send the HTTP response
|
|
|
|
to an HTTP request possibly containing a WebSocket Upgrade.
|
|
|
|
The call blocks until one of the following conditions is true:
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-06-03 18:40:28 -07:00
|
|
|
@li The response finishes sending.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is implemented in terms of one or more calls to
|
|
|
|
the next layer's `read_some` and `write_some` functions.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
If the stream receives a valid HTTP WebSocket Upgrade request,
|
|
|
|
an HTTP response is sent back indicating a successful upgrade.
|
2017-07-27 15:40:10 -07:00
|
|
|
When this call returns, the stream is then ready to send and
|
|
|
|
receive WebSocket protocol frames and messages.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
If the HTTP Upgrade request is invalid or cannot be satisfied,
|
|
|
|
an HTTP response is sent indicating the reason and status code
|
2017-07-27 15:40:10 -07:00
|
|
|
(typically 400, "Bad Request"). This counts as a failure.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@param req An object containing the HTTP Upgrade request.
|
2017-07-27 15:40:10 -07:00
|
|
|
Ownership is not transferred, the implementation will not
|
|
|
|
access this object from other threads.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@param decorator A function object which will be called to modify
|
|
|
|
the HTTP response object delivered by the implementation. This
|
|
|
|
could be used to set the Server field, subprotocols, or other
|
|
|
|
application or HTTP specific fields. The object will be called
|
|
|
|
with this equivalent signature:
|
|
|
|
@code void decorator(
|
|
|
|
response_type& res
|
|
|
|
); @endcode
|
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@throws system_error Thrown on failure.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
*/
|
2017-07-14 13:00:09 -07:00
|
|
|
template<class Body, class Allocator,
|
2017-07-27 15:40:10 -07:00
|
|
|
class ResponseDecorator>
|
|
|
|
void
|
|
|
|
accept_ex(http::request<Body,
|
2017-06-19 13:01:59 -07:00
|
|
|
http::basic_fields<Allocator>> const& req,
|
2017-07-27 15:40:10 -07:00
|
|
|
ResponseDecorator const& decorator);
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Respond to a WebSocket HTTP Upgrade request
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to synchronously send the HTTP response
|
|
|
|
to an HTTP request possibly containing a WebSocket Upgrade.
|
|
|
|
The call blocks until one of the following conditions is true:
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-06-03 18:40:28 -07:00
|
|
|
@li The response finishes sending.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is implemented in terms of one or more calls to
|
|
|
|
the next layer's `read_some` and `write_some` functions.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
If the stream receives a valid HTTP WebSocket Upgrade request,
|
|
|
|
an HTTP response is sent back indicating a successful upgrade.
|
2017-07-27 15:40:10 -07:00
|
|
|
When this call returns, the stream is then ready to send and
|
|
|
|
receive WebSocket protocol frames and messages.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
If the HTTP Upgrade request is invalid or cannot be satisfied,
|
|
|
|
an HTTP response is sent indicating the reason and status code
|
2017-07-27 15:40:10 -07:00
|
|
|
(typically 400, "Bad Request"). This counts as a failure.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@param req An object containing the HTTP Upgrade request.
|
2017-07-27 15:40:10 -07:00
|
|
|
Ownership is not transferred, the implementation will not
|
|
|
|
access this object from other threads.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param ec Set to indicate what error occurred, if any.
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class Body, class Allocator>
|
|
|
|
void
|
|
|
|
accept(http::request<Body,
|
2017-06-19 13:01:59 -07:00
|
|
|
http::basic_fields<Allocator>> const& req,
|
2017-07-27 15:40:10 -07:00
|
|
|
error_code& ec);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Respond to a WebSocket HTTP Upgrade request
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to synchronously send the HTTP response
|
|
|
|
to an HTTP request possibly containing a WebSocket Upgrade.
|
|
|
|
The call blocks until one of the following conditions is true:
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-06-03 18:40:28 -07:00
|
|
|
@li The response finishes sending.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
@li An error occurs on the stream.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is implemented in terms of one or more calls to
|
|
|
|
the next layer's `read_some` and `write_some` functions.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-04-25 10:12:43 -07:00
|
|
|
If the stream receives a valid HTTP WebSocket Upgrade request,
|
|
|
|
an HTTP response is sent back indicating a successful upgrade.
|
2017-07-27 15:40:10 -07:00
|
|
|
When this call returns, the stream is then ready to send and
|
|
|
|
receive WebSocket protocol frames and messages.
|
2017-04-25 10:12:43 -07:00
|
|
|
If the HTTP Upgrade request is invalid or cannot be satisfied,
|
|
|
|
an HTTP response is sent indicating the reason and status code
|
2017-07-27 15:40:10 -07:00
|
|
|
(typically 400, "Bad Request"). This counts as a failure.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-04-25 10:12:43 -07:00
|
|
|
@param req An object containing the HTTP Upgrade request.
|
2017-07-27 15:40:10 -07:00
|
|
|
Ownership is not transferred, the implementation will not
|
|
|
|
access this object from other threads.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@param decorator A function object which will be called to modify
|
|
|
|
the HTTP response object delivered by the implementation. This
|
|
|
|
could be used to set the Server field, subprotocols, or other
|
|
|
|
application or HTTP specific fields. The object will be called
|
|
|
|
with this equivalent signature:
|
|
|
|
@code void decorator(
|
|
|
|
response_type& res
|
|
|
|
); @endcode
|
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param ec Set to indicate what error occurred, if any.
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class Body, class Allocator,
|
|
|
|
class ResponseDecorator>
|
|
|
|
void
|
|
|
|
accept_ex(http::request<Body,
|
|
|
|
http::basic_fields<Allocator>> const& req,
|
|
|
|
ResponseDecorator const& decorator,
|
|
|
|
error_code& ec);
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Respond to a WebSocket HTTP Upgrade request
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to synchronously send the HTTP response
|
|
|
|
to an HTTP request possibly containing a WebSocket Upgrade.
|
|
|
|
The call blocks until one of the following conditions is true:
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The response finishes sending.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li An error occurs on the stream.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is implemented in terms of one or more calls to
|
|
|
|
the next layer's `read_some` and `write_some` functions.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
If the stream receives a valid HTTP WebSocket Upgrade request,
|
|
|
|
an HTTP response is sent back indicating a successful upgrade.
|
|
|
|
When this call returns, the stream is then ready to send and
|
|
|
|
receive WebSocket protocol frames and messages.
|
|
|
|
If the HTTP Upgrade request is invalid or cannot be satisfied,
|
|
|
|
an HTTP response is sent indicating the reason and status code
|
|
|
|
(typically 400, "Bad Request"). This counts as a failure.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The implementation uses fixed size internal storage to
|
|
|
|
copy the buffer. If the buffer is too large, the error
|
|
|
|
@ref error::buffer_overflow will be indicated. Applications
|
|
|
|
that wish to supply larger buffers should wrap the next layer
|
|
|
|
in a @ref buffered_read_stream and store the buffer contents in
|
|
|
|
the wrapper before calling accept.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param req An object containing the HTTP Upgrade request.
|
|
|
|
Ownership is not transferred, the implementation will not
|
|
|
|
access this object from other threads.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param buffers Caller provided data that has already been
|
|
|
|
received on the stream. This must not include the octets
|
|
|
|
corresponding to the HTTP Upgrade request. The implementation
|
|
|
|
will copy the caller provided data before the function returns.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@throws system_error Thrown on failure.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class Body, class Allocator,
|
|
|
|
class ConstBufferSequence>
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
void
|
2017-07-27 15:40:10 -07:00
|
|
|
accept(http::request<Body,
|
|
|
|
http::basic_fields<Allocator>> const& req,
|
|
|
|
ConstBufferSequence const& buffers);
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Respond to a WebSocket HTTP Upgrade request
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to synchronously send the HTTP response
|
|
|
|
to an HTTP request possibly containing a WebSocket Upgrade.
|
|
|
|
The call blocks until one of the following conditions is true:
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The response finishes sending.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li An error occurs on the stream.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is implemented in terms of one or more calls to
|
|
|
|
the next layer's `read_some` and `write_some` functions.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
If the stream receives a valid HTTP WebSocket Upgrade request,
|
|
|
|
an HTTP response is sent back indicating a successful upgrade.
|
|
|
|
When this call returns, the stream is then ready to send and
|
|
|
|
receive WebSocket protocol frames and messages.
|
|
|
|
If the HTTP Upgrade request is invalid or cannot be satisfied,
|
|
|
|
an HTTP response is sent indicating the reason and status code
|
|
|
|
(typically 400, "Bad Request"). This counts as a failure.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The implementation uses fixed size internal storage to
|
|
|
|
copy the buffer. If the buffer is too large, the error
|
|
|
|
@ref error::buffer_overflow will be indicated. Applications
|
|
|
|
that wish to supply larger buffers should wrap the next layer
|
|
|
|
in a @ref buffered_read_stream and store the buffer contents in
|
|
|
|
the wrapper before calling accept.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param req An object containing the HTTP Upgrade request.
|
|
|
|
Ownership is not transferred, the implementation will not
|
|
|
|
access this object from other threads.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param buffers Caller provided data that has already been
|
|
|
|
received on the stream. This must not include the octets
|
|
|
|
corresponding to the HTTP Upgrade request. The implementation
|
|
|
|
will copy the caller provided data before the function returns.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param decorator A function object which will be called to modify
|
|
|
|
the HTTP response object delivered by the implementation. This
|
|
|
|
could be used to set the Server field, subprotocols, or other
|
|
|
|
application or HTTP specific fields. The object will be called
|
|
|
|
with this equivalent signature:
|
|
|
|
@code void decorator(
|
|
|
|
response_type& res
|
|
|
|
); @endcode
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@throws system_error Thrown on failure.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class Body, class Allocator,
|
|
|
|
class ConstBufferSequence, class ResponseDecorator>
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
void
|
2017-07-27 15:40:10 -07:00
|
|
|
accept_ex(http::request<Body,
|
|
|
|
http::basic_fields<Allocator>> const& req,
|
|
|
|
ConstBufferSequence const& buffers,
|
|
|
|
ResponseDecorator const& decorator);
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Respond to a WebSocket HTTP Upgrade request
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to synchronously send the HTTP response
|
|
|
|
to an HTTP request possibly containing a WebSocket Upgrade.
|
|
|
|
The call blocks until one of the following conditions is true:
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The response finishes sending.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li An error occurs on the stream.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is implemented in terms of one or more calls to
|
|
|
|
the next layer's `read_some` and `write_some` functions.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
If the stream receives a valid HTTP WebSocket Upgrade request,
|
|
|
|
an HTTP response is sent back indicating a successful upgrade.
|
|
|
|
When this call returns, the stream is then ready to send and
|
|
|
|
receive WebSocket protocol frames and messages.
|
|
|
|
If the HTTP Upgrade request is invalid or cannot be satisfied,
|
|
|
|
an HTTP response is sent indicating the reason and status code
|
|
|
|
(typically 400, "Bad Request"). This counts as a failure.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The implementation uses fixed size internal storage to
|
|
|
|
copy the buffer. If the buffer is too large, the error
|
|
|
|
@ref error::buffer_overflow will be indicated. Applications
|
|
|
|
that wish to supply larger buffers should wrap the next layer
|
|
|
|
in a @ref buffered_read_stream and store the buffer contents in
|
|
|
|
the wrapper before calling accept.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param req An object containing the HTTP Upgrade request.
|
|
|
|
Ownership is not transferred, the implementation will not
|
|
|
|
access this object from other threads.
|
|
|
|
|
|
|
|
@param buffers Caller provided data that has already been
|
|
|
|
received on the stream. This must not include the octets
|
|
|
|
corresponding to the HTTP Upgrade request. The implementation
|
|
|
|
will copy the caller provided data before the function returns.
|
|
|
|
|
|
|
|
@param ec Set to indicate what error occurred, if any.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class Body, class Allocator,
|
|
|
|
class ConstBufferSequence>
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
void
|
2017-07-27 15:40:10 -07:00
|
|
|
accept(http::request<Body,
|
|
|
|
http::basic_fields<Allocator>> const& req,
|
|
|
|
ConstBufferSequence const& buffers,
|
|
|
|
error_code& ec);
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Respond to a WebSocket HTTP Upgrade request
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to synchronously send the HTTP response
|
|
|
|
to an HTTP request possibly containing a WebSocket Upgrade.
|
|
|
|
The call blocks until one of the following conditions is true:
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The response finishes sending.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li An error occurs on the stream.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is implemented in terms of one or more calls to
|
|
|
|
the next layer's `read_some` and `write_some` functions.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
If the stream receives a valid HTTP WebSocket Upgrade request,
|
|
|
|
an HTTP response is sent back indicating a successful upgrade.
|
|
|
|
When this call returns, the stream is then ready to send and
|
|
|
|
receive WebSocket protocol frames and messages.
|
|
|
|
If the HTTP Upgrade request is invalid or cannot be satisfied,
|
|
|
|
an HTTP response is sent indicating the reason and status code
|
|
|
|
(typically 400, "Bad Request"). This counts as a failure.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The implementation uses fixed size internal storage to
|
|
|
|
copy the buffer. If the buffer is too large, the error
|
|
|
|
@ref error::buffer_overflow will be indicated. Applications
|
|
|
|
that wish to supply larger buffers should wrap the next layer
|
|
|
|
in a @ref buffered_read_stream and store the buffer contents in
|
|
|
|
the wrapper before calling accept.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param req An object containing the HTTP Upgrade request.
|
|
|
|
Ownership is not transferred, the implementation will not
|
|
|
|
access this object from other threads.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param buffers Caller provided data that has already been
|
|
|
|
received on the stream. This must not include the octets
|
|
|
|
corresponding to the HTTP Upgrade request. The implementation
|
|
|
|
will copy the caller provided data before the function returns.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@param decorator A function object which will be called to modify
|
2017-07-27 15:40:10 -07:00
|
|
|
the HTTP response object delivered by the implementation. This
|
|
|
|
could be used to set the Server field, subprotocols, or other
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
application or HTTP specific fields. The object will be called
|
|
|
|
with this equivalent signature:
|
|
|
|
@code void decorator(
|
2017-07-27 15:40:10 -07:00
|
|
|
response_type& res
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
); @endcode
|
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param ec Set to indicate what error occurred, if any.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class Body, class Allocator,
|
|
|
|
class ConstBufferSequence, class ResponseDecorator>
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
void
|
2017-07-27 15:40:10 -07:00
|
|
|
accept_ex(http::request<Body,
|
|
|
|
http::basic_fields<Allocator>> const& req,
|
|
|
|
ConstBufferSequence const& buffers,
|
|
|
|
ResponseDecorator const& decorator,
|
|
|
|
error_code& ec);
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Start reading and responding to a WebSocket HTTP Upgrade request.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to asynchronously read an HTTP WebSocket
|
|
|
|
Upgrade request and send the HTTP response. The function call
|
|
|
|
always returns immediately. The asynchronous operation will
|
|
|
|
continue until one of the following conditions is true:
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The request is received and the response finishes sending.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li An error occurs on the stream.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This operation is implemented in terms of one or more calls to
|
|
|
|
the next layer's `async_read_some` and `async_write_some`
|
|
|
|
functions, and is known as a <em>composed operation</em>. The
|
|
|
|
program must ensure that the stream performs no other
|
|
|
|
asynchronous operations until this operation completes.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
If the stream receives a valid HTTP WebSocket Upgrade request,
|
|
|
|
an HTTP response is sent back indicating a successful upgrade.
|
|
|
|
When the completion handler is invoked, the stream is then
|
|
|
|
ready to send and receive WebSocket protocol frames and
|
|
|
|
messages.
|
|
|
|
If the HTTP Upgrade request is invalid or cannot be satisfied,
|
|
|
|
an HTTP response is sent indicating the reason and status code
|
|
|
|
(typically 400, "Bad Request"). This counts as a failure, and
|
|
|
|
the completion handler will be invoked with a suitable error
|
|
|
|
code set.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The implementation uses fixed size internal storage to
|
|
|
|
receive the request. If the request is too large, the error
|
|
|
|
@ref error::buffer_overflow will be indicated. Applications
|
|
|
|
that wish to receive larger requests should first read the
|
|
|
|
request using their own buffer and a suitable overload of
|
|
|
|
@ref http::read or @ref http::async_read, then call @ref accept
|
|
|
|
or @ref async_accept with the request.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param handler The handler to be called when the request
|
|
|
|
completes. Copies will be made of the handler as required. The
|
|
|
|
equivalent function signature of the handler must be:
|
|
|
|
@code void handler(
|
|
|
|
error_code const& ec // Result of operation
|
|
|
|
); @endcode
|
|
|
|
Regardless of whether the asynchronous operation completes
|
|
|
|
immediately or not, the handler will not be invoked from within
|
|
|
|
this function. Invocation of the handler will be performed in a
|
|
|
|
manner equivalent to using `boost::asio::io_service::post`.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class AcceptHandler>
|
|
|
|
#if BOOST_BEAST_DOXYGEN
|
|
|
|
void_or_deduced
|
|
|
|
#else
|
|
|
|
async_return_type<
|
|
|
|
AcceptHandler, void(error_code)>
|
|
|
|
#endif
|
|
|
|
async_accept(AcceptHandler&& handler);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Start reading and responding to a WebSocket HTTP Upgrade request.
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to asynchronously read an HTTP WebSocket
|
|
|
|
Upgrade request and send the HTTP response. The function call
|
|
|
|
always returns immediately. The asynchronous operation will
|
|
|
|
continue until one of the following conditions is true:
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The request is received and the response finishes sending.
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li An error occurs on the stream.
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This operation is implemented in terms of one or more calls to
|
|
|
|
the next layer's `async_read_some` and `async_write_some`
|
|
|
|
functions, and is known as a <em>composed operation</em>. The
|
|
|
|
program must ensure that the stream performs no other
|
|
|
|
asynchronous operations until this operation completes.
|
2017-07-12 07:05:27 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
If the stream receives a valid HTTP WebSocket Upgrade request,
|
|
|
|
an HTTP response is sent back indicating a successful upgrade.
|
|
|
|
When the completion handler is invoked, the stream is then
|
|
|
|
ready to send and receive WebSocket protocol frames and
|
|
|
|
messages.
|
|
|
|
If the HTTP Upgrade request is invalid or cannot be satisfied,
|
|
|
|
an HTTP response is sent indicating the reason and status code
|
|
|
|
(typically 400, "Bad Request"). This counts as a failure, and
|
|
|
|
the completion handler will be invoked with a suitable error
|
|
|
|
code set.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The implementation uses fixed size internal storage to
|
|
|
|
receive the request. If the request is too large, the error
|
|
|
|
@ref error::buffer_overflow will be indicated. Applications
|
|
|
|
that wish to receive larger requests should first read the
|
|
|
|
request using their own buffer and a suitable overload of
|
|
|
|
@ref http::read or @ref http::async_read, then call @ref accept
|
|
|
|
or @ref async_accept with the request.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param decorator A function object which will be called to modify
|
|
|
|
the HTTP response object delivered by the implementation. This
|
|
|
|
could be used to set the Server field, subprotocols, or other
|
|
|
|
application or HTTP specific fields. The object will be called
|
|
|
|
with this equivalent signature:
|
|
|
|
@code void decorator(
|
|
|
|
response_type& res
|
|
|
|
); @endcode
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param handler The handler to be called when the request
|
|
|
|
completes. Copies will be made of the handler as required. The
|
|
|
|
equivalent function signature of the handler must be:
|
|
|
|
@code void handler(
|
|
|
|
error_code const& ec // Result of operation
|
|
|
|
); @endcode
|
|
|
|
Regardless of whether the asynchronous operation completes
|
|
|
|
immediately or not, the handler will not be invoked from within
|
|
|
|
this function. Invocation of the handler will be performed in a
|
|
|
|
manner equivalent to using `boost::asio::io_service::post`.
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class ResponseDecorator, class AcceptHandler>
|
|
|
|
#if BOOST_BEAST_DOXYGEN
|
|
|
|
void_or_deduced
|
|
|
|
#else
|
|
|
|
async_return_type<
|
|
|
|
AcceptHandler, void(error_code)>
|
|
|
|
#endif
|
|
|
|
async_accept_ex(ResponseDecorator const& decorator,
|
|
|
|
AcceptHandler&& handler);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Start reading and responding to a WebSocket HTTP Upgrade request.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to asynchronously read an HTTP WebSocket
|
|
|
|
Upgrade request and send the HTTP response. The function call
|
|
|
|
always returns immediately. The asynchronous operation will
|
|
|
|
continue until one of the following conditions is true:
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The request is received and the response finishes sending.
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li An error occurs on the stream.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This operation is implemented in terms of one or more calls to
|
|
|
|
the next layer's `async_read_some` and `async_write_some`
|
|
|
|
functions, and is known as a <em>composed operation</em>. The
|
|
|
|
program must ensure that the stream performs no other
|
|
|
|
asynchronous operations until this operation completes.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
If the stream receives a valid HTTP WebSocket Upgrade request,
|
|
|
|
an HTTP response is sent back indicating a successful upgrade.
|
|
|
|
When the completion handler is invoked, the stream is then
|
|
|
|
ready to send and receive WebSocket protocol frames and
|
|
|
|
messages.
|
|
|
|
If the HTTP Upgrade request is invalid or cannot be satisfied,
|
|
|
|
an HTTP response is sent indicating the reason and status code
|
|
|
|
(typically 400, "Bad Request"). This counts as a failure, and
|
|
|
|
the completion handler will be invoked with a suitable error
|
|
|
|
code set.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The implementation uses fixed size internal storage to
|
|
|
|
receive the request. If the request is too large, the error
|
|
|
|
@ref error::buffer_overflow will be indicated. Applications
|
|
|
|
that wish to receive larger requests should first read the
|
|
|
|
request using their own buffer and a suitable overload of
|
|
|
|
@ref http::read or @ref http::async_read, then call @ref accept
|
|
|
|
or @ref async_accept with the request.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param buffers Caller provided data that has already been
|
|
|
|
received on the stream. This may be used for implementations
|
|
|
|
allowing multiple protocols on the same stream. The
|
|
|
|
buffered data will first be applied to the handshake, and
|
|
|
|
then to received WebSocket frames. The implementation will
|
|
|
|
copy the caller provided data before the function returns.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param handler The handler to be called when the request
|
|
|
|
completes. Copies will be made of the handler as required. The
|
|
|
|
equivalent function signature of the handler must be:
|
|
|
|
@code void handler(
|
|
|
|
error_code const& ec // Result of operation
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
); @endcode
|
2017-07-27 15:40:10 -07:00
|
|
|
Regardless of whether the asynchronous operation completes
|
|
|
|
immediately or not, the handler will not be invoked from within
|
|
|
|
this function. Invocation of the handler will be performed in a
|
|
|
|
manner equivalent to using `boost::asio::io_service::post`.
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class ConstBufferSequence, class AcceptHandler>
|
|
|
|
#if BOOST_BEAST_DOXYGEN
|
|
|
|
void_or_deduced
|
|
|
|
#else
|
|
|
|
typename std::enable_if<
|
|
|
|
! http::detail::is_header<ConstBufferSequence>::value,
|
|
|
|
async_return_type<AcceptHandler, void(error_code)>>::type
|
|
|
|
#endif
|
|
|
|
async_accept(ConstBufferSequence const& buffers,
|
|
|
|
AcceptHandler&& handler);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Start reading and responding to a WebSocket HTTP Upgrade request.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to asynchronously read an HTTP WebSocket
|
|
|
|
Upgrade request and send the HTTP response. The function call
|
|
|
|
always returns immediately. The asynchronous operation will
|
|
|
|
continue until one of the following conditions is true:
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The request is received and the response finishes sending.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li An error occurs on the stream.
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This operation is implemented in terms of one or more calls to
|
|
|
|
the next layer's `async_read_some` and `async_write_some`
|
|
|
|
functions, and is known as a <em>composed operation</em>. The
|
|
|
|
program must ensure that the stream performs no other
|
|
|
|
asynchronous operations until this operation completes.
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
If the stream receives a valid HTTP WebSocket Upgrade request,
|
|
|
|
an HTTP response is sent back indicating a successful upgrade.
|
|
|
|
When the completion handler is invoked, the stream is then
|
|
|
|
ready to send and receive WebSocket protocol frames and
|
|
|
|
messages.
|
|
|
|
If the HTTP Upgrade request is invalid or cannot be satisfied,
|
|
|
|
an HTTP response is sent indicating the reason and status code
|
|
|
|
(typically 400, "Bad Request"). This counts as a failure, and
|
|
|
|
the completion handler will be invoked with a suitable error
|
|
|
|
code set.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The implementation uses fixed size internal storage to
|
|
|
|
receive the request. If the request is too large, the error
|
|
|
|
@ref error::buffer_overflow will be indicated. Applications
|
|
|
|
that wish to receive larger requests should first read the
|
|
|
|
request using their own buffer and a suitable overload of
|
|
|
|
@ref http::read or @ref http::async_read, then call @ref accept
|
|
|
|
or @ref async_accept with the request.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param buffers Caller provided data that has already been
|
|
|
|
received on the stream. This may be used for implementations
|
|
|
|
allowing multiple protocols on the same stream. The
|
|
|
|
buffered data will first be applied to the handshake, and
|
|
|
|
then to received WebSocket frames. The implementation will
|
|
|
|
copy the caller provided data before the function returns.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
@param decorator A function object which will be called to modify
|
2017-07-27 15:40:10 -07:00
|
|
|
the HTTP response object delivered by the implementation. This
|
|
|
|
could be used to set the Server field, subprotocols, or other
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
application or HTTP specific fields. The object will be called
|
|
|
|
with this equivalent signature:
|
|
|
|
@code void decorator(
|
2017-07-27 15:40:10 -07:00
|
|
|
response_type& res
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
); @endcode
|
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param handler The handler to be called when the request
|
|
|
|
completes. Copies will be made of the handler as required. The
|
|
|
|
equivalent function signature of the handler must be:
|
|
|
|
@code void handler(
|
|
|
|
error_code const& ec // Result of operation
|
|
|
|
); @endcode
|
|
|
|
Regardless of whether the asynchronous operation completes
|
|
|
|
immediately or not, the handler will not be invoked from within
|
|
|
|
this function. Invocation of the handler will be performed in a
|
|
|
|
manner equivalent to using `boost::asio::io_service::post`.
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class ConstBufferSequence,
|
|
|
|
class ResponseDecorator, class AcceptHandler>
|
|
|
|
#if BOOST_BEAST_DOXYGEN
|
|
|
|
void_or_deduced
|
|
|
|
#else
|
|
|
|
typename std::enable_if<
|
|
|
|
! http::detail::is_header<ConstBufferSequence>::value,
|
|
|
|
async_return_type<AcceptHandler, void(error_code)>>::type
|
|
|
|
#endif
|
|
|
|
async_accept_ex(ConstBufferSequence const& buffers,
|
|
|
|
ResponseDecorator const& decorator,
|
|
|
|
AcceptHandler&& handler);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Start responding to a WebSocket HTTP Upgrade request.
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to asynchronously send the HTTP response
|
|
|
|
to an HTTP request possibly containing a WebSocket Upgrade
|
|
|
|
request. The function call always returns immediately. The
|
|
|
|
asynchronous operation will continue until one of the following
|
|
|
|
conditions is true:
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The response finishes sending.
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li An error occurs on the stream.
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This operation is implemented in terms of one or more calls to
|
|
|
|
the next layer's `async_write_some` functions, and is known as
|
|
|
|
a <em>composed operation</em>. The program must ensure that the
|
|
|
|
stream performs no other operations until this operation
|
2016-05-01 12:33:35 -04:00
|
|
|
completes.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
If the stream receives a valid HTTP WebSocket Upgrade request,
|
|
|
|
an HTTP response is sent back indicating a successful upgrade.
|
|
|
|
When the completion handler is invoked, the stream is then
|
|
|
|
ready to send and receive WebSocket protocol frames and
|
|
|
|
messages.
|
|
|
|
If the HTTP Upgrade request is invalid or cannot be satisfied,
|
|
|
|
an HTTP response is sent indicating the reason and status code
|
|
|
|
(typically 400, "Bad Request"). This counts as a failure, and
|
|
|
|
the completion handler will be invoked with a suitable error
|
|
|
|
code set.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param req An object containing the HTTP Upgrade request.
|
|
|
|
Ownership is not transferred, the implementation will not access
|
|
|
|
this object from other threads.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param handler The handler to be called when the request
|
|
|
|
completes. Copies will be made of the handler as required. The
|
|
|
|
equivalent function signature of the handler must be:
|
2017-07-20 08:01:46 -07:00
|
|
|
@code void handler(
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
error_code const& ec // Result of operation
|
2017-07-20 08:01:46 -07:00
|
|
|
); @endcode
|
|
|
|
Regardless of whether the asynchronous operation completes
|
|
|
|
immediately or not, the handler will not be invoked from within
|
|
|
|
this function. Invocation of the handler will be performed in a
|
2016-05-01 12:33:35 -04:00
|
|
|
manner equivalent to using `boost::asio::io_service::post`.
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class Body, class Allocator,
|
|
|
|
class AcceptHandler>
|
2017-07-20 13:40:34 -07:00
|
|
|
#if BOOST_BEAST_DOXYGEN
|
2017-05-23 15:50:15 -07:00
|
|
|
void_or_deduced
|
|
|
|
#else
|
2017-05-12 17:13:03 -07:00
|
|
|
async_return_type<
|
2017-07-27 15:40:10 -07:00
|
|
|
AcceptHandler, void(error_code)>
|
2017-05-23 15:50:15 -07:00
|
|
|
#endif
|
2017-07-27 15:40:10 -07:00
|
|
|
async_accept(http::request<Body,
|
|
|
|
http::basic_fields<Allocator>> const& req,
|
|
|
|
AcceptHandler&& handler);
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Start responding to a WebSocket HTTP Upgrade request.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to asynchronously send the HTTP response
|
|
|
|
to an HTTP request possibly containing a WebSocket Upgrade
|
|
|
|
request. The function call always returns immediately. The
|
|
|
|
asynchronous operation will continue until one of the following
|
|
|
|
conditions is true:
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The response finishes sending.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li An error occurs on the stream.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This operation is implemented in terms of one or more calls to
|
|
|
|
the next layer's `async_write_some` functions, and is known as
|
|
|
|
a <em>composed operation</em>. The program must ensure that the
|
|
|
|
stream performs no other operations until this operation
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
completes.
|
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
If the stream receives a valid HTTP WebSocket Upgrade request,
|
|
|
|
an HTTP response is sent back indicating a successful upgrade.
|
|
|
|
When the completion handler is invoked, the stream is then
|
|
|
|
ready to send and receive WebSocket protocol frames and
|
|
|
|
messages.
|
|
|
|
If the HTTP Upgrade request is invalid or cannot be satisfied,
|
|
|
|
an HTTP response is sent indicating the reason and status code
|
|
|
|
(typically 400, "Bad Request"). This counts as a failure, and
|
|
|
|
the completion handler will be invoked with a suitable error
|
|
|
|
code set.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param req An object containing the HTTP Upgrade request.
|
|
|
|
Ownership is not transferred, the implementation will not access
|
|
|
|
this object from other threads.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param decorator A function object which will be called to modify
|
|
|
|
the HTTP response object delivered by the implementation. This
|
|
|
|
could be used to set the Server field, subprotocols, or other
|
|
|
|
application or HTTP specific fields. The object will be called
|
|
|
|
with this equivalent signature:
|
|
|
|
@code void decorator(
|
|
|
|
response_type& res
|
|
|
|
); @endcode
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param handler The handler to be called when the request
|
|
|
|
completes. Copies will be made of the handler as required. The
|
|
|
|
equivalent function signature of the handler must be:
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
@code void handler(
|
2017-07-27 15:40:10 -07:00
|
|
|
error_code const& ec // Result of operation
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
); @endcode
|
|
|
|
Regardless of whether the asynchronous operation completes
|
|
|
|
immediately or not, the handler will not be invoked from within
|
|
|
|
this function. Invocation of the handler will be performed in a
|
|
|
|
manner equivalent to using `boost::asio::io_service::post`.
|
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class Body, class Allocator,
|
|
|
|
class ResponseDecorator, class AcceptHandler>
|
2017-07-20 13:40:34 -07:00
|
|
|
#if BOOST_BEAST_DOXYGEN
|
2017-05-23 15:50:15 -07:00
|
|
|
void_or_deduced
|
|
|
|
#else
|
2017-05-12 17:13:03 -07:00
|
|
|
async_return_type<
|
2017-07-27 15:40:10 -07:00
|
|
|
AcceptHandler, void(error_code)>
|
2017-05-23 15:50:15 -07:00
|
|
|
#endif
|
2017-07-27 15:40:10 -07:00
|
|
|
async_accept_ex(http::request<Body,
|
|
|
|
http::basic_fields<Allocator>> const& req,
|
|
|
|
ResponseDecorator const& decorator,
|
|
|
|
AcceptHandler&& handler);
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Start responding to a WebSocket HTTP Upgrade request.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to asynchronously send the HTTP response
|
|
|
|
to an HTTP request possibly containing a WebSocket Upgrade
|
|
|
|
request. The function call always returns immediately. The
|
|
|
|
asynchronous operation will continue until one of the following
|
|
|
|
conditions is true:
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The response finishes sending.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li An error occurs on the stream.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This operation is implemented in terms of one or more calls to
|
|
|
|
the next layer's `async_write_some` functions, and is known as
|
|
|
|
a <em>composed operation</em>. The program must ensure that the
|
|
|
|
stream performs no other operations until this operation
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
completes.
|
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
If the stream receives a valid HTTP WebSocket Upgrade request,
|
|
|
|
an HTTP response is sent back indicating a successful upgrade.
|
|
|
|
When the completion handler is invoked, the stream is then
|
|
|
|
ready to send and receive WebSocket protocol frames and
|
|
|
|
messages.
|
|
|
|
If the HTTP Upgrade request is invalid or cannot be satisfied,
|
|
|
|
an HTTP response is sent indicating the reason and status code
|
|
|
|
(typically 400, "Bad Request"). This counts as a failure, and
|
|
|
|
the completion handler will be invoked with a suitable error
|
|
|
|
code set.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The implementation uses fixed size internal storage to
|
|
|
|
copy the buffer. If the buffer is too large, the error
|
|
|
|
@ref error::buffer_overflow will be indicated. Applications
|
|
|
|
that wish to supply larger buffers should wrap the next layer
|
|
|
|
in a @ref buffered_read_stream and store the buffer contents in
|
|
|
|
the wrapper before calling accept.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param req An object containing the HTTP Upgrade request.
|
|
|
|
Ownership is not transferred, the implementation will not access
|
|
|
|
this object from other threads.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param buffers Caller provided data that has already been
|
|
|
|
received on the stream. This may be used for implementations
|
|
|
|
allowing multiple protocols on the same stream. The
|
|
|
|
buffered data will first be applied to the handshake, and
|
|
|
|
then to received WebSocket frames. The implementation will
|
|
|
|
copy the caller provided data before the function returns.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param handler The handler to be called when the request
|
|
|
|
completes. Copies will be made of the handler as required. The
|
|
|
|
equivalent function signature of the handler must be:
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
@code void handler(
|
2017-07-27 15:40:10 -07:00
|
|
|
error_code const& ec // Result of operation
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
); @endcode
|
|
|
|
Regardless of whether the asynchronous operation completes
|
|
|
|
immediately or not, the handler will not be invoked from within
|
|
|
|
this function. Invocation of the handler will be performed in a
|
|
|
|
manner equivalent to using `boost::asio::io_service::post`.
|
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<class Body, class Allocator,
|
|
|
|
class ConstBufferSequence, class AcceptHandler>
|
2017-07-20 13:40:34 -07:00
|
|
|
#if BOOST_BEAST_DOXYGEN
|
2017-05-23 15:50:15 -07:00
|
|
|
void_or_deduced
|
|
|
|
#else
|
2017-05-12 17:13:03 -07:00
|
|
|
async_return_type<
|
2017-07-27 15:40:10 -07:00
|
|
|
AcceptHandler, void(error_code)>
|
2017-05-23 15:50:15 -07:00
|
|
|
#endif
|
2017-07-27 15:40:10 -07:00
|
|
|
async_accept(http::request<Body,
|
|
|
|
http::basic_fields<Allocator>> const& req,
|
|
|
|
ConstBufferSequence const& buffers,
|
|
|
|
AcceptHandler&& handler);
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
/** Start responding to a WebSocket HTTP Upgrade request.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This function is used to asynchronously send the HTTP response
|
|
|
|
to an HTTP request possibly containing a WebSocket Upgrade
|
|
|
|
request. The function call always returns immediately. The
|
|
|
|
asynchronous operation will continue until one of the following
|
|
|
|
conditions is true:
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li The response finishes sending.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@li An error occurs on the stream.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
This operation is implemented in terms of one or more calls to
|
|
|
|
the next layer's `async_write_some` functions, and is known as
|
|
|
|
a <em>composed operation</em>. The program must ensure that the
|
|
|
|
stream performs no other operations until this operation
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
completes.
|
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
If the stream receives a valid HTTP WebSocket Upgrade request,
|
|
|
|
an HTTP response is sent back indicating a successful upgrade.
|
|
|
|
When the completion handler is invoked, the stream is then
|
|
|
|
ready to send and receive WebSocket protocol frames and
|
|
|
|
messages.
|
|
|
|
If the HTTP Upgrade request is invalid or cannot be satisfied,
|
|
|
|
an HTTP response is sent indicating the reason and status code
|
|
|
|
(typically 400, "Bad Request"). This counts as a failure, and
|
|
|
|
the completion handler will be invoked with a suitable error
|
|
|
|
code set.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
The implementation uses fixed size internal storage to
|
|
|
|
copy the buffer. If the buffer is too large, the error
|
|
|
|
@ref error::buffer_overflow will be indicated. Applications
|
|
|
|
that wish to supply larger buffers should wrap the next layer
|
|
|
|
in a @ref buffered_read_stream and store the buffer contents in
|
|
|
|
the wrapper before calling accept.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param req An object containing the HTTP Upgrade request.
|
|
|
|
Ownership is not transferred, the implementation will not access
|
|
|
|
this object from other threads.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param buffers Caller provided data that has already been
|
|
|
|
received on the stream. This may be used for implementations
|
|
|
|
allowing multiple protocols on the same stream. The
|
|
|
|
buffered data will first be applied to the handshake, and
|
|
|
|
then to received WebSocket frames. The implementation will
|
|
|
|
copy the caller provided data before the function returns.
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
|
|
|
@param decorator A function object which will be called to modify
|
2017-07-27 15:40:10 -07:00
|
|
|
the HTTP response object delivered by the implementation. This
|
|
|
|
could be used to set the Server field, subprotocols, or other
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
application or HTTP specific fields. The object will be called
|
|
|
|
with this equivalent signature:
|
|
|
|
@code void decorator(
|
2017-07-27 15:40:10 -07:00
|
|
|
response_type& res
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
); @endcode
|
|
|
|
|
2017-07-27 15:40:10 -07:00
|
|
|
@param handler The handler to be called when the request
|
|
|
|
completes. Copies will be made of the handler as required. The
|
|
|
|
equivalent function signature of the handler must be:
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
@code void handler(
|
2017-07-27 15:40:10 -07:00
|
|
|
error_code const& ec // Result of operation
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
); @endcode
|
|
|
|
Regardless of whether the asynchronous operation completes
|
|
|
|
immediately or not, the handler will not be invoked from within
|
|
|
|
this function. Invocation of the handler will be performed in a
|
|
|
|
manner equivalent to using `boost::asio::io_service::post`.
|
|
|
|
*/
|
2017-07-27 15:40:10 -07:00
|
|
|
template<
|
|
|
|
class Body, class Allocator,
|
|
|
|
class ConstBufferSequence,
|
|
|
|
class ResponseDecorator,
|
|
|
|
class AcceptHandler>
|
2017-07-20 13:40:34 -07:00
|
|
|
#if BOOST_BEAST_DOXYGEN
|
2017-05-23 15:50:15 -07:00
|
|
|
void_or_deduced
|
|
|
|
#else
|
2017-05-12 17:13:03 -07:00
|
|
|
async_return_type<
|
2017-07-27 15:40:10 -07:00
|
|
|
AcceptHandler, void(error_code)>
|
2017-05-23 15:50:15 -07:00
|
|
|
#endif
|
2017-07-27 15:40:10 -07:00
|
|
|
async_accept_ex(
|
|
|
|
http::request<Body,
|
|
|
|
http::basic_fields<Allocator>> const& req,
|
|
|
|
ConstBufferSequence const& buffers,
|
|
|
|
ResponseDecorator const& decorator,
|
|
|
|
AcceptHandler&& handler);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-15 17:05:24 -07:00
|
|
|
//--------------------------------------------------------------------------
|
|
|
|
//
|
|
|
|
// Control Frames
|
|
|
|
//
|
|
|
|
//--------------------------------------------------------------------------
|
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
/** Send a WebSocket close frame.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-15 16:22:25 -04:00
|
|
|
This function is used to synchronously send a close frame on
|
2016-05-01 12:33:35 -04:00
|
|
|
the stream. The call blocks until one of the following is true:
|
|
|
|
|
|
|
|
@li The close frame finishes sending.
|
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
2016-10-15 21:39:24 -04:00
|
|
|
This function is implemented in terms of one or more calls
|
|
|
|
to the next layer's `write_some` functions.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
If the close reason specifies a close code other than
|
2016-10-15 21:39:24 -04:00
|
|
|
@ref beast::websocket::close_code::none, the close frame is
|
|
|
|
sent with the close code and optional reason string. Otherwise,
|
|
|
|
the close frame is sent with no payload.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
Callers should not attempt to write WebSocket data after
|
|
|
|
initiating the close. Instead, callers should continue
|
2016-05-01 12:33:35 -04:00
|
|
|
reading until an error occurs. A read returning @ref error::closed
|
2017-07-20 08:01:46 -07:00
|
|
|
indicates a successful connection closure.
|
|
|
|
|
|
|
|
@param cr The reason for the close.
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2016-10-04 18:00:11 -04:00
|
|
|
@throws system_error Thrown on failure.
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
|
|
|
void
|
2016-04-30 13:00:33 -04:00
|
|
|
close(close_reason const& cr);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
/** Send a WebSocket close frame.
|
|
|
|
|
2016-05-15 16:22:25 -04:00
|
|
|
This function is used to synchronously send a close frame on
|
2016-05-01 12:33:35 -04:00
|
|
|
the stream. The call blocks until one of the following is true:
|
|
|
|
|
|
|
|
@li The close frame finishes sending.
|
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-10-15 21:39:24 -04:00
|
|
|
This function is implemented in terms of one or more calls
|
|
|
|
to the next layer's `write_some` functions.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
If the close reason specifies a close code other than
|
2016-10-15 21:39:24 -04:00
|
|
|
@ref beast::websocket::close_code::none, the close frame is
|
|
|
|
sent with the close code and optional reason string. Otherwise,
|
|
|
|
the close frame is sent with no payload.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
Callers should not attempt to write WebSocket data after
|
|
|
|
initiating the close. Instead, callers should continue
|
2016-05-01 12:33:35 -04:00
|
|
|
reading until an error occurs. A read returning @ref error::closed
|
2017-07-20 08:01:46 -07:00
|
|
|
indicates a successful connection closure.
|
|
|
|
|
|
|
|
@param cr The reason for the close.
|
|
|
|
|
|
|
|
@param ec Set to indicate what error occurred, if any.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
close(close_reason const& cr, error_code& ec);
|
|
|
|
|
2016-05-15 16:22:25 -04:00
|
|
|
/** Start an asynchronous operation to send a WebSocket close frame.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
This function is used to asynchronously send a close frame on
|
|
|
|
the stream. This function call always returns immediately. The
|
|
|
|
asynchronous operation will continue until one of the following
|
|
|
|
conditions is true:
|
|
|
|
|
|
|
|
@li The close frame finishes sending.
|
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
|
|
|
This operation is implemented in terms of one or more calls to the
|
|
|
|
next layer's `async_write_some` functions, and is known as a
|
|
|
|
<em>composed operation</em>. The program must ensure that the
|
2016-05-15 16:22:25 -04:00
|
|
|
stream performs no other write operations (such as @ref async_ping,
|
2017-07-15 17:05:24 -07:00
|
|
|
@ref stream::async_write, @ref stream::async_write_some, or
|
2016-05-01 12:33:35 -04:00
|
|
|
@ref stream::async_close) until this operation completes.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
If the close reason specifies a close code other than
|
2016-10-15 21:39:24 -04:00
|
|
|
@ref beast::websocket::close_code::none, the close frame is
|
|
|
|
sent with the close code and optional reason string. Otherwise,
|
|
|
|
the close frame is sent with no payload.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
Callers should not attempt to write WebSocket data after
|
|
|
|
initiating the close. Instead, callers should continue
|
2016-05-01 12:33:35 -04:00
|
|
|
reading until an error occurs. A read returning @ref error::closed
|
2017-07-20 08:01:46 -07:00
|
|
|
indicates a successful connection closure.
|
|
|
|
|
|
|
|
@param cr The reason for the close.
|
|
|
|
|
|
|
|
@param handler The handler to be called when the close operation
|
|
|
|
completes. Copies will be made of the handler as required. The
|
|
|
|
function signature of the handler must be:
|
|
|
|
@code
|
|
|
|
void handler(
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
error_code const& ec // Result of operation
|
2017-07-20 08:01:46 -07:00
|
|
|
);
|
|
|
|
@endcode
|
|
|
|
Regardless of whether the asynchronous operation completes
|
|
|
|
immediately or not, the handler will not be invoked from within
|
|
|
|
this function. Invocation of the handler will be performed in a
|
2016-05-01 12:33:35 -04:00
|
|
|
manner equivalent to using `boost::asio::io_service::post`.
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
|
|
|
template<class CloseHandler>
|
2017-07-20 13:40:34 -07:00
|
|
|
#if BOOST_BEAST_DOXYGEN
|
2017-05-23 15:50:15 -07:00
|
|
|
void_or_deduced
|
|
|
|
#else
|
2017-05-12 17:13:03 -07:00
|
|
|
async_return_type<
|
|
|
|
CloseHandler, void(error_code)>
|
2017-05-23 15:50:15 -07:00
|
|
|
#endif
|
2017-07-20 08:01:46 -07:00
|
|
|
async_close(close_reason const& cr, CloseHandler&& handler);
|
|
|
|
|
2016-05-15 16:22:25 -04:00
|
|
|
/** Send a WebSocket ping frame.
|
|
|
|
|
|
|
|
This function is used to synchronously send a ping frame on
|
|
|
|
the stream. The call blocks until one of the following is true:
|
|
|
|
|
|
|
|
@li The ping frame finishes sending.
|
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
|
|
|
This function is implemented in terms of one or more calls to the
|
|
|
|
next layer's `write_some` functions.
|
|
|
|
|
|
|
|
@param payload The payload of the ping message, which may be empty.
|
|
|
|
|
2016-10-04 18:00:11 -04:00
|
|
|
@throws system_error Thrown on failure.
|
2016-05-15 16:22:25 -04:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
ping(ping_data const& payload);
|
|
|
|
|
|
|
|
/** Send a WebSocket ping frame.
|
|
|
|
|
|
|
|
This function is used to synchronously send a ping frame on
|
|
|
|
the stream. The call blocks until one of the following is true:
|
|
|
|
|
|
|
|
@li The ping frame finishes sending.
|
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
|
|
|
This function is implemented in terms of one or more calls to the
|
|
|
|
next layer's `write_some` functions.
|
|
|
|
|
|
|
|
@param payload The payload of the ping message, which may be empty.
|
|
|
|
|
|
|
|
@param ec Set to indicate what error occurred, if any.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
ping(ping_data const& payload, error_code& ec);
|
|
|
|
|
|
|
|
/** Start an asynchronous operation to send a WebSocket ping frame.
|
|
|
|
|
|
|
|
This function is used to asynchronously send a ping frame to
|
|
|
|
the stream. The function call always returns immediately. The
|
|
|
|
asynchronous operation will continue until one of the following
|
|
|
|
is true:
|
|
|
|
|
|
|
|
@li The entire ping frame is sent.
|
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
|
|
|
This operation is implemented in terms of one or more calls to the
|
|
|
|
next layer's `async_write_some` functions, and is known as a
|
|
|
|
<em>composed operation</em>. The program must ensure that the
|
|
|
|
stream performs no other writes until this operation completes.
|
|
|
|
|
2017-02-24 14:53:20 -05:00
|
|
|
If a close frame is sent or received before the ping frame is
|
|
|
|
sent, the completion handler will be called with the error
|
|
|
|
set to `boost::asio::error::operation_aborted`.
|
|
|
|
|
2016-05-15 16:22:25 -04:00
|
|
|
@param payload The payload of the ping message, which may be empty.
|
|
|
|
|
|
|
|
@param handler The handler to be called when the read operation
|
|
|
|
completes. Copies will be made of the handler as required. The
|
|
|
|
function signature of the handler must be:
|
|
|
|
@code
|
|
|
|
void handler(
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
error_code const& ec // Result of operation
|
2016-05-15 16:22:25 -04:00
|
|
|
);
|
|
|
|
@endcode
|
|
|
|
Regardless of whether the asynchronous operation completes
|
|
|
|
immediately or not, the handler will not be invoked from within
|
|
|
|
this function. Invocation of the handler will be performed in a
|
|
|
|
manner equivalent to using `boost::asio::io_service::post`.
|
|
|
|
*/
|
2016-11-03 17:53:32 -04:00
|
|
|
template<class WriteHandler>
|
2017-07-20 13:40:34 -07:00
|
|
|
#if BOOST_BEAST_DOXYGEN
|
2017-05-23 15:50:15 -07:00
|
|
|
void_or_deduced
|
|
|
|
#else
|
2017-05-12 17:13:03 -07:00
|
|
|
async_return_type<
|
|
|
|
WriteHandler, void(error_code)>
|
2017-05-23 15:50:15 -07:00
|
|
|
#endif
|
2016-11-03 17:53:32 -04:00
|
|
|
async_ping(ping_data const& payload, WriteHandler&& handler);
|
|
|
|
|
|
|
|
/** Send a WebSocket pong frame.
|
|
|
|
|
|
|
|
This function is used to synchronously send a pong frame on
|
|
|
|
the stream. The call blocks until one of the following is true:
|
|
|
|
|
|
|
|
@li The pong frame finishes sending.
|
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
|
|
|
This function is implemented in terms of one or more calls to the
|
|
|
|
next layer's `write_some` functions.
|
|
|
|
|
|
|
|
The WebSocket protocol allows pong frames to be sent from either
|
|
|
|
end at any time. It is not necessary to first receive a ping in
|
|
|
|
order to send a pong. The remote peer may use the receipt of a
|
|
|
|
pong frame as an indication that the connection is not dead.
|
|
|
|
|
|
|
|
@param payload The payload of the pong message, which may be empty.
|
|
|
|
|
|
|
|
@throws system_error Thrown on failure.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
pong(ping_data const& payload);
|
|
|
|
|
|
|
|
/** Send a WebSocket pong frame.
|
|
|
|
|
|
|
|
This function is used to synchronously send a pong frame on
|
|
|
|
the stream. The call blocks until one of the following is true:
|
|
|
|
|
|
|
|
@li The pong frame finishes sending.
|
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
|
|
|
This function is implemented in terms of one or more calls to the
|
|
|
|
next layer's `write_some` functions.
|
|
|
|
|
|
|
|
The WebSocket protocol allows pong frames to be sent from either
|
|
|
|
end at any time. It is not necessary to first receive a ping in
|
|
|
|
order to send a pong. The remote peer may use the receipt of a
|
|
|
|
pong frame as an indication that the connection is not dead.
|
|
|
|
|
|
|
|
@param payload The payload of the pong message, which may be empty.
|
|
|
|
|
|
|
|
@param ec Set to indicate what error occurred, if any.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
pong(ping_data const& payload, error_code& ec);
|
|
|
|
|
|
|
|
/** Start an asynchronous operation to send a WebSocket pong frame.
|
|
|
|
|
|
|
|
This function is used to asynchronously send a pong frame to
|
|
|
|
the stream. The function call always returns immediately. The
|
|
|
|
asynchronous operation will continue until one of the following
|
|
|
|
is true:
|
|
|
|
|
|
|
|
@li The entire pong frame is sent.
|
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
|
|
|
This operation is implemented in terms of one or more calls to the
|
|
|
|
next layer's `async_write_some` functions, and is known as a
|
|
|
|
<em>composed operation</em>. The program must ensure that the
|
|
|
|
stream performs no other writes until this operation completes.
|
|
|
|
|
|
|
|
The WebSocket protocol allows pong frames to be sent from either
|
|
|
|
end at any time. It is not necessary to first receive a ping in
|
|
|
|
order to send a pong. The remote peer may use the receipt of a
|
|
|
|
pong frame as an indication that the connection is not dead.
|
|
|
|
|
2017-02-24 14:53:20 -05:00
|
|
|
If a close frame is sent or received before the pong frame is
|
|
|
|
sent, the completion handler will be called with the error
|
|
|
|
set to `boost::asio::error::operation_aborted`.
|
|
|
|
|
2016-11-03 17:53:32 -04:00
|
|
|
@param payload The payload of the pong message, which may be empty.
|
|
|
|
|
|
|
|
@param handler The handler to be called when the read operation
|
|
|
|
completes. Copies will be made of the handler as required. The
|
|
|
|
function signature of the handler must be:
|
|
|
|
@code
|
|
|
|
void handler(
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
error_code const& ec // Result of operation
|
2016-11-03 17:53:32 -04:00
|
|
|
);
|
|
|
|
@endcode
|
|
|
|
Regardless of whether the asynchronous operation completes
|
|
|
|
immediately or not, the handler will not be invoked from within
|
|
|
|
this function. Invocation of the handler will be performed in a
|
|
|
|
manner equivalent to using `boost::asio::io_service::post`.
|
|
|
|
*/
|
|
|
|
template<class WriteHandler>
|
2017-07-20 13:40:34 -07:00
|
|
|
#if BOOST_BEAST_DOXYGEN
|
2017-05-23 15:50:15 -07:00
|
|
|
void_or_deduced
|
|
|
|
#else
|
2017-05-12 17:13:03 -07:00
|
|
|
async_return_type<
|
|
|
|
WriteHandler, void(error_code)>
|
2017-05-23 15:50:15 -07:00
|
|
|
#endif
|
2016-11-03 17:53:32 -04:00
|
|
|
async_pong(ping_data const& payload, WriteHandler&& handler);
|
2016-05-15 16:22:25 -04:00
|
|
|
|
2017-07-15 17:05:24 -07:00
|
|
|
//--------------------------------------------------------------------------
|
|
|
|
//
|
|
|
|
// Reading
|
|
|
|
//
|
|
|
|
//--------------------------------------------------------------------------
|
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
/** Read a message
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
This function is used to synchronously read a complete
|
|
|
|
message from the stream.
|
2017-07-25 08:50:58 -07:00
|
|
|
The call blocks until one of the following is true:
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
@li A complete message is received.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-25 08:50:58 -07:00
|
|
|
@li A close frame is received. In this case the error indicated by
|
|
|
|
the function will be @ref error::closed.
|
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
2017-07-25 08:50:58 -07:00
|
|
|
This operation is implemented in terms of one or more calls to the next
|
|
|
|
layer's `read_some` and `write_some` functions.
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
Received message data, if any, is appended to the input area of the
|
|
|
|
buffer. The functions @ref got_binary and @ref got_text may be used
|
|
|
|
to query the stream and determine the type of the last received message.
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-25 08:50:58 -07:00
|
|
|
While this operation is active, the implementation will read incoming
|
|
|
|
control frames and handle them automatically as follows:
|
2017-02-07 19:11:24 -05:00
|
|
|
|
2017-07-25 08:50:58 -07:00
|
|
|
@li The @ref control_callback will be invoked for each control frame.
|
2017-02-07 19:11:24 -05:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li For each received ping frame, a pong frame will be
|
|
|
|
automatically sent.
|
2017-02-07 19:11:24 -05:00
|
|
|
|
2017-07-25 08:50:58 -07:00
|
|
|
@li If a close frame is received, the WebSocket close procedure is
|
|
|
|
performed. In this case, when the function returns, the error
|
|
|
|
@ref error::closed will be indicated.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-25 08:50:58 -07:00
|
|
|
@return The number of message payload bytes appended to the buffer.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-25 08:50:58 -07:00
|
|
|
@param buffer A dynamic buffer to hold the message data after any
|
|
|
|
masking or decompression has been applied.
|
|
|
|
|
|
|
|
@throws system_error Thrown to indicate an error. The corresponding
|
|
|
|
error code may be retrieved from the exception object for inspection.
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
2016-05-28 09:23:54 -04:00
|
|
|
template<class DynamicBuffer>
|
2017-07-25 08:50:58 -07:00
|
|
|
std::size_t
|
2017-06-08 19:55:42 -07:00
|
|
|
read(DynamicBuffer& buffer);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
/** Read a message
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
This function is used to synchronously read a complete
|
|
|
|
message from the stream.
|
|
|
|
The call blocks until one of the following is true:
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
@li A complete message is received.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li A close frame is received. In this case the error indicated by
|
|
|
|
the function will be @ref error::closed.
|
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
This operation is implemented in terms of one or more calls to the next
|
|
|
|
layer's `read_some` and `write_some` functions.
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
Received message data, if any, is appended to the input area of the
|
|
|
|
buffer. The functions @ref got_binary and @ref got_text may be used
|
|
|
|
to query the stream and determine the type of the last received message.
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
While this operation is active, the implementation will read incoming
|
|
|
|
control frames and handle them automatically as follows:
|
2017-02-07 19:11:24 -05:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li The @ref control_callback will be invoked for each control frame.
|
2017-02-07 19:11:24 -05:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li For each received ping frame, a pong frame will be
|
|
|
|
automatically sent.
|
2017-02-07 19:11:24 -05:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li If a close frame is received, the WebSocket close procedure is
|
|
|
|
performed. In this case, when the function returns, the error
|
|
|
|
@ref error::closed will be indicated.
|
2017-02-06 20:07:03 -05:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@return The number of message payload bytes appended to the buffer.
|
|
|
|
|
|
|
|
@param buffer A dynamic buffer to hold the message data after any
|
|
|
|
masking or decompression has been applied.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
@param ec Set to indicate what error occurred, if any.
|
|
|
|
*/
|
2016-05-28 09:23:54 -04:00
|
|
|
template<class DynamicBuffer>
|
2017-07-25 08:50:58 -07:00
|
|
|
std::size_t
|
2017-06-08 19:55:42 -07:00
|
|
|
read(DynamicBuffer& buffer, error_code& ec);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
/** Read a message asynchronously
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
This function is used to asynchronously read a complete
|
|
|
|
message from the stream.
|
|
|
|
The function call always returns immediately.
|
|
|
|
The asynchronous operation will continue until one of the
|
|
|
|
following is true:
|
2016-05-01 12:33:35 -04:00
|
|
|
|
|
|
|
@li A complete message is received.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li A close frame is received. In this case the error indicated by
|
|
|
|
the function will be @ref error::closed.
|
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
|
|
|
This operation is implemented in terms of one or more calls to the
|
|
|
|
next layer's `async_read_some` and `async_write_some` functions,
|
|
|
|
and is known as a <em>composed operation</em>. The program must
|
2016-05-15 16:22:25 -04:00
|
|
|
ensure that the stream performs no other reads until this operation
|
2016-05-01 12:33:35 -04:00
|
|
|
completes.
|
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
Received message data, if any, is appended to the input area of the
|
|
|
|
buffer. The functions @ref got_binary and @ref got_text may be used
|
|
|
|
to query the stream and determine the type of the last received message.
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
While this operation is active, the implementation will read incoming
|
|
|
|
control frames and handle them automatically as follows:
|
2017-02-07 19:11:24 -05:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li The @ref control_callback will be invoked for each control frame.
|
2017-02-07 19:11:24 -05:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li For each received ping frame, a pong frame will be
|
|
|
|
automatically sent.
|
2017-02-07 19:11:24 -05:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li If a close frame is received, the WebSocket close procedure is
|
|
|
|
performed. In this case, when the function returns, the error
|
|
|
|
@ref error::closed will be indicated.
|
2017-02-06 20:07:03 -05:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
Because of the need to handle control frames, asynchronous read
|
|
|
|
operations can cause writes to take place. These writes are managed
|
2017-02-03 16:22:28 -05:00
|
|
|
transparently; callers can still have one active asynchronous
|
|
|
|
read and asynchronous write operation pending simultaneously
|
|
|
|
(a user initiated call to @ref async_close counts as a write).
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-05-13 09:27:06 -07:00
|
|
|
@param buffer A dynamic buffer to hold the message data after
|
2016-05-28 09:23:54 -04:00
|
|
|
any masking or decompression has been applied. This object must
|
|
|
|
remain valid until the handler is called.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
@param handler The handler to be called when the read operation
|
|
|
|
completes. Copies will be made of the handler as required. The
|
2017-07-25 10:35:16 -07:00
|
|
|
equivalent function signature of the handler must be:
|
2017-07-20 08:01:46 -07:00
|
|
|
@code
|
|
|
|
void handler(
|
2017-07-25 08:50:58 -07:00
|
|
|
error_code const& ec, // Result of operation
|
2017-07-25 10:35:16 -07:00
|
|
|
std::size_t bytes_written // Number of bytes appended to buffer
|
2017-07-20 08:01:46 -07:00
|
|
|
);
|
|
|
|
@endcode
|
|
|
|
Regardless of whether the asynchronous operation completes
|
|
|
|
immediately or not, the handler will not be invoked from within
|
|
|
|
this function. Invocation of the handler will be performed in a
|
2016-05-01 12:33:35 -04:00
|
|
|
manner equivalent to using `boost::asio::io_service::post`.
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
2016-05-28 09:23:54 -04:00
|
|
|
template<class DynamicBuffer, class ReadHandler>
|
2017-07-20 13:40:34 -07:00
|
|
|
#if BOOST_BEAST_DOXYGEN
|
2017-05-23 15:50:15 -07:00
|
|
|
void_or_deduced
|
|
|
|
#else
|
2017-05-12 17:13:03 -07:00
|
|
|
async_return_type<
|
2017-07-25 08:50:58 -07:00
|
|
|
ReadHandler,
|
|
|
|
void(error_code, std::size_t)>
|
2017-05-23 15:50:15 -07:00
|
|
|
#endif
|
2017-07-25 08:50:58 -07:00
|
|
|
async_read(
|
|
|
|
DynamicBuffer& buffer,
|
|
|
|
ReadHandler&& handler);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-15 17:05:24 -07:00
|
|
|
//--------------------------------------------------------------------------
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
/** Read part of a message
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
This function is used to synchronously read some
|
|
|
|
message data from the stream.
|
|
|
|
The call blocks until one of the following is true:
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li Some or all of the message is received.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li A close frame is received. In this case the error indicated by
|
|
|
|
the function will be @ref error::closed.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
This operation is implemented in terms of one or more calls to the next
|
|
|
|
layer's `read_some` and `write_some` functions.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
Received message data, if any, is appended to the input area of the
|
|
|
|
buffer. The functions @ref got_binary and @ref got_text may be used
|
|
|
|
to query the stream and determine the type of the last received message.
|
|
|
|
The function @ref is_message_done may be called to determine if the
|
|
|
|
message received by the last read operation is complete.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
While this operation is active, the implementation will read incoming
|
|
|
|
control frames and handle them automatically as follows:
|
2017-02-07 19:11:24 -05:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li The @ref control_callback will be invoked for each control frame.
|
2017-02-07 19:11:24 -05:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li For each received ping frame, a pong frame will be
|
|
|
|
automatically sent.
|
2017-02-06 20:07:03 -05:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li If a close frame is received, the WebSocket close procedure is
|
|
|
|
performed. In this case, when the function returns, the error
|
|
|
|
@ref error::closed will be indicated.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@return The number of message payload bytes appended to the buffer.
|
2017-06-08 20:34:27 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@param buffer A dynamic buffer to hold the message data after any
|
|
|
|
masking or decompression has been applied.
|
|
|
|
|
|
|
|
@param limit An upper limit on the number of bytes this function
|
|
|
|
will append into the buffer. If this value is zero, then a reasonable
|
|
|
|
size will be chosen automatically.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@throws system_error Thrown to indicate an error. The corresponding
|
|
|
|
error code may be retrieved from the exception object for inspection.
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
2016-05-28 09:23:54 -04:00
|
|
|
template<class DynamicBuffer>
|
2017-07-15 17:05:24 -07:00
|
|
|
std::size_t
|
|
|
|
read_some(
|
|
|
|
DynamicBuffer& buffer,
|
|
|
|
std::size_t limit);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
/** Read part of a message
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
This function is used to synchronously read some
|
|
|
|
message data from the stream.
|
|
|
|
The call blocks until one of the following is true:
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li Some or all of the message is received.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li A close frame is received. In this case the error indicated by
|
|
|
|
the function will be @ref error::closed.
|
2016-05-01 12:33:35 -04:00
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
This operation is implemented in terms of one or more calls to the next
|
|
|
|
layer's `read_some` and `write_some` functions.
|
|
|
|
|
|
|
|
Received message data, if any, is appended to the input area of the
|
|
|
|
buffer. The functions @ref got_binary and @ref got_text may be used
|
|
|
|
to query the stream and determine the type of the last received message.
|
|
|
|
The function @ref is_message_done may be called to determine if the
|
|
|
|
message received by the last read operation is complete.
|
|
|
|
|
|
|
|
While this operation is active, the implementation will read incoming
|
|
|
|
control frames and handle them automatically as follows:
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li The @ref control_callback will be invoked for each control frame.
|
2017-02-07 19:11:24 -05:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li For each received ping frame, a pong frame will be
|
|
|
|
automatically sent.
|
2017-02-07 19:11:24 -05:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li If a close frame is received, the WebSocket close procedure is
|
|
|
|
performed. In this case, when the function returns, the error
|
|
|
|
@ref error::closed will be indicated.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@return The number of message payload bytes appended to the buffer.
|
2017-02-06 20:07:03 -05:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@param buffer A dynamic buffer to hold the message data after any
|
|
|
|
masking or decompression has been applied.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@param limit An upper limit on the number of bytes this function
|
|
|
|
will append into the buffer. If this value is zero, then a reasonable
|
2017-07-15 17:05:24 -07:00
|
|
|
size will be chosen automatically.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
@param ec Set to indicate what error occurred, if any.
|
|
|
|
*/
|
2016-05-28 09:23:54 -04:00
|
|
|
template<class DynamicBuffer>
|
2017-07-15 17:05:24 -07:00
|
|
|
std::size_t
|
|
|
|
read_some(
|
|
|
|
DynamicBuffer& buffer,
|
|
|
|
std::size_t limit,
|
|
|
|
error_code& ec);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
/** Read part of a message asynchronously
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
This function is used to asynchronously read part of a
|
|
|
|
message from the stream.
|
|
|
|
The function call always returns immediately.
|
|
|
|
The asynchronous operation will continue until one of the
|
|
|
|
following is true:
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li Some or all of the message is received.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li A close frame is received. In this case the error indicated by
|
|
|
|
the function will be @ref error::closed.
|
2016-05-01 12:33:35 -04:00
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
|
|
|
This operation is implemented in terms of one or more calls to the
|
2017-07-25 10:35:16 -07:00
|
|
|
next layer's `async_read_some` and `async_write_some` functions,
|
|
|
|
and is known as a <em>composed operation</em>. The program must
|
|
|
|
ensure that the stream performs no other reads until this operation
|
|
|
|
completes.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
Received message data, if any, is appended to the input area of the
|
|
|
|
buffer. The functions @ref got_binary and @ref got_text may be used
|
|
|
|
to query the stream and determine the type of the last received message.
|
|
|
|
The function @ref is_message_done may be called to determine if the
|
|
|
|
message received by the last read operation is complete.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
While this operation is active, the implementation will read incoming
|
|
|
|
control frames and handle them automatically as follows:
|
2017-02-07 19:11:24 -05:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li The @ref control_callback will be invoked for each control frame.
|
2017-02-07 19:11:24 -05:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li For each received ping frame, a pong frame will be
|
|
|
|
automatically sent.
|
2017-02-07 19:11:24 -05:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li If a close frame is received, the WebSocket close procedure is
|
|
|
|
performed. In this case, when the function returns, the error
|
|
|
|
@ref error::closed will be indicated.
|
2017-02-06 20:07:03 -05:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
Because of the need to handle control frames, asynchronous read
|
|
|
|
operations can cause writes to take place. These writes are managed
|
2017-02-03 16:22:28 -05:00
|
|
|
transparently; callers can still have one active asynchronous
|
|
|
|
read and asynchronous write operation pending simultaneously
|
|
|
|
(a user initiated call to @ref async_close counts as a write).
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@param buffer A dynamic buffer to hold the message data after
|
|
|
|
any masking or decompression has been applied. This object must
|
|
|
|
remain valid until the handler is called.
|
|
|
|
|
|
|
|
@param limit An upper limit on the number of bytes this function
|
|
|
|
will append into the buffer. If this value is zero, then a reasonable
|
|
|
|
size will be chosen automatically.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
@param handler The handler to be called when the read operation
|
|
|
|
completes. Copies will be made of the handler as required. The
|
2017-07-25 10:35:16 -07:00
|
|
|
equivalent function signature of the handler must be:
|
2017-07-20 08:01:46 -07:00
|
|
|
@code
|
|
|
|
void handler(
|
2017-07-25 10:35:16 -07:00
|
|
|
error_code const& ec, // Result of operation
|
|
|
|
std::size_t bytes_written // Number of bytes appended to buffer
|
2017-07-20 08:01:46 -07:00
|
|
|
);
|
|
|
|
@endcode
|
|
|
|
Regardless of whether the asynchronous operation completes
|
|
|
|
immediately or not, the handler will not be invoked from within
|
|
|
|
this function. Invocation of the handler will be performed in a
|
2017-07-15 17:05:24 -07:00
|
|
|
manner equivalent to using `boost::asio::io_service::post`.
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
2016-05-28 09:23:54 -04:00
|
|
|
template<class DynamicBuffer, class ReadHandler>
|
2017-07-20 13:40:34 -07:00
|
|
|
#if BOOST_BEAST_DOXYGEN
|
2017-05-23 15:50:15 -07:00
|
|
|
void_or_deduced
|
|
|
|
#else
|
2017-07-15 17:05:24 -07:00
|
|
|
async_return_type<
|
|
|
|
ReadHandler, void(error_code, std::size_t)>
|
2017-05-23 15:50:15 -07:00
|
|
|
#endif
|
2017-07-15 17:05:24 -07:00
|
|
|
async_read_some(
|
|
|
|
DynamicBuffer& buffer,
|
|
|
|
std::size_t limit,
|
|
|
|
ReadHandler&& handler);
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------------
|
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
/** Read part of a message
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
This function is used to synchronously read some
|
|
|
|
message data from the stream.
|
|
|
|
The call blocks until one of the following is true:
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li Some or all of the message is received.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li A close frame is received. In this case the error indicated by
|
|
|
|
the function will be @ref error::closed.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
This operation is implemented in terms of one or more calls to the next
|
|
|
|
layer's `read_some` and `write_some` functions.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
Received message data, if any, is written to the buffer sequence.
|
|
|
|
The functions @ref got_binary and @ref got_text may be used
|
|
|
|
to query the stream and determine the type of the last received message.
|
|
|
|
The function @ref is_message_done may be called to determine if the
|
|
|
|
message received by the last read operation is complete.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
While this operation is active, the implementation will read incoming
|
|
|
|
control frames and handle them automatically as follows:
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li The @ref control_callback will be invoked for each control frame.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li For each received ping frame, a pong frame will be
|
|
|
|
automatically sent.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li If a close frame is received, the WebSocket close procedure is
|
|
|
|
performed. In this case, when the function returns, the error
|
|
|
|
@ref error::closed will be indicated.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@return The number of message payload bytes written to the
|
|
|
|
buffer sequence.
|
|
|
|
|
|
|
|
@param buffers A buffer sequence to hold the message data after any
|
|
|
|
masking or decompression has been applied.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@throws system_error Thrown to indicate an error. The corresponding
|
|
|
|
error code may be retrieved from the exception object for inspection.
|
2017-07-15 17:05:24 -07:00
|
|
|
*/
|
|
|
|
template<class MutableBufferSequence>
|
|
|
|
std::size_t
|
|
|
|
read_some(
|
|
|
|
MutableBufferSequence const& buffers);
|
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
/** Read part of a message
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
This function is used to synchronously read some
|
|
|
|
message data from the stream.
|
|
|
|
The call blocks until one of the following is true:
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li Some or all of the message is received.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li A close frame is received. In this case the error indicated by
|
|
|
|
the function will be @ref error::closed.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
This operation is implemented in terms of one or more calls to the next
|
|
|
|
layer's `read_some` and `write_some` functions.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
Received message data, if any, is written to the buffer sequence.
|
|
|
|
The functions @ref got_binary and @ref got_text may be used
|
|
|
|
to query the stream and determine the type of the last received message.
|
|
|
|
The function @ref is_message_done may be called to determine if the
|
|
|
|
message received by the last read operation is complete.
|
|
|
|
|
|
|
|
While this operation is active, the implementation will read incoming
|
|
|
|
control frames and handle them automatically as follows:
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li The @ref control_callback will be invoked for each control frame.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li For each received ping frame, a pong frame will be
|
|
|
|
automatically sent.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li If a close frame is received, the WebSocket close procedure is
|
|
|
|
performed. In this case, when the function returns, the error
|
|
|
|
@ref error::closed will be indicated.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@return The number of message payload bytes written to the
|
|
|
|
buffer sequence.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@param buffers A buffer sequence to hold the message data after any
|
|
|
|
masking or decompression has been applied.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@param ec Set to indicate what error occurred, if any.
|
2017-07-15 17:05:24 -07:00
|
|
|
*/
|
|
|
|
template<class MutableBufferSequence>
|
|
|
|
std::size_t
|
|
|
|
read_some(
|
|
|
|
MutableBufferSequence const& buffers,
|
|
|
|
error_code& ec);
|
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
/** Read part of a message asynchronously
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
This function is used to asynchronously read part of a
|
|
|
|
message from the stream.
|
|
|
|
The function call always returns immediately.
|
|
|
|
The asynchronous operation will continue until one of the
|
|
|
|
following is true:
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li Some or all of the message is received.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li A close frame is received. In this case the error indicated by
|
|
|
|
the function will be @ref error::closed.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
|
|
|
This operation is implemented in terms of one or more calls to the
|
2017-07-25 10:35:16 -07:00
|
|
|
next layer's `async_read_some` and `async_write_some` functions,
|
|
|
|
and is known as a <em>composed operation</em>. The program must
|
|
|
|
ensure that the stream performs no other reads until this operation
|
|
|
|
completes.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
Received message data, if any, is written to the buffer sequence.
|
|
|
|
The functions @ref got_binary and @ref got_text may be used
|
|
|
|
to query the stream and determine the type of the last received message.
|
|
|
|
The function @ref is_message_done may be called to determine if the
|
|
|
|
message received by the last read operation is complete.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
While this operation is active, the implementation will read incoming
|
|
|
|
control frames and handle them automatically as follows:
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li The @ref control_callback will be invoked for each control frame.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li For each received ping frame, a pong frame will be
|
|
|
|
automatically sent.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@li If a close frame is received, the WebSocket close procedure is
|
|
|
|
performed. In this case, when the function returns, the error
|
|
|
|
@ref error::closed will be indicated.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
Because of the need to handle control frames, asynchronous read
|
|
|
|
operations can cause writes to take place. These writes are managed
|
2017-07-15 17:05:24 -07:00
|
|
|
transparently; callers can still have one active asynchronous
|
|
|
|
read and asynchronous write operation pending simultaneously
|
|
|
|
(a user initiated call to @ref async_close counts as a write).
|
|
|
|
|
2017-07-25 10:35:16 -07:00
|
|
|
@param buffers The buffer sequence into which message data will
|
|
|
|
be placed after any masking or decompresison has been applied.
|
2017-07-15 17:05:24 -07:00
|
|
|
The implementation will make copies of this object as needed,
|
|
|
|
but ownership of the underlying memory is not transferred.
|
|
|
|
The caller is responsible for ensuring that the memory
|
2017-07-25 10:35:16 -07:00
|
|
|
locations pointed to by the buffer sequence remains valid
|
|
|
|
until the completion handler is called.
|
2017-07-15 17:05:24 -07:00
|
|
|
|
|
|
|
@param handler The handler to be called when the read operation
|
|
|
|
completes. Copies will be made of the handler as required. The
|
2017-07-25 10:35:16 -07:00
|
|
|
equivalent function signature of the handler must be:
|
2017-07-15 17:05:24 -07:00
|
|
|
@code
|
|
|
|
void handler(
|
2017-07-25 10:35:16 -07:00
|
|
|
error_code const& ec, // Result of operation
|
|
|
|
std::size_t bytes_written // Number of bytes written to the buffer sequence
|
2017-07-15 17:05:24 -07:00
|
|
|
);
|
|
|
|
@endcode
|
|
|
|
Regardless of whether the asynchronous operation completes
|
|
|
|
immediately or not, the handler will not be invoked from within
|
|
|
|
this function. Invocation of the handler will be performed in a
|
|
|
|
manner equivalent to using `boost::asio::io_service::post`.
|
|
|
|
*/
|
|
|
|
template<class MutableBufferSequence, class ReadHandler>
|
2017-07-20 13:40:34 -07:00
|
|
|
#if BOOST_BEAST_DOXYGEN
|
2017-07-15 17:05:24 -07:00
|
|
|
void_or_deduced
|
|
|
|
#else
|
|
|
|
async_return_type<ReadHandler, void(error_code, std::size_t)>
|
|
|
|
#endif
|
|
|
|
async_read_some(
|
|
|
|
MutableBufferSequence const& buffers,
|
|
|
|
ReadHandler&& handler);
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------------
|
|
|
|
//
|
|
|
|
// Writing
|
|
|
|
//
|
|
|
|
//--------------------------------------------------------------------------
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
/** Write a message to the stream.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
This function is used to synchronously write a message to
|
|
|
|
the stream. The call blocks until one of the following conditions
|
|
|
|
is met:
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
@li The entire message is sent.
|
|
|
|
|
|
|
|
@li An error occurs.
|
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
This operation is implemented in terms of one or more calls to the
|
|
|
|
next layer's `write_some` function.
|
|
|
|
|
2017-06-08 18:03:10 -07:00
|
|
|
The current setting of the @ref binary option controls
|
2016-05-01 12:33:35 -04:00
|
|
|
whether the message opcode is set to text or binary. If the
|
2016-06-10 15:48:39 -04:00
|
|
|
@ref auto_fragment option is set, the message will be split
|
2016-05-01 12:33:35 -04:00
|
|
|
into one or more frames as necessary. The actual payload contents
|
|
|
|
sent may be transformed as per the WebSocket protocol settings.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
@param buffers The buffers containing the entire message
|
|
|
|
payload. The implementation will make copies of this object
|
|
|
|
as needed, but ownership of the underlying memory is not
|
|
|
|
transferred. The caller is responsible for ensuring that
|
|
|
|
the memory locations pointed to by buffers remains valid
|
|
|
|
until the completion handler is called.
|
|
|
|
|
2016-10-04 18:00:11 -04:00
|
|
|
@throws system_error Thrown on failure.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
@note This function always sends an entire message. To
|
2017-07-15 17:05:24 -07:00
|
|
|
send a message in fragments, use @ref write_some.
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
|
|
|
template<class ConstBufferSequence>
|
|
|
|
void
|
2016-04-30 13:00:33 -04:00
|
|
|
write(ConstBufferSequence const& buffers);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
/** Write a message to the stream.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
This function is used to synchronously write a message to
|
|
|
|
the stream. The call blocks until one of the following conditions
|
|
|
|
is met:
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
@li The entire message is sent.
|
|
|
|
|
|
|
|
@li An error occurs.
|
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
This operation is implemented in terms of one or more calls to the
|
|
|
|
next layer's `write_some` function.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-06-08 18:03:10 -07:00
|
|
|
The current setting of the @ref binary option controls
|
2016-05-01 12:33:35 -04:00
|
|
|
whether the message opcode is set to text or binary. If the
|
2016-06-10 15:48:39 -04:00
|
|
|
@ref auto_fragment option is set, the message will be split
|
2016-05-01 12:33:35 -04:00
|
|
|
into one or more frames as necessary. The actual payload contents
|
|
|
|
sent may be transformed as per the WebSocket protocol settings.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
@param buffers The buffers containing the entire message
|
|
|
|
payload. The implementation will make copies of this object
|
|
|
|
as needed, but ownership of the underlying memory is not
|
|
|
|
transferred. The caller is responsible for ensuring that
|
|
|
|
the memory locations pointed to by buffers remains valid
|
|
|
|
until the completion handler is called.
|
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
@param ec Set to indicate what error occurred, if any.
|
|
|
|
|
2016-10-04 18:00:11 -04:00
|
|
|
@throws system_error Thrown on failure.
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-20 08:01:46 -07:00
|
|
|
@note This function always sends an entire message. To
|
2017-07-15 17:05:24 -07:00
|
|
|
send a message in fragments, use @ref write_some.
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
|
|
|
template<class ConstBufferSequence>
|
|
|
|
void
|
|
|
|
write(ConstBufferSequence const& buffers, error_code& ec);
|
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
/** Start an asynchronous operation to write a message to the stream.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-15 16:22:25 -04:00
|
|
|
This function is used to asynchronously write a message to
|
2016-05-01 12:33:35 -04:00
|
|
|
the stream. The function call always returns immediately.
|
|
|
|
The asynchronous operation will continue until one of the
|
|
|
|
following conditions is true:
|
|
|
|
|
|
|
|
@li The entire message is sent.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
@li An error occurs.
|
|
|
|
|
|
|
|
This operation is implemented in terms of one or more calls
|
|
|
|
to the next layer's `async_write_some` functions, and is known
|
|
|
|
as a <em>composed operation</em>. The program must ensure that
|
|
|
|
the stream performs no other write operations (such as
|
2017-07-15 17:05:24 -07:00
|
|
|
stream::async_write, stream::async_write_some, or
|
2016-05-01 12:33:35 -04:00
|
|
|
stream::async_close).
|
|
|
|
|
2017-06-08 18:03:10 -07:00
|
|
|
The current setting of the @ref binary option controls
|
2016-05-01 12:33:35 -04:00
|
|
|
whether the message opcode is set to text or binary. If the
|
2016-06-10 15:48:39 -04:00
|
|
|
@ref auto_fragment option is set, the message will be split
|
2016-05-01 12:33:35 -04:00
|
|
|
into one or more frames as necessary. The actual payload contents
|
|
|
|
sent may be transformed as per the WebSocket protocol settings.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
@param buffers The buffers containing the entire message
|
|
|
|
payload. The implementation will make copies of this object
|
|
|
|
as needed, but ownership of the underlying memory is not
|
|
|
|
transferred. The caller is responsible for ensuring that
|
|
|
|
the memory locations pointed to by buffers remains valid
|
|
|
|
until the completion handler is called.
|
|
|
|
|
|
|
|
@param handler The handler to be called when the write operation
|
|
|
|
completes. Copies will be made of the handler as required. The
|
|
|
|
function signature of the handler must be:
|
|
|
|
@code
|
|
|
|
void handler(
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
error_code const& ec // Result of operation
|
2017-07-20 08:01:46 -07:00
|
|
|
);
|
|
|
|
@endcode
|
|
|
|
Regardless of whether the asynchronous operation completes
|
|
|
|
immediately or not, the handler will not be invoked from within
|
|
|
|
this function. Invocation of the handler will be performed in a
|
2016-05-01 12:33:35 -04:00
|
|
|
manner equivalent to using `boost::asio::io_service::post`.
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
|
|
|
template<class ConstBufferSequence, class WriteHandler>
|
2017-07-20 13:40:34 -07:00
|
|
|
#if BOOST_BEAST_DOXYGEN
|
2017-05-23 15:50:15 -07:00
|
|
|
void_or_deduced
|
|
|
|
#else
|
2017-05-12 17:13:03 -07:00
|
|
|
async_return_type<
|
|
|
|
WriteHandler, void(error_code)>
|
2017-05-23 15:50:15 -07:00
|
|
|
#endif
|
2017-07-20 08:01:46 -07:00
|
|
|
async_write(ConstBufferSequence const& buffers,
|
|
|
|
WriteHandler&& handler);
|
|
|
|
|
2016-06-10 15:48:39 -04:00
|
|
|
/** Write partial message data on the stream.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-06-10 15:48:39 -04:00
|
|
|
This function is used to write some or all of a message's
|
|
|
|
payload to the stream. The call will block until one of the
|
|
|
|
following conditions is true:
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-06-10 15:48:39 -04:00
|
|
|
@li A frame is sent.
|
|
|
|
|
|
|
|
@li Message data is transferred to the write buffer.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
@li An error occurs.
|
|
|
|
|
|
|
|
This operation is implemented in terms of one or more calls
|
2016-05-01 12:33:35 -04:00
|
|
|
to the stream's `write_some` function.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
If this is the beginning of a new message, the message opcode
|
|
|
|
will be set to text or binary as per the current setting of
|
2017-06-08 18:03:10 -07:00
|
|
|
the @ref binary option. The actual payload sent may be
|
|
|
|
transformed as per the WebSocket protocol settings.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
@param fin `true` if this is the last frame in the message.
|
|
|
|
|
2016-06-10 15:48:39 -04:00
|
|
|
@param buffers The input buffer sequence holding the data to write.
|
|
|
|
|
|
|
|
@return The number of bytes consumed in the input buffers.
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2016-10-04 18:00:11 -04:00
|
|
|
@throws system_error Thrown on failure.
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
|
|
|
template<class ConstBufferSequence>
|
|
|
|
void
|
2017-07-15 17:05:24 -07:00
|
|
|
write_some(bool fin, ConstBufferSequence const& buffers);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-06-10 15:48:39 -04:00
|
|
|
/** Write partial message data on the stream.
|
|
|
|
|
|
|
|
This function is used to write some or all of a message's
|
|
|
|
payload to the stream. The call will block until one of the
|
|
|
|
following conditions is true:
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-06-10 15:48:39 -04:00
|
|
|
@li A frame is sent.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-06-10 15:48:39 -04:00
|
|
|
@li Message data is transferred to the write buffer.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
@li An error occurs.
|
|
|
|
|
|
|
|
This operation is implemented in terms of one or more calls
|
2016-06-10 15:48:39 -04:00
|
|
|
to the stream's `write_some` function.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
If this is the beginning of a new message, the message opcode
|
|
|
|
will be set to text or binary as per the current setting of
|
2017-06-08 18:03:10 -07:00
|
|
|
the @ref binary option. The actual payload sent may be
|
|
|
|
transformed as per the WebSocket protocol settings.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
@param fin `true` if this is the last frame in the message.
|
|
|
|
|
2016-06-10 15:48:39 -04:00
|
|
|
@param buffers The input buffer sequence holding the data to write.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
@param ec Set to indicate what error occurred, if any.
|
2016-06-10 15:48:39 -04:00
|
|
|
|
|
|
|
@return The number of bytes consumed in the input buffers.
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
|
|
|
template<class ConstBufferSequence>
|
|
|
|
void
|
2017-07-15 17:05:24 -07:00
|
|
|
write_some(bool fin,
|
2017-07-20 08:01:46 -07:00
|
|
|
ConstBufferSequence const& buffers, error_code& ec);
|
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
/** Start an asynchronous operation to send a message frame on the stream.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
This function is used to asynchronously write a message frame
|
|
|
|
on the stream. This function call always returns immediately.
|
|
|
|
The asynchronous operation will continue until one of the following
|
|
|
|
conditions is true:
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
@li The entire frame is sent.
|
|
|
|
|
|
|
|
@li An error occurs.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
This operation is implemented in terms of one or more calls
|
2016-05-01 12:33:35 -04:00
|
|
|
to the next layer's `async_write_some` functions, and is known
|
|
|
|
as a <em>composed operation</em>. The actual payload sent
|
|
|
|
may be transformed as per the WebSocket protocol settings. The
|
|
|
|
program must ensure that the stream performs no other write
|
2017-07-15 17:05:24 -07:00
|
|
|
operations (such as stream::async_write, stream::async_write_some,
|
2016-05-01 12:33:35 -04:00
|
|
|
or stream::async_close).
|
|
|
|
|
|
|
|
If this is the beginning of a new message, the message opcode
|
|
|
|
will be set to text or binary as per the current setting of
|
2017-06-08 18:03:10 -07:00
|
|
|
the @ref binary option. The actual payload sent may be
|
|
|
|
transformed as per the WebSocket protocol settings.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
@param fin A bool indicating whether or not the frame is the
|
|
|
|
last frame in the corresponding WebSockets message.
|
|
|
|
|
|
|
|
@param buffers A object meeting the requirements of
|
|
|
|
ConstBufferSequence which holds the payload data before any
|
|
|
|
masking or compression. Although the buffers object may be copied
|
|
|
|
as necessary, ownership of the underlying buffers is retained by
|
|
|
|
the caller, which must guarantee that they remain valid until
|
|
|
|
the handler is called.
|
|
|
|
|
|
|
|
@param handler The handler to be called when the write completes.
|
|
|
|
Copies will be made of the handler as required. The equivalent
|
|
|
|
function signature of the handler must be:
|
|
|
|
@code void handler(
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
error_code const& ec // Result of operation
|
2017-07-20 08:01:46 -07:00
|
|
|
); @endcode
|
|
|
|
*/
|
|
|
|
template<class ConstBufferSequence, class WriteHandler>
|
2017-07-20 13:40:34 -07:00
|
|
|
#if BOOST_BEAST_DOXYGEN
|
2017-05-23 15:50:15 -07:00
|
|
|
void_or_deduced
|
|
|
|
#else
|
2017-05-12 17:13:03 -07:00
|
|
|
async_return_type<
|
|
|
|
WriteHandler, void(error_code)>
|
2017-05-23 15:50:15 -07:00
|
|
|
#endif
|
2017-07-15 17:05:24 -07:00
|
|
|
async_write_some(bool fin,
|
2017-07-20 08:01:46 -07:00
|
|
|
ConstBufferSequence const& buffers, WriteHandler&& handler);
|
|
|
|
|
|
|
|
private:
|
2017-07-15 17:05:24 -07:00
|
|
|
enum class fail_how
|
|
|
|
{
|
|
|
|
code = 1, // send close code, teardown, finish with error::failed
|
|
|
|
close = 2, // send frame in fb, teardown, finish with error::closed
|
|
|
|
teardown = 3 // teardown, finish with error::failed
|
|
|
|
};
|
|
|
|
|
|
|
|
template<class, class> class accept_op;
|
|
|
|
template<class> class close_op;
|
|
|
|
template<class> class fail_op;
|
|
|
|
template<class> class handshake_op;
|
|
|
|
template<class> class ping_op;
|
|
|
|
template<class> class read_fh_op;
|
|
|
|
template<class, class> class read_some_op;
|
|
|
|
template<class, class> class read_op;
|
|
|
|
template<class> class response_op;
|
|
|
|
template<class, class> class write_some_op;
|
|
|
|
template<class, class> class write_op;
|
2017-07-14 12:11:44 -07:00
|
|
|
|
|
|
|
static void default_decorate_req(request_type&) {}
|
|
|
|
static void default_decorate_res(response_type&) {}
|
|
|
|
|
|
|
|
void open(role_type role);
|
|
|
|
void close();
|
|
|
|
void reset();
|
|
|
|
void wr_begin();
|
|
|
|
|
2017-07-15 17:05:24 -07:00
|
|
|
template<class DynamicBuffer>
|
|
|
|
bool
|
|
|
|
parse_fh(detail::frame_header& fh,
|
|
|
|
DynamicBuffer& b, close_code& code);
|
|
|
|
|
2017-07-14 12:11:44 -07:00
|
|
|
template<class DynamicBuffer>
|
2017-04-25 10:12:43 -07:00
|
|
|
void
|
2017-07-14 12:11:44 -07:00
|
|
|
write_close(DynamicBuffer& db, close_reason const& rc);
|
2017-04-25 10:12:43 -07:00
|
|
|
|
2017-07-14 12:11:44 -07:00
|
|
|
template<class DynamicBuffer>
|
2017-04-25 10:12:43 -07:00
|
|
|
void
|
2017-07-14 12:11:44 -07:00
|
|
|
write_ping(DynamicBuffer& db,
|
|
|
|
detail::opcode op, ping_data const& data);
|
|
|
|
|
|
|
|
template<class Decorator>
|
|
|
|
request_type
|
|
|
|
build_request(detail::sec_ws_key_type& key,
|
|
|
|
string_view host,
|
|
|
|
string_view target,
|
|
|
|
Decorator const& decorator);
|
|
|
|
|
2017-07-14 13:00:09 -07:00
|
|
|
template<class Body,
|
|
|
|
class Allocator, class Decorator>
|
2017-07-14 12:11:44 -07:00
|
|
|
response_type
|
2017-07-14 13:00:09 -07:00
|
|
|
build_response(http::request<Body,
|
2017-07-14 12:11:44 -07:00
|
|
|
http::basic_fields<Allocator>> const& req,
|
|
|
|
Decorator const& decorator);
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-08-02 13:25:53 -07:00
|
|
|
void
|
|
|
|
on_response(response_type const& resp,
|
|
|
|
detail::sec_ws_key_type const& key, error_code& ec);
|
|
|
|
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
template<class Decorator>
|
|
|
|
void
|
|
|
|
do_accept(Decorator const& decorator,
|
2017-04-25 10:12:43 -07:00
|
|
|
error_code& ec);
|
|
|
|
|
2017-07-14 13:00:09 -07:00
|
|
|
template<class Body, class Allocator,
|
|
|
|
class Decorator>
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
void
|
2017-07-14 13:00:09 -07:00
|
|
|
do_accept(http::request<Body,
|
2017-06-19 13:01:59 -07:00
|
|
|
http::basic_fields<Allocator>> const& req,
|
|
|
|
Decorator const& decorator, error_code& ec);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
template<class RequestDecorator>
|
|
|
|
void
|
|
|
|
do_handshake(response_type* res_p,
|
2017-07-14 13:00:09 -07:00
|
|
|
string_view host, string_view target,
|
|
|
|
RequestDecorator const& decorator,
|
|
|
|
error_code& ec);
|
Refactor websocket decorators (API Change):
fix #80, #212, fix #303, fix #314, fix #317
websocket::stream now provides the following families of
functions for performing handshakes:
When operating in the server role:
* stream::accept
* stream::accept_ex
* stream::async_accept
* stream::async_accept_ex
When operating in the client role:
* stream::handshake
* stream::handshake_ex
* stream::async_handshake
* stream::async_handshake_ex
Member functions ending with "_ex" allow an additional
RequestDecorator parameter (for the accept family of
functions) or ResponseDecorator parameter (for the
handshake family of functions).
The decorator is called to optionally modify the contents
of the HTTP request or HTTP response object generated by
the implementation, before the message is sent. This
permits callers to set the User-Agent or Server fields,
add or modify HTTP fields related to subprotocols, or
perform any required transformation of the HTTP message
for application-specific needs.
The handshake() family of functions now have an additional
set of overloads accepting a parameter of type response_type&,
allowing the caller to receive the HTTP Response to the
Upgrade handshake. This permits inspection of the response
to handle things like subprotocols, authentication, or
other application-specific needs.
The new implementation does not require any state to be
stored in the stream object. Therefore, websocket::stream
objects are now smaller in size.
The overload of set_option for setting a decorator on the
stream is removed. The only way to set decorators now is
with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
|
|
|
|
2017-07-20 08:01:46 -07:00
|
|
|
void
|
2017-08-02 13:25:53 -07:00
|
|
|
do_fail(
|
2017-08-01 20:15:07 -07:00
|
|
|
std::uint16_t code,
|
2017-08-02 13:25:53 -07:00
|
|
|
error_code ev,
|
|
|
|
error_code& ec);
|
|
|
|
|
|
|
|
template<class Handler>
|
|
|
|
void
|
|
|
|
do_async_fail(
|
2017-08-01 20:15:07 -07:00
|
|
|
std::uint16_t code,
|
2017-08-02 13:25:53 -07:00
|
|
|
error_code ev,
|
|
|
|
Handler&& handler);
|
2017-07-20 08:01:46 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
} // websocket
|
|
|
|
} // beast
|
2017-07-20 13:40:34 -07:00
|
|
|
} // boost
|
|
|
|
|
|
|
|
#include <boost/beast/websocket/impl/accept.ipp>
|
|
|
|
#include <boost/beast/websocket/impl/close.ipp>
|
|
|
|
#include <boost/beast/websocket/impl/fail.ipp>
|
|
|
|
#include <boost/beast/websocket/impl/handshake.ipp>
|
|
|
|
#include <boost/beast/websocket/impl/ping.ipp>
|
|
|
|
#include <boost/beast/websocket/impl/read.ipp>
|
|
|
|
#include <boost/beast/websocket/impl/stream.ipp>
|
|
|
|
#include <boost/beast/websocket/impl/write.ipp>
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
#endif
|