2017-07-20 08:01:46 -07:00
|
|
|
//
|
2017-02-06 20:07:03 -05:00
|
|
|
// Copyright (c) 2013-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)
|
|
|
|
//
|
|
|
|
|
|
|
|
#ifndef BEAST_WEBSOCKET_STREAM_HPP
|
|
|
|
#define BEAST_WEBSOCKET_STREAM_HPP
|
|
|
|
|
2017-04-10 19:24:27 -07:00
|
|
|
#include <beast/config.hpp>
|
2017-07-20 08:01:46 -07:00
|
|
|
#include <beast/websocket/option.hpp>
|
|
|
|
#include <beast/websocket/detail/stream_base.hpp>
|
2016-10-09 06:34:35 -04:00
|
|
|
#include <beast/http/message.hpp>
|
2016-05-01 11:14:10 -04:00
|
|
|
#include <beast/http/string_body.hpp>
|
2016-05-07 14:57:15 -04:00
|
|
|
#include <beast/core/async_completion.hpp>
|
2017-04-25 10:12:43 -07:00
|
|
|
#include <beast/core/dynabuf_readstream.hpp>
|
2016-05-07 14:57:15 -04:00
|
|
|
#include <beast/core/detail/get_lowest_layer.hpp>
|
2017-07-20 08:01:46 -07:00
|
|
|
#include <boost/asio.hpp>
|
|
|
|
#include <boost/utility/string_ref.hpp>
|
|
|
|
#include <algorithm>
|
|
|
|
#include <cstdint>
|
|
|
|
#include <limits>
|
2017-04-25 10:12:43 -07:00
|
|
|
#include <type_traits>
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
namespace beast {
|
|
|
|
namespace websocket {
|
|
|
|
|
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
|
|
|
|
using request_type = http::request_header;
|
|
|
|
|
|
|
|
/// The type of object holding HTTP Upgrade responses
|
|
|
|
using response_type =
|
|
|
|
//http::response_header;
|
|
|
|
http::response<http::string_body, http::fields>;
|
|
|
|
|
2017-07-20 08:01:46 -07:00
|
|
|
/** Information about a WebSocket frame.
|
|
|
|
|
|
|
|
This information is provided to callers during frame
|
|
|
|
read operations.
|
|
|
|
*/
|
|
|
|
struct frame_info
|
|
|
|
{
|
|
|
|
/// Indicates the type of message (binary or text).
|
|
|
|
opcode op;
|
|
|
|
|
|
|
|
/// `true` if this is the last frame in the current message.
|
|
|
|
bool fin;
|
|
|
|
};
|
|
|
|
|
|
|
|
//--------------------------------------------------------------------
|
|
|
|
|
|
|
|
/** 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.
|
|
|
|
|
|
|
|
@par Thread Safety
|
|
|
|
@e Distinct @e objects: Safe.@n
|
|
|
|
@e Shared @e objects: Unsafe. The application must ensure that
|
|
|
|
all asynchronous operations are performed within the same
|
|
|
|
implicit or explicit strand.
|
|
|
|
|
|
|
|
@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
|
|
|
|
ip::tcp::socket sock(io_service);
|
|
|
|
websocket::stream<ip::tcp::socket&> ws(sock);
|
|
|
|
@endcode
|
|
|
|
|
2016-05-01 12:33:35 -04: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.
|
2016-05-15 16:22:25 -04:00
|
|
|
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
|
2016-05-01 12:33:35 -04:00
|
|
|
@b `AsyncStream`,
|
2016-05-28 09:23:54 -04:00
|
|
|
@b `DynamicBuffer`,
|
2016-05-01 12:33:35 -04:00
|
|
|
@b `SyncStream`
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
|
|
|
template<class NextLayer>
|
|
|
|
class stream : public detail::stream_base
|
|
|
|
{
|
2016-05-15 16:22:25 -04:00
|
|
|
friend class stream_test;
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-28 09:23:54 -04:00
|
|
|
dynabuf_readstream<NextLayer, streambuf> stream_;
|
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-04-22 14:56:09 -07:00
|
|
|
#if BEAST_DOXYGEN
|
2016-05-01 12:33:35 -04:00
|
|
|
implementation_defined;
|
2016-05-27 11:17:53 -04:00
|
|
|
#else
|
2016-04-30 13:00:33 -04:00
|
|
|
typename beast::detail::get_lowest_layer<
|
|
|
|
next_layer_type>::type;
|
2016-05-27 11:17:53 -04:00
|
|
|
#endif
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-04-30 13:00:33 -04:00
|
|
|
/** Move-construct a stream.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-04-30 13:00:33 -04:00
|
|
|
If @c NextLayer is move constructible, this function
|
|
|
|
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;
|
|
|
|
|
|
|
|
/** Move assignment.
|
|
|
|
|
2016-05-01 12:33:35 -04: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.
|
|
|
|
|
|
|
|
@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;
|
|
|
|
|
|
|
|
/** Construct a WebSocket stream.
|
|
|
|
|
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);
|
|
|
|
|
|
|
|
/** Destructor.
|
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
@note A stream object must not be destroyed while there
|
|
|
|
are pending asynchronous operations associated with it.
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
|
|
|
~stream() = default;
|
|
|
|
|
|
|
|
/** Set options on the stream.
|
|
|
|
|
|
|
|
The application must ensure that calls to set options
|
|
|
|
are performed within the same implicit or explicit strand.
|
|
|
|
|
|
|
|
@param args One or more stream options to set.
|
|
|
|
*/
|
2017-04-22 14:56:09 -07:00
|
|
|
#if BEAST_DOXYGEN
|
2017-07-20 08:01:46 -07:00
|
|
|
template<class... Args>
|
|
|
|
void
|
|
|
|
set_option(Args&&... args)
|
|
|
|
#else
|
|
|
|
template<class A1, class A2, class... An>
|
|
|
|
void
|
|
|
|
set_option(A1&& a1, A2&& a2, An&&... an)
|
|
|
|
#endif
|
|
|
|
{
|
|
|
|
set_option(std::forward<A1>(a1));
|
|
|
|
set_option(std::forward<A2>(a2),
|
|
|
|
std::forward<An>(an)...);
|
|
|
|
}
|
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
/// Set the automatic fragment size option
|
2017-07-20 08:01:46 -07:00
|
|
|
void
|
2016-06-10 15:48:39 -04:00
|
|
|
set_option(auto_fragment const& o)
|
2017-07-20 08:01:46 -07:00
|
|
|
{
|
2016-06-10 15:48:39 -04:00
|
|
|
wr_autofrag_ = o.value;
|
2017-07-20 08:01:46 -07:00
|
|
|
}
|
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
/// Set the keep-alive option
|
2017-07-20 08:01:46 -07:00
|
|
|
void
|
|
|
|
set_option(keep_alive const& o)
|
|
|
|
{
|
|
|
|
keep_alive_ = o.value;
|
|
|
|
}
|
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
/// Set the outgoing message type
|
2017-07-20 08:01:46 -07:00
|
|
|
void
|
|
|
|
set_option(message_type const& o)
|
|
|
|
{
|
|
|
|
wr_opcode_ = o.value;
|
|
|
|
}
|
|
|
|
|
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-02-03 16:22:28 -05:00
|
|
|
/// Set the ping callback
|
2016-05-15 16:22:25 -04:00
|
|
|
void
|
2017-02-03 16:22:28 -05:00
|
|
|
set_option(ping_callback o)
|
2016-05-15 16:22:25 -04:00
|
|
|
{
|
2017-02-03 16:22:28 -05:00
|
|
|
ping_cb_ = std::move(o.value);
|
2016-05-15 16:22:25 -04:00
|
|
|
}
|
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
/// Set the read buffer size
|
2017-07-20 08:01:46 -07:00
|
|
|
void
|
|
|
|
set_option(read_buffer_size const& o)
|
|
|
|
{
|
2016-10-24 18:41:25 -04:00
|
|
|
rd_buf_size_ = o.value;
|
|
|
|
// VFALCO What was the thinking here?
|
|
|
|
//stream_.capacity(o.value);
|
2017-07-20 08:01:46 -07:00
|
|
|
}
|
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
/// Set the maximum incoming message size allowed
|
2017-07-20 08:01:46 -07:00
|
|
|
void
|
|
|
|
set_option(read_message_max const& o)
|
|
|
|
{
|
|
|
|
rd_msg_max_ = o.value;
|
|
|
|
}
|
|
|
|
|
2016-10-25 16:45:27 -04:00
|
|
|
/// Set the size of the write buffer
|
2017-07-20 08:01:46 -07:00
|
|
|
void
|
2016-06-10 13:20:41 -04:00
|
|
|
set_option(write_buffer_size const& o)
|
2017-07-20 08:01:46 -07:00
|
|
|
{
|
2016-06-10 13:20:41 -04:00
|
|
|
wr_buf_size_ = o.value;
|
2017-07-20 08:01:46 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/** Get the io_service associated with the stream.
|
|
|
|
|
|
|
|
This function may be used to obtain the io_service object
|
|
|
|
that the stream uses to dispatch handlers for asynchronous
|
|
|
|
operations.
|
|
|
|
|
|
|
|
@return A reference to the io_service object that the stream
|
|
|
|
will use to dispatch handlers. Ownership is not transferred
|
|
|
|
to the caller.
|
|
|
|
*/
|
|
|
|
boost::asio::io_service&
|
|
|
|
get_io_service()
|
|
|
|
{
|
2016-04-30 13:00:33 -04:00
|
|
|
return stream_.get_io_service();
|
2017-07-20 08:01:46 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/** Get a reference to the next layer.
|
|
|
|
|
|
|
|
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
|
|
|
|
stream layers. Ownership is not transferred to the caller.
|
|
|
|
*/
|
|
|
|
next_layer_type&
|
|
|
|
next_layer()
|
|
|
|
{
|
2016-04-30 13:00:33 -04:00
|
|
|
return stream_.next_layer();
|
2017-07-20 08:01:46 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/** Get a reference to the next layer.
|
|
|
|
|
|
|
|
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
|
|
|
|
stream layers. Ownership is not transferred to the caller.
|
|
|
|
*/
|
|
|
|
next_layer_type const&
|
|
|
|
next_layer() const
|
|
|
|
{
|
2016-04-30 13:00:33 -04:00
|
|
|
return stream_.next_layer();
|
2017-07-20 08:01:46 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/** Get a reference to the lowest layer.
|
|
|
|
|
|
|
|
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&
|
|
|
|
lowest_layer()
|
|
|
|
{
|
2016-04-30 13:00:33 -04:00
|
|
|
return stream_.lowest_layer();
|
2017-07-20 08:01:46 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/** Get a reference to the lowest layer.
|
|
|
|
|
|
|
|
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
|
|
|
|
{
|
2016-04-30 13:00:33 -04:00
|
|
|
return stream_.lowest_layer();
|
2017-07-20 08:01:46 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/** 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_;
|
|
|
|
}
|
|
|
|
|
|
|
|
/** Read and respond to a WebSocket HTTP Upgrade request.
|
|
|
|
|
2017-04-25 10:12:43 -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-04-25 10:12:43 -07:00
|
|
|
@li The HTTP request finishes receiving, and the HTTP 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-04-25 10:12:43 -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.
|
|
|
|
When this call returns, the stream is then ready to send and
|
|
|
|
receive WebSocket protocol frames and messages.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
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
|
2016-05-01 12:33:35 -04:00
|
|
|
(typically 400, "Bad Request"). This counts as a failure.
|
2017-07-20 08:01:46 -07: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
|
|
|
accept();
|
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
|
|
|
/** Read and respond to a WebSocket HTTP Upgrade request.
|
|
|
|
|
|
|
|
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 HTTP request finishes receiving, and the HTTP response
|
|
|
|
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 `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.
|
|
|
|
|
|
|
|
@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.
|
|
|
|
*/
|
|
|
|
template<class ResponseDecorator>
|
|
|
|
void
|
|
|
|
accept_ex(ResponseDecorator const& decorator);
|
|
|
|
|
2017-07-20 08:01:46 -07:00
|
|
|
/** Read and respond to a WebSocket HTTP Upgrade request.
|
|
|
|
|
2017-04-25 10:12:43 -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-04-25 10:12:43 -07:00
|
|
|
@li The HTTP request finishes receiving, and the HTTP 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-04-25 10:12:43 -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.
|
|
|
|
When this call returns, the stream is then ready to send and
|
|
|
|
receive WebSocket protocol frames and messages.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
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
|
2016-05-01 12:33:35 -04:00
|
|
|
(typically 400, "Bad Request"). This counts as a failure.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
@param ec Set to indicate what error occurred, if any.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
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
|
|
|
/** Read and respond to a WebSocket HTTP Upgrade request.
|
|
|
|
|
|
|
|
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 HTTP request finishes receiving, and the HTTP response
|
|
|
|
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 `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.
|
|
|
|
|
|
|
|
@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.
|
|
|
|
*/
|
|
|
|
template<class ResponseDecorator>
|
|
|
|
void
|
|
|
|
accept_ex(ResponseDecorator const& decorator,
|
|
|
|
error_code& ec);
|
|
|
|
|
2017-04-25 10:12:43 -07:00
|
|
|
/** Read and respond to a WebSocket HTTP Upgrade request.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-04-25 10:12:43 -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-04-25 10:12:43 -07:00
|
|
|
@li The HTTP request finishes receiving, and the HTTP 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-04-25 10:12:43 -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-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.
|
|
|
|
When this call returns, the stream is then ready to send and
|
|
|
|
receive WebSocket protocol frames and messages.
|
2016-05-01 12:33:35 -04:00
|
|
|
|
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
|
2016-05-01 12:33:35 -04: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 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.
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
2017-04-25 10:12:43 -07:00
|
|
|
template<class ConstBufferSequence>
|
|
|
|
void
|
|
|
|
accept(ConstBufferSequence const& buffers);
|
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
|
|
|
/** Read and respond to a WebSocket HTTP Upgrade request.
|
|
|
|
|
|
|
|
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 HTTP request finishes receiving, and the HTTP response
|
|
|
|
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 `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.
|
|
|
|
|
|
|
|
@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.
|
|
|
|
|
|
|
|
@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.
|
|
|
|
*/
|
|
|
|
template<class ConstBufferSequence,
|
|
|
|
class ResponseDecorator>
|
|
|
|
void
|
|
|
|
accept_ex(ConstBufferSequence const& buffers,
|
|
|
|
ResponseDecorator const& decorator);
|
|
|
|
|
2017-07-20 08:01:46 -07:00
|
|
|
/** Read and respond to a WebSocket HTTP Upgrade request.
|
|
|
|
|
2017-04-25 10:12:43 -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-04-25 10:12:43 -07:00
|
|
|
@li The HTTP request finishes receiving, and the HTTP 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-04-25 10:12:43 -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.
|
|
|
|
When this call returns, the stream is then ready to send and
|
|
|
|
receive WebSocket protocol frames and messages.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
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
|
2016-05-01 12:33:35 -04:00
|
|
|
(typically 400, "Bad Request"). This counts as a failure.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
@param buffers Caller provided data that has already been
|
2017-04-25 10:12:43 -07:00
|
|
|
received on the stream. The implementation will copy the
|
|
|
|
caller provided data before the function returns.
|
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-20 08:01:46 -07:00
|
|
|
*/
|
|
|
|
template<class ConstBufferSequence>
|
|
|
|
void
|
2017-04-25 10:12:43 -07:00
|
|
|
accept(ConstBufferSequence const& buffers, 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
|
|
|
/** Read and respond to a WebSocket HTTP Upgrade request.
|
|
|
|
|
|
|
|
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 HTTP request finishes receiving, and the HTTP response
|
|
|
|
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 `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.
|
|
|
|
|
|
|
|
@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.
|
|
|
|
|
|
|
|
@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.
|
|
|
|
*/
|
|
|
|
template<class ConstBufferSequence,
|
|
|
|
class ResponseDecorator>
|
|
|
|
void
|
|
|
|
accept_ex(ConstBufferSequence const& buffers,
|
|
|
|
ResponseDecorator const& decorator,
|
|
|
|
error_code& ec);
|
|
|
|
|
2017-04-25 10:12:43 -07:00
|
|
|
/** Respond to a WebSocket HTTP Upgrade request
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-04-25 10:12:43 -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-04-25 10:12:43 -07:00
|
|
|
@li The HTTP 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-04-25 10:12:43 -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.
|
|
|
|
When this call returns, the stream is then ready to send and
|
|
|
|
receive WebSocket protocol frames and messages.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
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
|
2016-05-01 12:33:35 -04: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.
|
|
|
|
Ownership is not transferred, the implementation will not
|
|
|
|
access this object from other threads.
|
|
|
|
|
|
|
|
@throws system_error Thrown on failure.
|
|
|
|
*/
|
|
|
|
template<class Fields>
|
|
|
|
void
|
|
|
|
accept(http::header<true, Fields> const& req);
|
|
|
|
|
|
|
|
/** Respond to a WebSocket HTTP Upgrade request
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
@li The HTTP response 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 `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.
|
|
|
|
|
|
|
|
@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
|
|
|
|
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-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 Fields, class ResponseDecorator>
|
2017-07-20 08:01:46 -07:00
|
|
|
void
|
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
|
|
|
accept_ex(http::header<true, Fields> const& req,
|
|
|
|
ResponseDecorator const& decorator);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-04-25 10:12:43 -07:00
|
|
|
/** Respond to a WebSocket HTTP Upgrade request
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-04-25 10:12:43 -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:
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-04-25 10:12:43 -07:00
|
|
|
@li The HTTP 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-04-25 10:12:43 -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-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.
|
|
|
|
When this call returns, the stream is then ready to send and
|
|
|
|
receive WebSocket protocol frames and messages.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
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
|
2016-05-01 12:33:35 -04: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.
|
|
|
|
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 ec Set to indicate what error occurred, if any.
|
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
|
|
|
template<class Fields>
|
2017-04-25 10:12:43 -07:00
|
|
|
void
|
|
|
|
accept(http::header<true, Fields> 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
|
|
|
error_code& ec);
|
2017-04-25 10:12:43 -07:00
|
|
|
|
|
|
|
/** Respond to a WebSocket HTTP Upgrade request
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
@li The HTTP response 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 `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.
|
|
|
|
|
|
|
|
@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
|
|
|
@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-04-25 10:12:43 -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
|
|
|
template<class Fields, class ResponseDecorator>
|
2017-04-25 10:12:43 -07:00
|
|
|
void
|
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
|
|
|
accept_ex(http::header<true, Fields> const& req,
|
|
|
|
ResponseDecorator const& decorator,
|
|
|
|
error_code& ec);
|
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
|
|
|
/** Respond to a WebSocket HTTP Upgrade request
|
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
|
|
|
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-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
|
|
|
@li The HTTP 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-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-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 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.
|
|
|
|
|
|
|
|
@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
|
|
|
template<class Fields, class ConstBufferSequence>
|
|
|
|
void
|
|
|
|
accept(http::header<true, Fields> const& req,
|
|
|
|
ConstBufferSequence const& buffers);
|
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
|
|
|
/** Respond to a WebSocket HTTP Upgrade request
|
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 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
|
|
|
|
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 The HTTP 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-07-20 08:01:46 -07:00
|
|
|
|
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.
|
|
|
|
|
|
|
|
@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 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.
|
|
|
|
*/
|
|
|
|
template<class Fields, class ConstBufferSequence,
|
|
|
|
class ResponseDecorator>
|
|
|
|
void
|
|
|
|
accept_ex(http::header<true, Fields> const& req,
|
|
|
|
ConstBufferSequence const& buffers,
|
|
|
|
ResponseDecorator const& decorator);
|
|
|
|
|
|
|
|
/** Respond to a WebSocket HTTP Upgrade request
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
@li The HTTP response 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 `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.
|
|
|
|
|
|
|
|
@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.
|
|
|
|
*/
|
|
|
|
template<class Fields, class ConstBufferSequence>
|
|
|
|
void
|
|
|
|
accept(http::header<true, Fields> const& req,
|
|
|
|
ConstBufferSequence const& buffers, error_code& ec);
|
|
|
|
|
|
|
|
/** Respond to a WebSocket HTTP Upgrade request
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
@li The HTTP response 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 `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.
|
|
|
|
|
|
|
|
@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 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.
|
|
|
|
*/
|
|
|
|
template<class Fields, class ConstBufferSequence,
|
|
|
|
class ResponseDecorator>
|
|
|
|
void
|
|
|
|
accept_ex(http::header<true, Fields> const& req,
|
|
|
|
ConstBufferSequence const& buffers,
|
|
|
|
ResponseDecorator const& decorator,
|
|
|
|
error_code& ec);
|
|
|
|
|
|
|
|
/** Start reading and responding to a WebSocket HTTP Upgrade request.
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
@li The HTTP request finishes receiving, and the HTTP response
|
|
|
|
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_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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
@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`.
|
|
|
|
*/
|
|
|
|
template<class AcceptHandler>
|
|
|
|
#if BEAST_DOXYGEN
|
|
|
|
void_or_deduced
|
|
|
|
#else
|
|
|
|
typename async_completion<
|
|
|
|
AcceptHandler, void(error_code)>::result_type
|
|
|
|
#endif
|
|
|
|
async_accept(AcceptHandler&& handler);
|
|
|
|
|
|
|
|
/** Start reading and responding to a WebSocket HTTP Upgrade request.
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
@li The HTTP request finishes receiving, and the HTTP response
|
|
|
|
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_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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
@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 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`.
|
|
|
|
*/
|
|
|
|
template<class ResponseDecorator, class AcceptHandler>
|
|
|
|
#if BEAST_DOXYGEN
|
|
|
|
void_or_deduced
|
|
|
|
#else
|
|
|
|
typename async_completion<
|
|
|
|
AcceptHandler, void(error_code)>::result_type
|
|
|
|
#endif
|
|
|
|
async_accept_ex(ResponseDecorator const& decorator,
|
|
|
|
AcceptHandler&& handler);
|
|
|
|
|
|
|
|
/** Start reading and responding to a WebSocket HTTP Upgrade request.
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
@li The HTTP request finishes receiving, and the HTTP response
|
|
|
|
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_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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
@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.
|
|
|
|
|
|
|
|
@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`.
|
|
|
|
*/
|
|
|
|
template<class ConstBufferSequence, class AcceptHandler>
|
|
|
|
#if BEAST_DOXYGEN
|
|
|
|
void_or_deduced
|
|
|
|
#else
|
|
|
|
typename async_completion<AcceptHandler,
|
|
|
|
void(error_code)>::result_type
|
|
|
|
#endif
|
|
|
|
async_accept(ConstBufferSequence const& buffers,
|
|
|
|
AcceptHandler&& handler);
|
|
|
|
|
|
|
|
/** Start reading and responding to a WebSocket HTTP Upgrade request.
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
@li The HTTP request finishes receiving, and the HTTP response
|
|
|
|
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_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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
@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.
|
|
|
|
|
|
|
|
@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 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`.
|
|
|
|
*/
|
|
|
|
template<class ConstBufferSequence,
|
|
|
|
class ResponseDecorator, class AcceptHandler>
|
|
|
|
#if BEAST_DOXYGEN
|
|
|
|
void_or_deduced
|
|
|
|
#else
|
|
|
|
typename async_completion<AcceptHandler,
|
|
|
|
void(error_code)>::result_type
|
|
|
|
#endif
|
|
|
|
async_accept_ex(ConstBufferSequence const& buffers,
|
|
|
|
ResponseDecorator const& decorator,
|
|
|
|
AcceptHandler&& handler);
|
|
|
|
|
|
|
|
/** Start responding to a WebSocket HTTP Upgrade request.
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
@li The HTTP response 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
|
|
|
|
stream performs no other operations until this operation
|
|
|
|
completes.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
@param req An object containing the HTTP Upgrade request.
|
|
|
|
Ownership is not transferred, the implementation will not access
|
|
|
|
this object from other threads.
|
|
|
|
|
|
|
|
@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`.
|
|
|
|
*/
|
|
|
|
template<class Fields, class AcceptHandler>
|
|
|
|
#if BEAST_DOXYGEN
|
|
|
|
void_or_deduced
|
|
|
|
#else
|
|
|
|
typename async_completion<AcceptHandler,
|
|
|
|
void(error_code)>::result_type
|
|
|
|
#endif
|
|
|
|
async_accept(http::header<true, Fields> const& req,
|
|
|
|
AcceptHandler&& handler);
|
|
|
|
|
|
|
|
/** Start responding to a WebSocket HTTP Upgrade request.
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
@li The HTTP response 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
|
|
|
|
stream performs no other operations until this operation
|
|
|
|
completes.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
@param req An object containing the HTTP Upgrade request.
|
|
|
|
Ownership is not transferred, the implementation will not access
|
|
|
|
this object from other threads.
|
|
|
|
|
|
|
|
@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 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`.
|
|
|
|
*/
|
|
|
|
template<class Fields,
|
|
|
|
class ResponseDecorator, class AcceptHandler>
|
|
|
|
#if BEAST_DOXYGEN
|
|
|
|
void_or_deduced
|
|
|
|
#else
|
|
|
|
typename async_completion<AcceptHandler,
|
|
|
|
void(error_code)>::result_type
|
|
|
|
#endif
|
|
|
|
async_accept_ex(http::header<true, Fields> const& req,
|
|
|
|
ResponseDecorator const& decorator,
|
|
|
|
AcceptHandler&& handler);
|
|
|
|
|
|
|
|
/** Start responding to a WebSocket HTTP Upgrade request.
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
@li The HTTP response 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
|
|
|
|
stream performs no other operations until this operation
|
|
|
|
completes.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
@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-04-25 10:12:43 -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-04-25 10:12:43 -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(
|
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-04-25 10:12:43 -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-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 Fields,
|
|
|
|
class ConstBufferSequence, class AcceptHandler>
|
2017-04-25 10:12:43 -07:00
|
|
|
#if BEAST_DOXYGEN
|
|
|
|
void_or_deduced
|
|
|
|
#else
|
|
|
|
typename async_completion<AcceptHandler,
|
|
|
|
void(error_code)>::result_type
|
|
|
|
#endif
|
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
|
|
|
async_accept(http::header<true, Fields> const& req,
|
|
|
|
ConstBufferSequence const& buffers,
|
|
|
|
AcceptHandler&& handler);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-04-25 10:12:43 -07:00
|
|
|
/** Start responding to a WebSocket HTTP Upgrade request.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-04-25 10:12:43 -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:
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-04-25 10:12:43 -07:00
|
|
|
@li The HTTP 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-04-25 10:12:43 -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
|
|
|
|
completes.
|
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.
|
|
|
|
When the completion handler is invoked, the stream is then
|
|
|
|
ready to send and receive WebSocket protocol frames and
|
|
|
|
messages.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
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
|
|
|
|
(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-04-25 10:12:43 -07:00
|
|
|
@param req An object containing the HTTP Upgrade request.
|
2016-05-01 12:33:35 -04:00
|
|
|
Ownership is not transferred, the implementation will not access
|
|
|
|
this object from other threads.
|
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 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.
|
|
|
|
|
|
|
|
@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-04-25 10:12:43 -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(
|
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-04-25 10:12:43 -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-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 Fields, class ConstBufferSequence,
|
|
|
|
class ResponseDecorator, class AcceptHandler>
|
2017-04-25 10:12:43 -07:00
|
|
|
#if BEAST_DOXYGEN
|
|
|
|
void_or_deduced
|
|
|
|
#else
|
|
|
|
typename async_completion<AcceptHandler,
|
|
|
|
void(error_code)>::result_type
|
|
|
|
#endif
|
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
|
|
|
async_accept_ex(http::header<true, Fields> const& req,
|
|
|
|
ConstBufferSequence const& buffers,
|
|
|
|
ResponseDecorator const& decorator,
|
|
|
|
AcceptHandler&& handler);
|
|
|
|
|
|
|
|
/** Send an HTTP WebSocket Upgrade request and receive the response.
|
|
|
|
|
|
|
|
This function is used to synchronously send the WebSocket
|
|
|
|
upgrade HTTP request. The call blocks until one of the
|
|
|
|
following conditions is true:
|
|
|
|
|
|
|
|
@li A HTTP request finishes sending and an HTTP response finishes
|
|
|
|
receiving.
|
|
|
|
|
|
|
|
@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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
@param resource The requesting URI, which may not be empty,
|
|
|
|
required by the HTTP protocol.
|
|
|
|
|
|
|
|
@throws system_error Thrown on failure.
|
|
|
|
|
|
|
|
@par Example
|
|
|
|
@code
|
|
|
|
websocket::stream<ip::tcp::socket> ws{io_service};
|
|
|
|
...
|
|
|
|
try
|
|
|
|
{
|
|
|
|
ws.handshake("localhost", "/");
|
|
|
|
}
|
|
|
|
catch(...)
|
|
|
|
{
|
|
|
|
// An error occurred.
|
|
|
|
}
|
|
|
|
@endcode
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
handshake(boost::string_ref const& host,
|
|
|
|
boost::string_ref const& resource);
|
|
|
|
|
|
|
|
/** Send an HTTP WebSocket Upgrade request and receive the response.
|
|
|
|
|
|
|
|
This function is used to synchronously send the WebSocket
|
|
|
|
upgrade HTTP request. The call blocks until one of the
|
|
|
|
following conditions is true:
|
|
|
|
|
|
|
|
@li A HTTP request finishes sending and an HTTP response finishes
|
|
|
|
receiving.
|
|
|
|
|
|
|
|
@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.
|
|
|
|
|
|
|
|
The operation is successful if the received HTTP response indicates
|
|
|
|
a successful HTTP Upgrade (represented by a Status-Code of 101,
|
|
|
|
"switching protocols").
|
|
|
|
|
|
|
|
@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 resource The requesting URI, which may not be empty,
|
|
|
|
required by the HTTP protocol.
|
|
|
|
|
|
|
|
@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", "/");
|
|
|
|
}
|
|
|
|
catch(...)
|
|
|
|
{
|
|
|
|
// An error occurred.
|
|
|
|
}
|
|
|
|
@endcode
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
handshake(response_type& res,
|
|
|
|
boost::string_ref const& host,
|
|
|
|
boost::string_ref const& resource);
|
|
|
|
|
|
|
|
/** Send an HTTP WebSocket Upgrade request and receive the response.
|
|
|
|
|
|
|
|
This function is used to synchronously send the WebSocket
|
|
|
|
upgrade HTTP request. The call blocks until one of the
|
|
|
|
following conditions is true:
|
|
|
|
|
|
|
|
@li A HTTP request finishes sending and an HTTP response finishes
|
|
|
|
receiving.
|
|
|
|
|
|
|
|
@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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
@param resource The requesting URI, 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.fields.insert("User-Agent", "Beast");
|
|
|
|
});
|
|
|
|
}
|
|
|
|
catch(...)
|
|
|
|
{
|
|
|
|
// An error occurred.
|
|
|
|
}
|
|
|
|
@endcode
|
|
|
|
*/
|
|
|
|
template<class RequestDecorator>
|
|
|
|
void
|
|
|
|
handshake_ex(boost::string_ref const& host,
|
|
|
|
boost::string_ref const& resource,
|
|
|
|
RequestDecorator const& decorator);
|
|
|
|
|
|
|
|
/** Send an HTTP WebSocket Upgrade request and receive the response.
|
|
|
|
|
|
|
|
This function is used to synchronously send the WebSocket
|
|
|
|
upgrade HTTP request. The call blocks until one of the
|
|
|
|
following conditions is true:
|
|
|
|
|
|
|
|
@li A HTTP request finishes sending and an HTTP response finishes
|
|
|
|
receiving.
|
|
|
|
|
|
|
|
@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.
|
|
|
|
|
|
|
|
The operation is successful if the received HTTP response indicates
|
|
|
|
a successful HTTP Upgrade (represented by a Status-Code of 101,
|
|
|
|
"switching protocols").
|
|
|
|
|
|
|
|
@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 resource The requesting URI, 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
|
|
|
|
{
|
|
|
|
response_type res;
|
|
|
|
ws.handshake(res, "localhost", "/",
|
|
|
|
[](request_type& req)
|
|
|
|
{
|
|
|
|
req.fields.insert("User-Agent", "Beast");
|
|
|
|
});
|
|
|
|
}
|
|
|
|
catch(...)
|
|
|
|
{
|
|
|
|
// An error occurred.
|
|
|
|
}
|
|
|
|
@endcode
|
|
|
|
*/
|
|
|
|
template<class RequestDecorator>
|
|
|
|
void
|
|
|
|
handshake_ex(response_type& res,
|
|
|
|
boost::string_ref const& host,
|
|
|
|
boost::string_ref const& resource,
|
|
|
|
RequestDecorator const& decorator);
|
|
|
|
|
|
|
|
/** Send an HTTP WebSocket Upgrade request and receive the response.
|
|
|
|
|
|
|
|
This function is used to synchronously send the WebSocket
|
|
|
|
upgrade HTTP request. The call blocks until one of the
|
|
|
|
following conditions is true:
|
|
|
|
|
|
|
|
@li A HTTP request finishes sending and an HTTP response finishes
|
|
|
|
receiving.
|
|
|
|
|
|
|
|
@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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
@param resource The requesting URI, which may not be empty,
|
|
|
|
required by the HTTP protocol.
|
|
|
|
|
|
|
|
@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, resource, ec);
|
|
|
|
if(ec)
|
|
|
|
{
|
|
|
|
// An error occurred.
|
|
|
|
}
|
|
|
|
@endcode
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
handshake(boost::string_ref const& host,
|
|
|
|
boost::string_ref const& resource, error_code& ec);
|
|
|
|
|
|
|
|
/** Send an HTTP WebSocket Upgrade request and receive the response.
|
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 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
|
|
|
|
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 A HTTP request finishes sending and an HTTP response finishes
|
|
|
|
receiving.
|
2016-05-01 12:33:35 -04: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
|
|
|
@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.
|
2016-05-01 12:33:35 -04: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
|
|
|
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
|
|
|
|
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 host The name of the remote host,
|
|
|
|
required by the HTTP protocol.
|
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 resource The requesting URI, which may not be empty,
|
|
|
|
required by the HTTP protocol.
|
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 ec Set to indicate what error occurred, if any.
|
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 res The HTTP Upgrade response returned by the remote
|
|
|
|
endpoint. If `ec is set, the return value is undefined.
|
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
|
|
|
@par Example
|
|
|
|
@code
|
|
|
|
websocket::stream<ip::tcp::socket> ws{io_service};
|
|
|
|
...
|
|
|
|
error_code ec;
|
|
|
|
response_type res;
|
|
|
|
ws.handshake(res, host, resource, ec);
|
|
|
|
if(ec)
|
|
|
|
{
|
|
|
|
// An error occurred.
|
|
|
|
}
|
|
|
|
@endcode
|
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
|
|
|
|
handshake(response_type& res,
|
|
|
|
boost::string_ref const& host,
|
|
|
|
boost::string_ref const& resource,
|
|
|
|
error_code& ec);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-04-25 10:12:43 -07:00
|
|
|
/** Send an HTTP WebSocket Upgrade request and receive the response.
|
2017-07-20 08:01:46 -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-04-25 10:12:43 -07:00
|
|
|
@li A HTTP request finishes sending and an HTTP response finishes
|
2016-05-01 12:33:35 -04:00
|
|
|
receiving.
|
|
|
|
|
2017-07-20 08:01:46 -07:00
|
|
|
@li An error occurs on the stream
|
|
|
|
|
2016-05-01 12:33:35 -04: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
|
|
|
|
2016-05-01 12:33:35 -04: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
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
@param host The name of the remote host,
|
|
|
|
required by the HTTP protocol.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
@param resource The requesting URI, 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
|
|
|
|
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 ec Set to indicate what error occurred, if any.
|
2016-05-01 12:33:35 -04:00
|
|
|
|
2017-07-20 08:01:46 -07:00
|
|
|
@par Example
|
|
|
|
@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
|
|
|
...
|
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 ec;
|
|
|
|
ws.handshake("localhost", "/",
|
|
|
|
[](request_type& req)
|
|
|
|
{
|
|
|
|
req.fields.insert("User-Agent", "Beast");
|
|
|
|
},
|
|
|
|
ec);
|
|
|
|
if(ec)
|
2017-07-20 08:01:46 -07:00
|
|
|
{
|
|
|
|
// 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
|
|
|
template<class RequestDecorator>
|
2017-07-20 08:01:46 -07:00
|
|
|
void
|
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
|
|
|
handshake_ex(boost::string_ref const& host,
|
|
|
|
boost::string_ref const& resource,
|
|
|
|
RequestDecorator const& decorator,
|
|
|
|
error_code& ec);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-04-25 10:12:43 -07:00
|
|
|
/** Send an HTTP WebSocket Upgrade request and receive the response.
|
2017-07-20 08:01:46 -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-04-25 10:12:43 -07:00
|
|
|
@li A HTTP request finishes sending and an HTTP response finishes
|
2016-05-01 12:33:35 -04:00
|
|
|
receiving.
|
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
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
This function is implemented in terms of one or more calls to the
|
|
|
|
next layer's `read_some` and `write_some` functions.
|
|
|
|
|
|
|
|
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
|
|
|
@param res The HTTP Upgrade response returned by the remote
|
|
|
|
endpoint.
|
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
@param host The name of the remote host,
|
|
|
|
required by the HTTP protocol.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
@param resource The requesting URI, 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
|
|
|
|
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
|
|
|
@param ec Set to indicate what error occurred, if any.
|
|
|
|
|
|
|
|
@par Example
|
|
|
|
@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
|
|
|
...
|
|
|
|
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
|
|
|
response_type res;
|
|
|
|
ws.handshake(res, "localhost", "/",
|
|
|
|
[](request_type& req)
|
|
|
|
{
|
|
|
|
req.fields.insert("User-Agent", "Beast");
|
|
|
|
},
|
|
|
|
ec);
|
2017-07-20 08:01:46 -07:00
|
|
|
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
|
|
|
template<class RequestDecorator>
|
2017-07-20 08:01:46 -07:00
|
|
|
void
|
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
|
|
|
handshake_ex(response_type& res,
|
|
|
|
boost::string_ref const& host,
|
|
|
|
boost::string_ref const& resource,
|
|
|
|
RequestDecorator const& decorator,
|
|
|
|
error_code& ec);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
/** Start an asynchronous operation to send an upgrade request and receive the response.
|
|
|
|
|
|
|
|
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
|
|
|
@li A HTTP request finishes sending and an HTTP response finishes
|
2016-05-01 12:33:35 -04:00
|
|
|
receiving.
|
|
|
|
|
|
|
|
@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 ensure
|
|
|
|
that the stream performs no other operations until this operation
|
|
|
|
completes.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-01 12:33:35 -04: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
|
|
|
|
|
|
|
@param host The name of the remote host, required by
|
|
|
|
the HTTP protocol. Copies may be made as needed.
|
|
|
|
|
|
|
|
@param resource The requesting URI, which may not be empty,
|
|
|
|
required by the HTTP protocol. Copies 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
|
|
|
@param handler The handler to be called when the request completes.
|
2017-07-20 08:01:46 -07:00
|
|
|
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
|
|
|
|
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 HandshakeHandler>
|
2017-04-22 14:56:09 -07:00
|
|
|
#if BEAST_DOXYGEN
|
2016-05-01 12:33:35 -04:00
|
|
|
void_or_deduced
|
2016-05-27 11:17:53 -04:00
|
|
|
#else
|
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
|
|
|
typename async_completion<HandshakeHandler,
|
|
|
|
void(error_code)>::result_type
|
2016-05-27 11:17:53 -04:00
|
|
|
#endif
|
2017-07-20 08:01:46 -07:00
|
|
|
async_handshake(boost::string_ref const& host,
|
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
|
|
|
boost::string_ref const& resource,
|
|
|
|
HandshakeHandler&& handler);
|
|
|
|
|
|
|
|
/** Start an asynchronous operation to send an upgrade request and receive the response.
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
@li A HTTP request finishes sending and an HTTP response finishes
|
|
|
|
receiving.
|
|
|
|
|
|
|
|
@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 ensure
|
|
|
|
that the stream performs no other operations until this operation
|
|
|
|
completes.
|
|
|
|
|
|
|
|
The operation is successful if the received HTTP response indicates
|
|
|
|
a successful HTTP Upgrade (represented by a Status-Code of 101,
|
|
|
|
"switching protocols").
|
|
|
|
|
|
|
|
@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.
|
|
|
|
|
|
|
|
@param host The name of the remote host, required by
|
|
|
|
the HTTP protocol. Copies may be made as needed.
|
|
|
|
|
|
|
|
@param resource The requesting URI, which may not be empty,
|
|
|
|
required by the HTTP protocol. Copies 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`.
|
|
|
|
*/
|
|
|
|
template<class HandshakeHandler>
|
|
|
|
#if BEAST_DOXYGEN
|
|
|
|
void_or_deduced
|
|
|
|
#else
|
|
|
|
typename async_completion<HandshakeHandler,
|
|
|
|
void(error_code)>::result_type
|
|
|
|
#endif
|
|
|
|
async_handshake(response_type& res,
|
|
|
|
boost::string_ref const& host,
|
|
|
|
boost::string_ref const& resource,
|
|
|
|
HandshakeHandler&& handler);
|
|
|
|
|
|
|
|
/** Start an asynchronous operation to send an upgrade request and receive the response.
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
@li A HTTP request finishes sending and an HTTP response finishes
|
|
|
|
receiving.
|
|
|
|
|
|
|
|
@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 ensure
|
|
|
|
that the stream performs no other operations until this operation
|
|
|
|
completes.
|
|
|
|
|
|
|
|
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 resource The requesting URI, which may not be empty,
|
|
|
|
required by the HTTP protocol. Copies may be made as
|
|
|
|
needed.
|
|
|
|
|
|
|
|
@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`.
|
|
|
|
*/
|
|
|
|
template<class RequestDecorator, class HandshakeHandler>
|
|
|
|
#if BEAST_DOXYGEN
|
|
|
|
void_or_deduced
|
|
|
|
#else
|
|
|
|
typename async_completion<HandshakeHandler,
|
|
|
|
void(error_code)>::result_type
|
|
|
|
#endif
|
|
|
|
async_handshake_ex(boost::string_ref const& host,
|
|
|
|
boost::string_ref const& resource,
|
|
|
|
RequestDecorator const& decorator,
|
|
|
|
HandshakeHandler&& handler);
|
|
|
|
|
|
|
|
/** Start an asynchronous operation to send an upgrade request and receive the response.
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
@li A HTTP request finishes sending and an HTTP response finishes
|
|
|
|
receiving.
|
|
|
|
|
|
|
|
@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 ensure
|
|
|
|
that the stream performs no other operations until this operation
|
|
|
|
completes.
|
|
|
|
|
|
|
|
The operation is successful if the received HTTP response indicates
|
|
|
|
a successful HTTP Upgrade (represented by a Status-Code of 101,
|
|
|
|
"switching protocols").
|
|
|
|
|
|
|
|
@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.
|
|
|
|
|
|
|
|
@param host The name of the remote host, required by
|
|
|
|
the HTTP protocol. Copies may be made as needed.
|
|
|
|
|
|
|
|
@param resource The requesting URI, which may not be empty,
|
|
|
|
required by the HTTP protocol. Copies may be made as
|
|
|
|
needed.
|
|
|
|
|
|
|
|
@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`.
|
|
|
|
*/
|
|
|
|
template<class RequestDecorator, class HandshakeHandler>
|
|
|
|
#if BEAST_DOXYGEN
|
|
|
|
void_or_deduced
|
|
|
|
#else
|
|
|
|
typename async_completion<HandshakeHandler,
|
|
|
|
void(error_code)>::result_type
|
|
|
|
#endif
|
|
|
|
async_handshake_ex(response_type& res,
|
|
|
|
boost::string_ref const& host,
|
|
|
|
boost::string_ref const& resource,
|
|
|
|
RequestDecorator const& decorator,
|
|
|
|
HandshakeHandler&& handler);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
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,
|
2016-05-01 12:33:35 -04:00
|
|
|
@ref stream::async_write, @ref stream::async_write_frame, or
|
|
|
|
@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-04-22 14:56:09 -07:00
|
|
|
#if BEAST_DOXYGEN
|
2016-05-01 12:33:35 -04:00
|
|
|
void_or_deduced
|
2016-05-27 11:17:53 -04:00
|
|
|
#else
|
2017-07-20 08:01:46 -07:00
|
|
|
typename async_completion<
|
|
|
|
CloseHandler, void(error_code)>::result_type
|
2016-05-27 11:17:53 -04: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-04-22 14:56:09 -07:00
|
|
|
#if BEAST_DOXYGEN
|
2016-05-15 16:22:25 -04:00
|
|
|
void_or_deduced
|
2016-05-27 11:17:53 -04:00
|
|
|
#else
|
2016-05-15 16:22:25 -04:00
|
|
|
typename async_completion<
|
2016-11-03 17:53:32 -04:00
|
|
|
WriteHandler, void(error_code)>::result_type
|
2016-05-27 11:17:53 -04: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-04-22 14:56:09 -07:00
|
|
|
#if BEAST_DOXYGEN
|
2016-11-03 17:53:32 -04:00
|
|
|
void_or_deduced
|
|
|
|
#else
|
|
|
|
typename async_completion<
|
|
|
|
WriteHandler, void(error_code)>::result_type
|
|
|
|
#endif
|
|
|
|
async_pong(ping_data const& payload, WriteHandler&& handler);
|
2016-05-15 16:22:25 -04:00
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
/** Read a message from the stream.
|
|
|
|
|
|
|
|
This function is used to synchronously read a 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
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
|
|
|
This call is implemented in terms of one or more calls to the
|
|
|
|
stream's `read_some` and `write_some` operations.
|
|
|
|
|
|
|
|
Upon a success, op is set to either binary or text depending on
|
|
|
|
the message type, and the input area of the stream buffer will
|
|
|
|
hold all the message payload bytes (which may be zero in length).
|
|
|
|
|
2017-02-07 19:11:24 -05:00
|
|
|
During reads, the implementation handles control frames as
|
|
|
|
follows:
|
|
|
|
|
|
|
|
@li A pong frame is sent when a ping frame is received.
|
|
|
|
|
|
|
|
@li The @ref ping_callback is invoked when a ping frame
|
|
|
|
or pong frame is received.
|
|
|
|
|
|
|
|
@li The WebSocket close procedure is started if a close frame
|
|
|
|
is received. In this case, the operation will eventually
|
|
|
|
complete with the error set to @ref error::closed.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
@param op A value to receive the message type.
|
|
|
|
This object must remain valid until the handler is called.
|
|
|
|
|
2016-05-28 09:23:54 -04:00
|
|
|
@param dynabuf A dynamic buffer to hold the message data after
|
|
|
|
any masking or decompression has been applied.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-10-04 18:00:11 -04:00
|
|
|
@throws system_error Thrown on failure.
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
2016-05-28 09:23:54 -04:00
|
|
|
template<class DynamicBuffer>
|
2017-07-20 08:01:46 -07:00
|
|
|
void
|
2016-05-28 09:23:54 -04:00
|
|
|
read(opcode& op, DynamicBuffer& dynabuf);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
/** Read a message from the stream.
|
|
|
|
|
|
|
|
This function is used to synchronously read a 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
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
|
|
|
This call is implemented in terms of one or more calls to the
|
|
|
|
stream's `read_some` and `write_some` operations.
|
|
|
|
|
|
|
|
Upon a success, op is set to either binary or text depending on
|
|
|
|
the message type, and the input area of the stream buffer will
|
|
|
|
hold all the message payload bytes (which may be zero in length).
|
|
|
|
|
2017-02-07 19:11:24 -05:00
|
|
|
During reads, the implementation handles control frames as
|
|
|
|
follows:
|
|
|
|
|
|
|
|
@li The @ref ping_callback is invoked when a ping frame
|
|
|
|
or pong frame is received.
|
|
|
|
|
|
|
|
@li A pong frame is sent when a ping frame is received.
|
|
|
|
|
|
|
|
@li The WebSocket close procedure is started if a close frame
|
|
|
|
is received. In this case, the operation will eventually
|
|
|
|
complete with the error set to @ref error::closed.
|
2017-02-06 20:07:03 -05:00
|
|
|
|
2017-07-20 08:01:46 -07:00
|
|
|
@param op A value to receive the message type.
|
|
|
|
This object must remain valid until the handler is called.
|
|
|
|
|
2016-05-28 09:23:54 -04:00
|
|
|
@param dynabuf 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-20 08:01:46 -07:00
|
|
|
void
|
2016-05-28 09:23:54 -04:00
|
|
|
read(opcode& op, DynamicBuffer& dynabuf, error_code& ec);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
/** Start an asynchronous operation to read a message from the stream.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-15 16:22:25 -04:00
|
|
|
This function is used to asynchronously read a message from
|
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
|
|
|
|
is true:
|
|
|
|
|
|
|
|
@li A complete message is received.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
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.
|
|
|
|
|
|
|
|
Upon a success, op is set to either binary or text depending on
|
|
|
|
the message type, and the input area of the stream buffer will
|
|
|
|
hold all the message payload bytes (which may be zero in length).
|
|
|
|
|
2017-02-07 19:11:24 -05:00
|
|
|
During reads, the implementation handles control frames as
|
|
|
|
follows:
|
|
|
|
|
|
|
|
@li The @ref ping_callback is invoked when a ping frame
|
|
|
|
or pong frame is received.
|
|
|
|
|
|
|
|
@li A pong frame is sent when a ping frame is received.
|
|
|
|
|
|
|
|
@li The WebSocket close procedure is started if a close frame
|
|
|
|
is received. In this case, the operation will eventually
|
|
|
|
complete with the error set to @ref error::closed.
|
2017-02-06 20:07:03 -05:00
|
|
|
|
2017-02-03 16:22:28 -05:00
|
|
|
Because of the need to handle control frames, read operations
|
|
|
|
can cause writes to take place. These writes are managed
|
|
|
|
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
|
|
|
|
|
|
|
@param op A value to receive the message type.
|
|
|
|
This object must remain valid until the handler is called.
|
|
|
|
|
2016-05-28 09:23:54 -04:00
|
|
|
@param dynabuf 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.
|
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
|
|
|
|
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
|
|
|
*/
|
2016-05-28 09:23:54 -04:00
|
|
|
template<class DynamicBuffer, class ReadHandler>
|
2017-04-22 14:56:09 -07:00
|
|
|
#if BEAST_DOXYGEN
|
2017-07-20 08:01:46 -07:00
|
|
|
void_or_deduced
|
2016-05-27 11:17:53 -04:00
|
|
|
#else
|
2017-07-20 08:01:46 -07:00
|
|
|
typename async_completion<
|
|
|
|
ReadHandler, void(error_code)>::result_type
|
2016-05-27 11:17:53 -04:00
|
|
|
#endif
|
2016-05-28 09:23:54 -04:00
|
|
|
async_read(opcode& op, DynamicBuffer& dynabuf, ReadHandler&& handler);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
/** Read a message frame from the stream.
|
|
|
|
|
|
|
|
This function is used to synchronously read a single message
|
|
|
|
frame from the stream. The call blocks until one of the following
|
|
|
|
is true:
|
|
|
|
|
|
|
|
@li A complete frame is received.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
@li An error occurs on the stream.
|
|
|
|
|
|
|
|
This call is implemented in terms of one or more calls to the
|
|
|
|
stream's `read_some` and `write_some` operations.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-02-07 19:11:24 -05:00
|
|
|
Upon success, `fi` is filled out to reflect the message payload
|
|
|
|
contents. `op` is set to binary or text, and the `fin` flag
|
2017-07-20 08:01:46 -07:00
|
|
|
indicates if all the message data has been read in. To read the
|
2017-02-07 19:11:24 -05:00
|
|
|
entire message, callers should keep calling @ref read_frame
|
|
|
|
until `fi.fin == true`. A message with no payload will have
|
|
|
|
`fi.fin == true`, and zero bytes placed into the stream buffer.
|
|
|
|
|
|
|
|
During reads, the implementation handles control frames as
|
|
|
|
follows:
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-02-07 19:11:24 -05:00
|
|
|
@li The @ref ping_callback is invoked when a ping frame
|
|
|
|
or pong frame is received.
|
|
|
|
|
|
|
|
@li A pong frame is sent when a ping frame is received.
|
|
|
|
|
|
|
|
@li The WebSocket close procedure is started if a close frame
|
|
|
|
is received. In this case, the operation will eventually
|
|
|
|
complete with the error set to @ref error::closed.
|
2017-02-06 20:07:03 -05:00
|
|
|
|
2017-07-20 08:01:46 -07:00
|
|
|
@param fi An object to store metadata about the message.
|
|
|
|
|
2016-05-28 09:23:54 -04:00
|
|
|
@param dynabuf A dynamic buffer to hold the message data after
|
|
|
|
any masking or decompression has been applied.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-10-04 18:00:11 -04:00
|
|
|
@throws system_error Thrown on failure.
|
2017-07-20 08:01:46 -07:00
|
|
|
*/
|
2016-05-28 09:23:54 -04:00
|
|
|
template<class DynamicBuffer>
|
2017-07-20 08:01:46 -07:00
|
|
|
void
|
2016-05-28 09:23:54 -04:00
|
|
|
read_frame(frame_info& fi, DynamicBuffer& dynabuf);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
/** Read a message frame from the stream.
|
|
|
|
|
|
|
|
This function is used to synchronously read a single message
|
|
|
|
frame from the stream. The call blocks until one of the following
|
|
|
|
is true:
|
|
|
|
|
|
|
|
@li A complete frame is received.
|
|
|
|
|
|
|
|
@li An error occurs on the stream.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
This call is implemented in terms of one or more calls to the
|
|
|
|
stream's `read_some` and `write_some` operations.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-02-07 19:11:24 -05:00
|
|
|
Upon success, `fi` is filled out to reflect the message payload
|
|
|
|
contents. `op` is set to binary or text, and the `fin` flag
|
2017-07-20 08:01:46 -07:00
|
|
|
indicates if all the message data has been read in. To read the
|
2017-02-07 19:11:24 -05:00
|
|
|
entire message, callers should keep calling @ref read_frame
|
|
|
|
until `fi.fin == true`. A message with no payload will have
|
|
|
|
`fi.fin == true`, and zero bytes placed into the stream buffer.
|
|
|
|
|
|
|
|
During reads, the implementation handles control frames as
|
|
|
|
follows:
|
|
|
|
|
|
|
|
@li The @ref ping_callback is invoked when a ping frame
|
|
|
|
or pong frame is received.
|
|
|
|
|
|
|
|
@li A pong frame is sent when a ping frame is received.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2017-02-07 19:11:24 -05:00
|
|
|
@li The WebSocket close procedure is started if a close frame
|
|
|
|
is received. In this case, the operation will eventually
|
|
|
|
complete with the error set to @ref error::closed.
|
2017-02-06 20:07:03 -05:00
|
|
|
|
2017-07-20 08:01:46 -07:00
|
|
|
@param fi An object to store metadata about the message.
|
|
|
|
|
2016-05-28 09:23:54 -04:00
|
|
|
@param dynabuf 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-20 08:01:46 -07:00
|
|
|
void
|
2016-05-28 09:23:54 -04:00
|
|
|
read_frame(frame_info& fi, DynamicBuffer& dynabuf, error_code& ec);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
/** Start an asynchronous operation to read a message frame from the stream.
|
2017-07-20 08:01:46 -07:00
|
|
|
|
2016-05-15 16:22:25 -04:00
|
|
|
This function is used to asynchronously read a single message
|
2017-07-20 08:01:46 -07:00
|
|
|
frame from the websocket. The function call always returns
|
2016-05-01 12:33:35 -04:00
|
|
|
immediately. The asynchronous operation will continue until
|
|
|
|
one of the following conditions is true:
|
|
|
|
|
|
|
|
@li A complete frame is received.
|
|
|
|
|
|
|
|
@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-20 08:01:46 -07:00
|
|
|
|
2017-02-07 19:11:24 -05:00
|
|
|
Upon a successful completion, `fi` is filled out to reflect the
|
|
|
|
message payload contents. `op` is set to binary or text, and the
|
|
|
|
`fin` flag indicates if all the message data has been read in.
|
|
|
|
To read the entire message, callers should keep calling
|
|
|
|
@ref read_frame until `fi.fin == true`. A message with no payload
|
|
|
|
will have `fi.fin == true`, and zero bytes placed into the stream
|
|
|
|
buffer.
|
|
|
|
|
|
|
|
During reads, the implementation handles control frames as
|
|
|
|
follows:
|
|
|
|
|
|
|
|
@li The @ref ping_callback is invoked when a ping frame
|
|
|
|
or pong frame is received.
|
|
|
|
|
|
|
|
@li A pong frame is sent when a ping frame is received.
|
|
|
|
|
|
|
|
@li The WebSocket close procedure is started if a close frame
|
|
|
|
is received. In this case, the operation will eventually
|
|
|
|
complete with the error set to @ref error::closed.
|
2017-02-06 20:07:03 -05:00
|
|
|
|
2017-02-03 16:22:28 -05:00
|
|
|
Because of the need to handle control frames, read operations
|
|
|
|
can cause writes to take place. These writes are managed
|
|
|
|
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
|
|
|
|
|
|
|
@param fi An object to store metadata about the message.
|
|
|
|
This object must remain valid until the handler is called.
|
|
|
|
|
2016-05-28 09:23:54 -04:00
|
|
|
@param dynabuf A dynamic buffer to hold the message data after
|
2017-07-20 08:01:46 -07:00
|
|
|
any masking or decompression has been applied. This object must
|
|
|
|
remain valid until the handler is called.
|
|
|
|
|
|
|
|
@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
|
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
|
|
|
|
manner equivalent to using boost::asio::io_service::post().
|
|
|
|
*/
|
2016-05-28 09:23:54 -04:00
|
|
|
template<class DynamicBuffer, class ReadHandler>
|
2017-04-22 14:56:09 -07:00
|
|
|
#if BEAST_DOXYGEN
|
2016-05-01 12:33:35 -04:00
|
|
|
void_or_deduced
|
2016-05-27 11:17:53 -04:00
|
|
|
#else
|
2017-07-20 08:01:46 -07:00
|
|
|
typename async_completion<
|
|
|
|
ReadHandler, void(error_code)>::result_type
|
2016-05-27 11:17:53 -04:00
|
|
|
#endif
|
2017-07-20 08:01:46 -07:00
|
|
|
async_read_frame(frame_info& fi,
|
2016-05-28 09:23:54 -04:00
|
|
|
DynamicBuffer& dynabuf, ReadHandler&& handler);
|
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.
|
|
|
|
|
|
|
|
The current setting of the @ref message_type option controls
|
|
|
|
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
|
2016-05-01 12:33:35 -04:00
|
|
|
send a message in fragments, use @ref write_frame.
|
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
|
|
|
|
2016-05-01 12:33:35 -04:00
|
|
|
The current setting of the @ref message_type option controls
|
|
|
|
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
|
2016-05-01 12:33:35 -04:00
|
|
|
send a message in fragments, use @ref write_frame.
|
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
|
|
|
|
stream::async_write, stream::async_write_frame, or
|
|
|
|
stream::async_close).
|
|
|
|
|
|
|
|
The current setting of the @ref message_type option controls
|
|
|
|
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-04-22 14:56:09 -07:00
|
|
|
#if BEAST_DOXYGEN
|
2017-07-20 08:01:46 -07:00
|
|
|
void_or_deduced
|
2016-05-27 11:17:53 -04:00
|
|
|
#else
|
2017-07-20 08:01:46 -07:00
|
|
|
typename async_completion<
|
|
|
|
WriteHandler, void(error_code)>::result_type
|
2016-05-27 11:17:53 -04: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
|
2016-05-01 12:33:35 -04:00
|
|
|
the @ref message_type 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
|
2016-04-30 13:00:33 -04:00
|
|
|
write_frame(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
|
2016-05-01 12:33:35 -04:00
|
|
|
the @ref message_type 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
|
|
|
|
write_frame(bool fin,
|
|
|
|
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
|
|
|
|
operations (such as stream::async_write, stream::async_write_frame,
|
|
|
|
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
|
|
|
|
the @ref message_type 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-04-22 14:56:09 -07:00
|
|
|
#if BEAST_DOXYGEN
|
2016-05-01 12:33:35 -04:00
|
|
|
void_or_deduced
|
2016-05-27 11:17:53 -04:00
|
|
|
#else
|
2017-07-20 08:01:46 -07:00
|
|
|
typename async_completion<
|
|
|
|
WriteHandler, void(error_code)>::result_type
|
2016-05-27 11:17:53 -04:00
|
|
|
#endif
|
2017-07-20 08:01:46 -07:00
|
|
|
async_write_frame(bool fin,
|
|
|
|
ConstBufferSequence const& buffers, WriteHandler&& handler);
|
|
|
|
|
|
|
|
private:
|
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, class Handler> class accept_op;
|
2017-07-20 08:01:46 -07:00
|
|
|
template<class Handler> class close_op;
|
|
|
|
template<class Handler> class handshake_op;
|
2016-05-15 16:22:25 -04:00
|
|
|
template<class Handler> class ping_op;
|
2017-07-20 08:01:46 -07:00
|
|
|
template<class Handler> class response_op;
|
|
|
|
template<class Buffers, class Handler> class write_op;
|
|
|
|
template<class Buffers, class Handler> class write_frame_op;
|
2016-05-28 09:23:54 -04:00
|
|
|
template<class DynamicBuffer, class Handler> class read_op;
|
|
|
|
template<class DynamicBuffer, class Handler> class read_frame_op;
|
2016-05-15 16:22:25 -04: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
|
|
|
static
|
2016-05-15 16:22:25 -04:00
|
|
|
void
|
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
|
|
|
default_decorate_req(request_type& res)
|
|
|
|
{
|
|
|
|
}
|
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
|
|
|
static
|
2017-04-25 10:12:43 -07:00
|
|
|
void
|
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
|
|
|
default_decorate_res(response_type& res)
|
|
|
|
{
|
|
|
|
}
|
2017-04-25 10:12:43 -07:00
|
|
|
|
|
|
|
void
|
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
|
|
|
reset();
|
|
|
|
|
|
|
|
template<class Decorator>
|
|
|
|
void
|
|
|
|
do_accept(Decorator const& decorator,
|
2017-04-25 10:12:43 -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
|
|
|
template<class Fields, class Decorator>
|
|
|
|
void
|
|
|
|
do_accept(http::header<true, Fields> 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,
|
|
|
|
boost::string_ref const& host,
|
|
|
|
boost::string_ref const& resource,
|
|
|
|
RequestDecorator const& decorator,
|
|
|
|
error_code& ec);
|
|
|
|
|
|
|
|
template<class Decorator>
|
|
|
|
request_type
|
|
|
|
build_request(std::string& key,
|
|
|
|
boost::string_ref const& host,
|
|
|
|
boost::string_ref const& resource,
|
|
|
|
Decorator const& decorator);
|
|
|
|
|
|
|
|
template<class Decorator>
|
|
|
|
response_type
|
|
|
|
build_response(request_type const& req,
|
|
|
|
Decorator const& decorator);
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
void
|
2016-11-20 07:32:41 -05:00
|
|
|
do_response(http::response_header const& resp,
|
2017-07-20 08:01:46 -07:00
|
|
|
boost::string_ref const& key, error_code& ec);
|
|
|
|
};
|
|
|
|
|
|
|
|
} // websocket
|
|
|
|
} // beast
|
|
|
|
|
2016-10-24 08:12:09 -04:00
|
|
|
#include <beast/websocket/impl/accept.ipp>
|
|
|
|
#include <beast/websocket/impl/close.ipp>
|
|
|
|
#include <beast/websocket/impl/handshake.ipp>
|
|
|
|
#include <beast/websocket/impl/ping.ipp>
|
|
|
|
#include <beast/websocket/impl/read.ipp>
|
2017-07-20 08:01:46 -07:00
|
|
|
#include <beast/websocket/impl/stream.ipp>
|
2016-10-24 08:12:09 -04:00
|
|
|
#include <beast/websocket/impl/write.ipp>
|
2017-07-20 08:01:46 -07:00
|
|
|
|
|
|
|
#endif
|