feedc0de/boost_beast
1
0
Fork 0
forked from boostorg/beast
Code Pull Requests Activity
Files
dfd08bf6aeb12e5718156b878e6363c00749ab8d
boost_beast/include/boost/beast/websocket/impl/handshake.hpp

364 lines
11 KiB
C++
Raw Normal View History

Truncate history, version 1.0.0-b2
2017-07-20 08:01:46 -07:00
//
Update copyrights
2017-07-24 09:42:36 -07:00
// Copyright (c) 2016-2017 Vinnie Falco (vinnie dot falco at gmail dot com)
Truncate history, version 1.0.0-b2
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)
//
Boost prep
2017-07-20 13:40:34 -07:00
// Official repository: https://github.com/boostorg/beast
//
Truncate history, version 1.0.0-b2
2017-07-20 08:01:46 -07:00
websocket stream uses shared_ptr<impl_type>
2019-01-19 07:24:00 -08:00
#ifndef BOOST_BEAST_WEBSOCKET_IMPL_HANDSHAKE_HPP
#define BOOST_BEAST_WEBSOCKET_IMPL_HANDSHAKE_HPP
Truncate history, version 1.0.0-b2
2017-07-20 08:01:46 -07:00
Boost prep
2017-07-20 13:40:34 -07:00
#include <boost/beast/websocket/detail/type_traits.hpp>
#include <boost/beast/http/empty_body.hpp>
#include <boost/beast/http/message.hpp>
#include <boost/beast/http/read.hpp>
#include <boost/beast/http/write.hpp>
async_op_base is a public interface: This utility simplifies the authoring of composed operations, see documentation for details.
2019-01-07 13:35:19 -08:00
#include <boost/beast/core/async_op_base.hpp>
Add executor_type trait
2019-02-04 21:52:54 -08:00
#include <boost/beast/core/stream_traits.hpp>
websocket handshake uses coroutine
2017-08-19 19:27:08 -07:00
#include <boost/asio/coroutine.hpp>
Use BOOST_ASSERT
2016-09-25 12:17:32 -04:00
#include <boost/assert.hpp>
Use BOOST_THROW_EXCEPTION fix #370
2017-05-22 15:30:12 -07:00
#include <boost/throw_exception.hpp>
Truncate history, version 1.0.0-b2
2017-07-20 08:01:46 -07:00
#include <memory>
Boost prep
2017-07-20 13:40:34 -07:00
namespace boost {
Truncate history, version 1.0.0-b2
2017-07-20 08:01:46 -07:00
namespace beast {
namespace websocket {
Reorganize source files and definitions
2016-10-24 08:12:09 -04:00
//------------------------------------------------------------------------------
Truncate history, version 1.0.0-b2
2017-07-20 08:01:46 -07:00
// send the upgrade request and process the response
//
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
template<class NextLayer, bool deflateSupported>
Truncate history, version 1.0.0-b2
2017-07-20 08:01:46 -07:00
template<class Handler>
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
class stream<NextLayer, deflateSupported>::handshake_op
async_op_base is a public interface: This utility simplifies the authoring of composed operations, see documentation for details.
2019-01-07 13:35:19 -08:00
: public beast::stable_async_op_base<Handler,
Add executor_type trait
2019-02-04 21:52:54 -08:00
beast::executor_type<stream>>
Use async_op_base: Composed operation implementations use async_op_base and stable_async_op_base, to eliminate redundant boilerplate.
2019-01-05 19:40:46 -08:00
, public net::coroutine
Truncate history, version 1.0.0-b2
2017-07-20 08:01:46 -07:00
{
struct data
{
Refactor websocket::stream operations
2019-01-20 12:25:30 -08:00
// VFALCO This really should be two separate
// composed operations, to save on memory
Documentation work
2017-06-07 16:30:49 -07:00
http::request<http::empty_body> 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
response_type res;
Truncate history, version 1.0.0-b2
2017-07-20 08:01:46 -07:00
};
Refactor websocket::stream operations
2019-01-20 12:25:30 -08:00
stream<NextLayer, deflateSupported>& ws_;
detail::sec_ws_key_type key_;
response_type* res_p_;
Use async_op_base: Composed operation implementations use async_op_base and stable_async_op_base, to eliminate redundant boilerplate.
2019-01-05 19:40:46 -08:00
data& d_;
Truncate history, version 1.0.0-b2
2017-07-20 08:01:46 -07:00
public:
Refactor websocket::stream operations
2019-01-20 12:25:30 -08:00
template<class Handler_, class Decorator>
Use async_op_base: Composed operation implementations use async_op_base and stable_async_op_base, to eliminate redundant boilerplate.
2019-01-05 19:40:46 -08:00
handshake_op(
Handler_&& h,
Refactor websocket::stream operations
2019-01-20 12:25:30 -08:00
stream& ws,
response_type* res_p,
string_view host, string_view target,
Decorator const& decorator)
Add tests for async_op_base
2019-01-09 16:11:15 -08:00
: stable_async_op_base<Handler,
Add executor_type trait
2019-02-04 21:52:54 -08:00
beast::executor_type<stream>>(
Add tests for async_op_base
2019-01-09 16:11:15 -08:00
std::forward<Handler_>(h), ws.get_executor())
Refactor websocket::stream operations
2019-01-20 12:25:30 -08:00
, ws_(ws)
, res_p_(res_p)
, d_(beast::allocate_stable<data>(*this))
Truncate history, version 1.0.0-b2
2017-07-20 08:01:46 -07:00
{
Refactor websocket::stream operations
2019-01-20 12:25:30 -08:00
d_.req = ws_.build_request(
key_, host, target, decorator);
ws_.impl_->reset(); // VFALCO I don't like this
Truncate history, version 1.0.0-b2
2017-07-20 08:01:46 -07:00
}
Update for Net-TS Asio (API Change): fix #769 The following classes are removed: * handler_type * async_result * async_completion * is_dynamic_buffer * is_const_buffer_sequence * is_mutable_buffer_sequence * handler_alloc Actions Required: * Use BOOST_ASIO_HANDLER_TYPE instead of handler_type * Use BOOST_ASIO_INITFN_RESULT_TYPE instead of async_result * Use boost::asio::async_completion * Use boost::asio::is_dynamic_buffer * Use boost::asio::is_const_buffer_sequence * Use boost::asio::is_mutable_buffer_sequence * boost::asio::associated_allocator_t replaces handler_alloc
2017-09-07 07:39:52 -07:00
void
operator()(
error_code ec = {},
Use async_op_base: Composed operation implementations use async_op_base and stable_async_op_base, to eliminate redundant boilerplate.
2019-01-05 19:40:46 -08:00
std::size_t bytes_used = 0)
Truncate history, version 1.0.0-b2
2017-07-20 08:01:46 -07:00
{
Use async_op_base: Composed operation implementations use async_op_base and stable_async_op_base, to eliminate redundant boilerplate.
2019-01-05 19:40:46 -08:00
boost::ignore_unused(bytes_used);
BOOST_ASIO_CORO_REENTER(*this)
Use executor_work_guard in composed operations: fix #1076 As per Asio and Networking TS requirements, composed operations must maintain an object of type executor_work_guard for the executor associated with the I/O object, for the lifetime of the asynchronous operation. This is in addition to the requirement for maintaining an object of type executor_work_guard for the executor associated with the handler.
2018-04-09 16:22:15 -07:00
{
Use async_op_base: Composed operation implementations use async_op_base and stable_async_op_base, to eliminate redundant boilerplate.
2019-01-05 19:40:46 -08:00
// Send HTTP Upgrade
Refactor websocket::stream operations
2019-01-20 12:25:30 -08:00
ws_.impl_->do_pmd_config(d_.req);
Use async_op_base: Composed operation implementations use async_op_base and stable_async_op_base, to eliminate redundant boilerplate.
2019-01-05 19:40:46 -08:00
BOOST_ASIO_CORO_YIELD
Refactor websocket::stream operations
2019-01-20 12:25:30 -08:00
http::async_write(ws_.impl_->stream,
Use async_op_base: Composed operation implementations use async_op_base and stable_async_op_base, to eliminate redundant boilerplate.
2019-01-05 19:40:46 -08:00
d_.req, std::move(*this));
if(ec)
goto upcall;
// Read HTTP response
BOOST_ASIO_CORO_YIELD
Refactor websocket::stream operations
2019-01-20 12:25:30 -08:00
http::async_read(ws_.next_layer(),
ws_.impl_->rd_buf, d_.res,
Use async_op_base: Composed operation implementations use async_op_base and stable_async_op_base, to eliminate redundant boilerplate.
2019-01-05 19:40:46 -08:00
std::move(*this));
if(ec)
goto upcall;
Refactor websocket::stream operations
2019-01-20 12:25:30 -08:00
ws_.on_response(d_.res, key_, ec);
if(res_p_)
swap(d_.res, *res_p_);
Use async_op_base: Composed operation implementations use async_op_base and stable_async_op_base, to eliminate redundant boilerplate.
2019-01-05 19:40:46 -08:00
upcall:
Rename to async_op_base::invoke_now
2019-02-15 15:02:38 -08:00
this->invoke_now(ec);
Use executor_work_guard in composed operations: fix #1076 As per Asio and Networking TS requirements, composed operations must maintain an object of type executor_work_guard for the executor associated with the I/O object, for the lifetime of the asynchronous operation. This is in addition to the requirement for maintaining an object of type executor_work_guard for the executor associated with the handler.
2018-04-09 16:22:15 -07:00
}
Truncate history, version 1.0.0-b2
2017-07-20 08:01:46 -07:00
}
Use async_op_base: Composed operation implementations use async_op_base and stable_async_op_base, to eliminate redundant boilerplate.
2019-01-05 19:40:46 -08:00
};
Truncate history, version 1.0.0-b2
2017-07-20 08:01:46 -07:00
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
template<class NextLayer, bool deflateSupported>
Reorganize source files and definitions
2016-10-24 08:12:09 -04:00
template<class HandshakeHandler>
Update for Net-TS Asio (API Change): fix #769 The following classes are removed: * handler_type * async_result * async_completion * is_dynamic_buffer * is_const_buffer_sequence * is_mutable_buffer_sequence * handler_alloc Actions Required: * Use BOOST_ASIO_HANDLER_TYPE instead of handler_type * Use BOOST_ASIO_INITFN_RESULT_TYPE instead of async_result * Use boost::asio::async_completion * Use boost::asio::is_dynamic_buffer * Use boost::asio::is_const_buffer_sequence * Use boost::asio::is_mutable_buffer_sequence * boost::asio::associated_allocator_t replaces handler_alloc
2017-09-07 07:39:52 -07:00
BOOST_ASIO_INITFN_RESULT_TYPE(
HandshakeHandler, void(error_code))
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
stream<NextLayer, deflateSupported>::
Canonicalize string_view parameter types
2017-06-04 10:52:28 -07:00
async_handshake(string_view host,
string_view target,
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
HandshakeHandler&& handler)
Reorganize source files and definitions
2016-10-24 08:12:09 -04:00
{
Concept revision and documentation (API Change): The concept type traits are renamed for consistency, and consolidated into a single header file <beast/core/type_traits.hpp> A new section, Core Concepts, is added to the documentation describing all of the core utility classes and functions. This also includes a complete explanation and sample program describing how to write asynchronous initiation functions and their associated composed operations.
2017-05-10 12:03:00 -07:00
static_assert(is_async_stream<next_layer_type>::value,
Reorganize source files and definitions
2016-10-24 08:12:09 -04:00
"AsyncStream requirements not met");
Type check completion handlers fix #988
2018-01-26 08:58:19 -08:00
BOOST_BEAST_HANDLER_INIT(
HandshakeHandler, void(error_code));
Update for Net-TS Asio (API Change): fix #769 The following classes are removed: * handler_type * async_result * async_completion * is_dynamic_buffer * is_const_buffer_sequence * is_mutable_buffer_sequence * handler_alloc Actions Required: * Use BOOST_ASIO_HANDLER_TYPE instead of handler_type * Use BOOST_ASIO_INITFN_RESULT_TYPE instead of async_result * Use boost::asio::async_completion * Use boost::asio::is_dynamic_buffer * Use boost::asio::is_const_buffer_sequence * Use boost::asio::is_mutable_buffer_sequence * boost::asio::associated_allocator_t replaces handler_alloc
2017-09-07 07:39:52 -07:00
handshake_op<BOOST_ASIO_HANDLER_TYPE(
HandshakeHandler, void(error_code))>{
Don't copy completion handlers: All asynchronous operations will now be able to use move-only CompletionHandlers. Signed-off-by: Damian Jarek <damian.jarek93@gmail.com>
2017-12-02 12:59:30 +01:00
std::move(init.completion_handler), *this, nullptr, host,
websocket handshake uses coroutine
2017-08-19 19:27:08 -07:00
target, &default_decorate_req}();
Harmonize concepts and identifiers with net-ts (API Change): fix #321 This synchronizes identifier names and some implementation details with the Networking-TS document and reference implementation. The following interfaces have changed: * async_completion * is_buffer_sequence (removed) * is_const_buffer_sequence (was is_ConstBufferSequence) * is_dynamic_buffer (was is_DynamicBuffer) * is_mutable_buffer_sequence (was is_MutableBufferSequence) * async_result (new) * BEAST_HANDLER_TYPE macro (new) * BEAST_INITFN_RESULT_TYPE macro (new) Filename changes: * async_result.hpp (was async_completion.hpp)
2017-05-06 12:36:40 -07:00
return init.result.get();
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
}
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
template<class NextLayer, bool deflateSupported>
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. 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 HandshakeHandler>
Update for Net-TS Asio (API Change): fix #769 The following classes are removed: * handler_type * async_result * async_completion * is_dynamic_buffer * is_const_buffer_sequence * is_mutable_buffer_sequence * handler_alloc Actions Required: * Use BOOST_ASIO_HANDLER_TYPE instead of handler_type * Use BOOST_ASIO_INITFN_RESULT_TYPE instead of async_result * Use boost::asio::async_completion * Use boost::asio::is_dynamic_buffer * Use boost::asio::is_const_buffer_sequence * Use boost::asio::is_mutable_buffer_sequence * boost::asio::associated_allocator_t replaces handler_alloc
2017-09-07 07:39:52 -07:00
BOOST_ASIO_INITFN_RESULT_TYPE(
HandshakeHandler, void(error_code))
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
stream<NextLayer, deflateSupported>::
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. 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_handshake(response_type& res,
Canonicalize string_view parameter types
2017-06-04 10:52:28 -07:00
string_view host,
string_view target,
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
HandshakeHandler&& handler)
{
Concept revision and documentation (API Change): The concept type traits are renamed for consistency, and consolidated into a single header file <beast/core/type_traits.hpp> A new section, Core Concepts, is added to the documentation describing all of the core utility classes and functions. This also includes a complete explanation and sample program describing how to write asynchronous initiation functions and their associated composed operations.
2017-05-10 12:03:00 -07:00
static_assert(is_async_stream<next_layer_type>::value,
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
"AsyncStream requirements not met");
Type check completion handlers fix #988
2018-01-26 08:58:19 -08:00
BOOST_BEAST_HANDLER_INIT(
HandshakeHandler, void(error_code));
Update for Net-TS Asio (API Change): fix #769 The following classes are removed: * handler_type * async_result * async_completion * is_dynamic_buffer * is_const_buffer_sequence * is_mutable_buffer_sequence * handler_alloc Actions Required: * Use BOOST_ASIO_HANDLER_TYPE instead of handler_type * Use BOOST_ASIO_INITFN_RESULT_TYPE instead of async_result * Use boost::asio::async_completion * Use boost::asio::is_dynamic_buffer * Use boost::asio::is_const_buffer_sequence * Use boost::asio::is_mutable_buffer_sequence * boost::asio::associated_allocator_t replaces handler_alloc
2017-09-07 07:39:52 -07:00
handshake_op<BOOST_ASIO_HANDLER_TYPE(
HandshakeHandler, void(error_code))>{
Don't copy completion handlers: All asynchronous operations will now be able to use move-only CompletionHandlers. Signed-off-by: Damian Jarek <damian.jarek93@gmail.com>
2017-12-02 12:59:30 +01:00
std::move(init.completion_handler), *this, &res, host,
websocket handshake uses coroutine
2017-08-19 19:27:08 -07:00
target, &default_decorate_req}();
Harmonize concepts and identifiers with net-ts (API Change): fix #321 This synchronizes identifier names and some implementation details with the Networking-TS document and reference implementation. The following interfaces have changed: * async_completion * is_buffer_sequence (removed) * is_const_buffer_sequence (was is_ConstBufferSequence) * is_dynamic_buffer (was is_DynamicBuffer) * is_mutable_buffer_sequence (was is_MutableBufferSequence) * async_result (new) * BEAST_HANDLER_TYPE macro (new) * BEAST_INITFN_RESULT_TYPE macro (new) Filename changes: * async_result.hpp (was async_completion.hpp)
2017-05-06 12:36:40 -07:00
return init.result.get();
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
}
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
template<class NextLayer, bool deflateSupported>
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. 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, class HandshakeHandler>
Update for Net-TS Asio (API Change): fix #769 The following classes are removed: * handler_type * async_result * async_completion * is_dynamic_buffer * is_const_buffer_sequence * is_mutable_buffer_sequence * handler_alloc Actions Required: * Use BOOST_ASIO_HANDLER_TYPE instead of handler_type * Use BOOST_ASIO_INITFN_RESULT_TYPE instead of async_result * Use boost::asio::async_completion * Use boost::asio::is_dynamic_buffer * Use boost::asio::is_const_buffer_sequence * Use boost::asio::is_mutable_buffer_sequence * boost::asio::associated_allocator_t replaces handler_alloc
2017-09-07 07:39:52 -07:00
BOOST_ASIO_INITFN_RESULT_TYPE(
HandshakeHandler, void(error_code))
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
stream<NextLayer, deflateSupported>::
Canonicalize string_view parameter types
2017-06-04 10:52:28 -07:00
async_handshake_ex(string_view host,
string_view target,
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
RequestDecorator const& decorator,
HandshakeHandler&& handler)
{
Concept revision and documentation (API Change): The concept type traits are renamed for consistency, and consolidated into a single header file <beast/core/type_traits.hpp> A new section, Core Concepts, is added to the documentation describing all of the core utility classes and functions. This also includes a complete explanation and sample program describing how to write asynchronous initiation functions and their associated composed operations.
2017-05-10 12:03:00 -07:00
static_assert(is_async_stream<next_layer_type>::value,
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
"AsyncStream requirements not met");
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
static_assert(detail::is_request_decorator<
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
RequestDecorator>::value,
"RequestDecorator requirements not met");
Type check completion handlers fix #988
2018-01-26 08:58:19 -08:00
BOOST_BEAST_HANDLER_INIT(
HandshakeHandler, void(error_code));
Update for Net-TS Asio (API Change): fix #769 The following classes are removed: * handler_type * async_result * async_completion * is_dynamic_buffer * is_const_buffer_sequence * is_mutable_buffer_sequence * handler_alloc Actions Required: * Use BOOST_ASIO_HANDLER_TYPE instead of handler_type * Use BOOST_ASIO_INITFN_RESULT_TYPE instead of async_result * Use boost::asio::async_completion * Use boost::asio::is_dynamic_buffer * Use boost::asio::is_const_buffer_sequence * Use boost::asio::is_mutable_buffer_sequence * boost::asio::associated_allocator_t replaces handler_alloc
2017-09-07 07:39:52 -07:00
handshake_op<BOOST_ASIO_HANDLER_TYPE(
HandshakeHandler, void(error_code))>{
Don't copy completion handlers: All asynchronous operations will now be able to use move-only CompletionHandlers. Signed-off-by: Damian Jarek <damian.jarek93@gmail.com>
2017-12-02 12:59:30 +01:00
std::move(init.completion_handler), *this, nullptr, host,
websocket handshake uses coroutine
2017-08-19 19:27:08 -07:00
target, decorator}();
Harmonize concepts and identifiers with net-ts (API Change): fix #321 This synchronizes identifier names and some implementation details with the Networking-TS document and reference implementation. The following interfaces have changed: * async_completion * is_buffer_sequence (removed) * is_const_buffer_sequence (was is_ConstBufferSequence) * is_dynamic_buffer (was is_DynamicBuffer) * is_mutable_buffer_sequence (was is_MutableBufferSequence) * async_result (new) * BEAST_HANDLER_TYPE macro (new) * BEAST_INITFN_RESULT_TYPE macro (new) Filename changes: * async_result.hpp (was async_completion.hpp)
2017-05-06 12:36:40 -07:00
return init.result.get();
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
}
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
template<class NextLayer, bool deflateSupported>
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. 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, class HandshakeHandler>
Update for Net-TS Asio (API Change): fix #769 The following classes are removed: * handler_type * async_result * async_completion * is_dynamic_buffer * is_const_buffer_sequence * is_mutable_buffer_sequence * handler_alloc Actions Required: * Use BOOST_ASIO_HANDLER_TYPE instead of handler_type * Use BOOST_ASIO_INITFN_RESULT_TYPE instead of async_result * Use boost::asio::async_completion * Use boost::asio::is_dynamic_buffer * Use boost::asio::is_const_buffer_sequence * Use boost::asio::is_mutable_buffer_sequence * boost::asio::associated_allocator_t replaces handler_alloc
2017-09-07 07:39:52 -07:00
BOOST_ASIO_INITFN_RESULT_TYPE(
HandshakeHandler, void(error_code))
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
stream<NextLayer, deflateSupported>::
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. 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_handshake_ex(response_type& res,
Canonicalize string_view parameter types
2017-06-04 10:52:28 -07:00
string_view host,
string_view target,
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
RequestDecorator const& decorator,
HandshakeHandler&& handler)
{
Concept revision and documentation (API Change): The concept type traits are renamed for consistency, and consolidated into a single header file <beast/core/type_traits.hpp> A new section, Core Concepts, is added to the documentation describing all of the core utility classes and functions. This also includes a complete explanation and sample program describing how to write asynchronous initiation functions and their associated composed operations.
2017-05-10 12:03:00 -07:00
static_assert(is_async_stream<next_layer_type>::value,
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
"AsyncStream requirements not met");
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
static_assert(detail::is_request_decorator<
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
RequestDecorator>::value,
"RequestDecorator requirements not met");
Type check completion handlers fix #988
2018-01-26 08:58:19 -08:00
BOOST_BEAST_HANDLER_INIT(
HandshakeHandler, void(error_code));
Update for Net-TS Asio (API Change): fix #769 The following classes are removed: * handler_type * async_result * async_completion * is_dynamic_buffer * is_const_buffer_sequence * is_mutable_buffer_sequence * handler_alloc Actions Required: * Use BOOST_ASIO_HANDLER_TYPE instead of handler_type * Use BOOST_ASIO_INITFN_RESULT_TYPE instead of async_result * Use boost::asio::async_completion * Use boost::asio::is_dynamic_buffer * Use boost::asio::is_const_buffer_sequence * Use boost::asio::is_mutable_buffer_sequence * boost::asio::associated_allocator_t replaces handler_alloc
2017-09-07 07:39:52 -07:00
handshake_op<BOOST_ASIO_HANDLER_TYPE(
HandshakeHandler, void(error_code))>{
Don't copy completion handlers: All asynchronous operations will now be able to use move-only CompletionHandlers. Signed-off-by: Damian Jarek <damian.jarek93@gmail.com>
2017-12-02 12:59:30 +01:00
std::move(init.completion_handler), *this, &res, host,
websocket handshake uses coroutine
2017-08-19 19:27:08 -07:00
target, decorator}();
Harmonize concepts and identifiers with net-ts (API Change): fix #321 This synchronizes identifier names and some implementation details with the Networking-TS document and reference implementation. The following interfaces have changed: * async_completion * is_buffer_sequence (removed) * is_const_buffer_sequence (was is_ConstBufferSequence) * is_dynamic_buffer (was is_DynamicBuffer) * is_mutable_buffer_sequence (was is_MutableBufferSequence) * async_result (new) * BEAST_HANDLER_TYPE macro (new) * BEAST_INITFN_RESULT_TYPE macro (new) Filename changes: * async_result.hpp (was async_completion.hpp)
2017-05-06 12:36:40 -07:00
return init.result.get();
Reorganize source files and definitions
2016-10-24 08:12:09 -04:00
}
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
template<class NextLayer, bool deflateSupported>
Reorganize source files and definitions
2016-10-24 08:12:09 -04:00
void
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
stream<NextLayer, deflateSupported>::
Canonicalize string_view parameter types
2017-06-04 10:52:28 -07:00
handshake(string_view host,
string_view target)
Reorganize source files and definitions
2016-10-24 08:12:09 -04:00
{
Concept revision and documentation (API Change): The concept type traits are renamed for consistency, and consolidated into a single header file <beast/core/type_traits.hpp> A new section, Core Concepts, is added to the documentation describing all of the core utility classes and functions. This also includes a complete explanation and sample program describing how to write asynchronous initiation functions and their associated composed operations.
2017-05-10 12:03:00 -07:00
static_assert(is_sync_stream<next_layer_type>::value,
Reorganize source files and definitions
2016-10-24 08:12:09 -04:00
"SyncStream requirements not met");
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
handshake(
Refactor http::header contents (API Change): fix #124 The http::header data members "method", "url", and "reason" are changed from data members, to pairs of get and set functions which forward the call to the Fields type used to instantiate the template. Previously, these data members were implemented using std::string. With this change, the implementation of the Fields type used to instantiate the template is now in control of the representation of those values. This permits custom memory allocation strategies including uniform use of the Allocator type already provided to beast::http::basic_fields.
2017-05-02 15:49:22 -07:00
host, target, ec);
Reorganize source files and definitions
2016-10-24 08:12:09 -04:00
if(ec)
Use BOOST_THROW_EXCEPTION fix #370
2017-05-22 15:30:12 -07:00
BOOST_THROW_EXCEPTION(system_error{ec});
Reorganize source files and definitions
2016-10-24 08:12:09 -04:00
}
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
template<class NextLayer, bool deflateSupported>
Reorganize source files and definitions
2016-10-24 08:12:09 -04:00
void
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
stream<NextLayer, deflateSupported>::
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. 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(response_type& res,
Canonicalize string_view parameter types
2017-06-04 10:52:28 -07:00
string_view host,
string_view target)
Reorganize source files and definitions
2016-10-24 08:12:09 -04:00
{
Concept revision and documentation (API Change): The concept type traits are renamed for consistency, and consolidated into a single header file <beast/core/type_traits.hpp> A new section, Core Concepts, is added to the documentation describing all of the core utility classes and functions. This also includes a complete explanation and sample program describing how to write asynchronous initiation functions and their associated composed operations.
2017-05-10 12:03:00 -07:00
static_assert(is_sync_stream<next_layer_type>::value,
Reorganize source files and definitions
2016-10-24 08:12:09 -04:00
"SyncStream requirements not met");
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. 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;
Refactor http::header contents (API Change): fix #124 The http::header data members "method", "url", and "reason" are changed from data members, to pairs of get and set functions which forward the call to the Fields type used to instantiate the template. Previously, these data members were implemented using std::string. With this change, the implementation of the Fields type used to instantiate the template is now in control of the representation of those values. This permits custom memory allocation strategies including uniform use of the Allocator type already provided to beast::http::basic_fields.
2017-05-02 15:49:22 -07:00
handshake(res, host, target, ec);
Reorganize source files and definitions
2016-10-24 08:12:09 -04:00
if(ec)
Use BOOST_THROW_EXCEPTION fix #370
2017-05-22 15:30:12 -07:00
BOOST_THROW_EXCEPTION(system_error{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
}
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
template<class NextLayer, bool deflateSupported>
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. 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
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
stream<NextLayer, deflateSupported>::
Canonicalize string_view parameter types
2017-06-04 10:52:28 -07:00
handshake_ex(string_view host,
string_view target,
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
RequestDecorator const& decorator)
{
Concept revision and documentation (API Change): The concept type traits are renamed for consistency, and consolidated into a single header file <beast/core/type_traits.hpp> A new section, Core Concepts, is added to the documentation describing all of the core utility classes and functions. This also includes a complete explanation and sample program describing how to write asynchronous initiation functions and their associated composed operations.
2017-05-10 12:03:00 -07:00
static_assert(is_sync_stream<next_layer_type>::value,
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
"SyncStream requirements not met");
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
static_assert(detail::is_request_decorator<
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
RequestDecorator>::value,
"RequestDecorator requirements not met");
error_code ec;
Refactor http::header contents (API Change): fix #124 The http::header data members "method", "url", and "reason" are changed from data members, to pairs of get and set functions which forward the call to the Fields type used to instantiate the template. Previously, these data members were implemented using std::string. With this change, the implementation of the Fields type used to instantiate the template is now in control of the representation of those values. This permits custom memory allocation strategies including uniform use of the Allocator type already provided to beast::http::basic_fields.
2017-05-02 15:49:22 -07:00
handshake_ex(host, target, decorator, ec);
Reorganize source files and definitions
2016-10-24 08:12:09 -04:00
if(ec)
Use BOOST_THROW_EXCEPTION fix #370
2017-05-22 15:30:12 -07:00
BOOST_THROW_EXCEPTION(system_error{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
}
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
template<class NextLayer, bool deflateSupported>
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. 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
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
stream<NextLayer, deflateSupported>::
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. 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,
Canonicalize string_view parameter types
2017-06-04 10:52:28 -07:00
string_view host,
string_view target,
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
RequestDecorator const& decorator)
{
Concept revision and documentation (API Change): The concept type traits are renamed for consistency, and consolidated into a single header file <beast/core/type_traits.hpp> A new section, Core Concepts, is added to the documentation describing all of the core utility classes and functions. This also includes a complete explanation and sample program describing how to write asynchronous initiation functions and their associated composed operations.
2017-05-10 12:03:00 -07:00
static_assert(is_sync_stream<next_layer_type>::value,
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
"SyncStream requirements not met");
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
static_assert(detail::is_request_decorator<
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
RequestDecorator>::value,
"RequestDecorator requirements not met");
error_code ec;
Refactor http::header contents (API Change): fix #124 The http::header data members "method", "url", and "reason" are changed from data members, to pairs of get and set functions which forward the call to the Fields type used to instantiate the template. Previously, these data members were implemented using std::string. With this change, the implementation of the Fields type used to instantiate the template is now in control of the representation of those values. This permits custom memory allocation strategies including uniform use of the Allocator type already provided to beast::http::basic_fields.
2017-05-02 15:49:22 -07:00
handshake_ex(res, host, target, decorator, 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
if(ec)
Use BOOST_THROW_EXCEPTION fix #370
2017-05-22 15:30:12 -07:00
BOOST_THROW_EXCEPTION(system_error{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
}
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
template<class NextLayer, bool deflateSupported>
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. 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
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
stream<NextLayer, deflateSupported>::
Canonicalize string_view parameter types
2017-06-04 10:52:28 -07:00
handshake(string_view host,
string_view target, error_code& ec)
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
{
Concept revision and documentation (API Change): The concept type traits are renamed for consistency, and consolidated into a single header file <beast/core/type_traits.hpp> A new section, Core Concepts, is added to the documentation describing all of the core utility classes and functions. This also includes a complete explanation and sample program describing how to write asynchronous initiation functions and their associated composed operations.
2017-05-10 12:03:00 -07:00
static_assert(is_sync_stream<next_layer_type>::value,
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
"SyncStream requirements not met");
do_handshake(nullptr,
Refactor http::header contents (API Change): fix #124 The http::header data members "method", "url", and "reason" are changed from data members, to pairs of get and set functions which forward the call to the Fields type used to instantiate the template. Previously, these data members were implemented using std::string. With this change, the implementation of the Fields type used to instantiate the template is now in control of the representation of those values. This permits custom memory allocation strategies including uniform use of the Allocator type already provided to beast::http::basic_fields.
2017-05-02 15:49:22 -07:00
host, target, &default_decorate_req, 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
}
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
template<class NextLayer, bool deflateSupported>
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. 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
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
stream<NextLayer, deflateSupported>::
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. 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(response_type& res,
Canonicalize string_view parameter types
2017-06-04 10:52:28 -07:00
string_view host,
string_view target,
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
error_code& ec)
{
Concept revision and documentation (API Change): The concept type traits are renamed for consistency, and consolidated into a single header file <beast/core/type_traits.hpp> A new section, Core Concepts, is added to the documentation describing all of the core utility classes and functions. This also includes a complete explanation and sample program describing how to write asynchronous initiation functions and their associated composed operations.
2017-05-10 12:03:00 -07:00
static_assert(is_sync_stream<next_layer_type>::value,
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
"SyncStream requirements not met");
do_handshake(&res,
Refactor http::header contents (API Change): fix #124 The http::header data members "method", "url", and "reason" are changed from data members, to pairs of get and set functions which forward the call to the Fields type used to instantiate the template. Previously, these data members were implemented using std::string. With this change, the implementation of the Fields type used to instantiate the template is now in control of the representation of those values. This permits custom memory allocation strategies including uniform use of the Allocator type already provided to beast::http::basic_fields.
2017-05-02 15:49:22 -07:00
host, target, &default_decorate_req, 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
}
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
template<class NextLayer, bool deflateSupported>
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. 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
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
stream<NextLayer, deflateSupported>::
Canonicalize string_view parameter types
2017-06-04 10:52:28 -07:00
handshake_ex(string_view host,
string_view target,
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
RequestDecorator const& decorator,
error_code& ec)
{
Concept revision and documentation (API Change): The concept type traits are renamed for consistency, and consolidated into a single header file <beast/core/type_traits.hpp> A new section, Core Concepts, is added to the documentation describing all of the core utility classes and functions. This also includes a complete explanation and sample program describing how to write asynchronous initiation functions and their associated composed operations.
2017-05-10 12:03:00 -07:00
static_assert(is_sync_stream<next_layer_type>::value,
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
"SyncStream requirements not met");
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
static_assert(detail::is_request_decorator<
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
RequestDecorator>::value,
"RequestDecorator requirements not met");
do_handshake(nullptr,
Refactor http::header contents (API Change): fix #124 The http::header data members "method", "url", and "reason" are changed from data members, to pairs of get and set functions which forward the call to the Fields type used to instantiate the template. Previously, these data members were implemented using std::string. With this change, the implementation of the Fields type used to instantiate the template is now in control of the representation of those values. This permits custom memory allocation strategies including uniform use of the Allocator type already provided to beast::http::basic_fields.
2017-05-02 15:49:22 -07:00
host, target, decorator, 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
}
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
template<class NextLayer, bool deflateSupported>
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. 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
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
stream<NextLayer, deflateSupported>::
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. 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,
Canonicalize string_view parameter types
2017-06-04 10:52:28 -07:00
string_view host,
string_view target,
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
RequestDecorator const& decorator,
error_code& ec)
{
Concept revision and documentation (API Change): The concept type traits are renamed for consistency, and consolidated into a single header file <beast/core/type_traits.hpp> A new section, Core Concepts, is added to the documentation describing all of the core utility classes and functions. This also includes a complete explanation and sample program describing how to write asynchronous initiation functions and their associated composed operations.
2017-05-10 12:03:00 -07:00
static_assert(is_sync_stream<next_layer_type>::value,
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
"SyncStream requirements not met");
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
static_assert(detail::is_request_decorator<
Refactor websocket decorators (API Change): fix #80, #212, fix #303, fix #314, fix #317 websocket::stream now provides the following families of functions for performing handshakes: When operating in the server role: * stream::accept * stream::accept_ex * stream::async_accept * stream::async_accept_ex When operating in the client role: * stream::handshake * stream::handshake_ex * stream::async_handshake * stream::async_handshake_ex Member functions ending with "_ex" allow an additional RequestDecorator parameter (for the accept family of functions) or ResponseDecorator parameter (for the handshake family of functions). The decorator is called to optionally modify the contents of the HTTP request or HTTP response object generated by the implementation, before the message is sent. This permits callers to set the User-Agent or Server fields, add or modify HTTP fields related to subprotocols, or perform any required transformation of the HTTP message for application-specific needs. The handshake() family of functions now have an additional set of overloads accepting a parameter of type response_type&, allowing the caller to receive the HTTP Response to the Upgrade handshake. This permits inspection of the response to handle things like subprotocols, authentication, or other application-specific needs. The new implementation does not require any state to be stored in the stream object. Therefore, websocket::stream objects are now smaller in size. The overload of set_option for setting a decorator on the stream is removed. The only way to set decorators now is with a suitable overload of accept or handshake.
2017-04-25 09:35:22 -07:00
RequestDecorator>::value,
"RequestDecorator requirements not met");
do_handshake(&res,
Refactor http::header contents (API Change): fix #124 The http::header data members "method", "url", and "reason" are changed from data members, to pairs of get and set functions which forward the call to the Fields type used to instantiate the template. Previously, these data members were implemented using std::string. With this change, the implementation of the Fields type used to instantiate the template is now in control of the representation of those values. This permits custom memory allocation strategies including uniform use of the Allocator type already provided to beast::http::basic_fields.
2017-05-02 15:49:22 -07:00
host, target, decorator, ec);
Reorganize source files and definitions
2016-10-24 08:12:09 -04:00
}
//------------------------------------------------------------------------------
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
template<class NextLayer, bool deflateSupported>
Refactor accept, handshake ops
2017-07-27 14:14:47 -07:00
template<class RequestDecorator>
void
permessage-deflate is a compile-time feature (API Change): fix #849 This adds an additional `bool` template parameter to `websocket::stream`: * When deflateSupported is `true`, the stream will be capable of negotiating the permessage-deflate websocket extension per the configured run-time settings. * When deflateSupported is `false`, the stream will never negotiate the permessage-deflate websocket extension. Furthermore, all of the code necessary for implementing the permessage-deflate extension will be excluded from function instantiations. The resulting emitted object code should be smaller.
2017-11-18 16:52:18 -08:00
stream<NextLayer, deflateSupported>::
Refactor accept, handshake ops
2017-07-27 14:14:47 -07:00
do_handshake(
response_type* res_p,
string_view host,
string_view target,
RequestDecorator const& decorator,
error_code& ec)
{
response_type res;
websocket stream uses shared_ptr<impl_type>
2019-01-19 07:24:00 -08:00
impl_->reset();
Refactor accept, handshake ops
2017-07-27 14:14:47 -07:00
detail::sec_ws_key_type key;
{
auto const req = build_request(
key, host, target, decorator);
websocket stream uses shared_ptr<impl_type>
2019-01-19 07:24:00 -08:00
this->impl_->do_pmd_config(req);
http::write(impl_->stream, req, ec);
Refactor accept, handshake ops
2017-07-27 14:14:47 -07:00
}
if(ec)
return;
websocket stream uses shared_ptr<impl_type>
2019-01-19 07:24:00 -08:00
http::read(next_layer(), impl_->rd_buf, res, ec);
Refactor accept, handshake ops
2017-07-27 14:14:47 -07:00
if(ec)
return;
Refactor fail/clode code
2017-08-02 13:25:53 -07:00
on_response(res, key, ec);
Refactor accept, handshake ops
2017-07-27 14:14:47 -07:00
if(res_p)
*res_p = std::move(res);
}
Truncate history, version 1.0.0-b2
2017-07-20 08:01:46 -07:00
} // websocket
} // beast
Boost prep
2017-07-20 13:40:34 -07:00
} // boost
Truncate history, version 1.0.0-b2
2017-07-20 08:01:46 -07:00
#endif
Copy Permalink