The C++ REST SDK is a Microsoft project for cloud-based client-server communication in native code using a modern asynchronous C++ API design. This project aims to help C++ developers connect to and interact with services.

• Homebrew sometimes appends the version of a package to it' directory name. Thus, one could have /usr/local/Cellar/[email protected]/ instead of /usr/local/Cellar/openssl/, or even both. I fixed the search for OPENSSL_ROOT_DIR and limited it's contents to one path only.
• Added the <package>-config-version.in.cmake file configuration for CMake find_package usage.
• Corrected condition in <package>-config.in.cmake for Boost usage. There was a @[email protected] AND OFF condition, which is always false. The result was that the Boost libraries and includes were not included in the users CMake project.
• Use CMAKE_INSTALL_INCLUDEDIR to install headers. cpprestsdk already uses CMAKE_INSTALL_LIBDIR & CMAKE_INSTALL_BINDIR

Update 3 is causing compiler errors in CppRestSdk v 2.8

2>C:\Dev\Couloir\3pLibs\cpprestsdk-master\Release\include\cpprest/streams.h(900): error C2187: syntax error: 'identifier' was unexpected here 2>C:\Dev\Couloir\3pLibs\cpprestsdk-master\Release\include\cpprest/streams.h(1133): note: see reference to class template instantiation 'Concurrency::streams::basic_istream<_CharType>' being compiled 2>C:\Dev\Couloir\3pLibs\cpprestsdk-master\Release\include\cpprest/http_msg.h(553): error C2039: 'to_utf16string': is not a member of '`global namespace'' 2>C:\Dev\Couloir\3pLibs\cpprestsdk-master\Release\include\cpprest/http_msg.h(553): error C3861: 'to_utf16string': identifier not found

					return buffer.bumpc().then([](

#ifndef _WIN32 // Required by GCC typename #endif 900 --.> concurrency::streams::char_traits::int_type) { return false; });

Compilation: c++14 /permissive- /Zc:throwingNew /Zc:inline /bigobj

Is there a simple code change I can make?

After trying the cpprest library out (on Linux), specifically the http_listener, I have quickly discovered that the default number of threads that are created is 40 threads. Nonetheless, I've examined the code, and I have been unable to ascertain why a value of 40 has been chosen.

A hard-coded thread count is likely to go against a popular school of thought that the number of threads should match the number of CPU cores (or at the most: thread_count <= (2 x cpu cores)). For example, my development system contains 4 cores.

Having thought about this further, there should be two (2) potential changes - the first one is easier than the second:

1. The thread count should be configurable via a parameter during intialisation of the http_listener.
2. Applicable classes should enable developers to instantiate instances of an object specifying a custom thread pool.

Environment: Ubuntu Zesty 17.04 Boost 1.62 GCC 6.3 cpprest 2.9

Google's thread sanitizer is reporting a data race on _pplx_g_sched_t::get_scheduler() function which I discovered creating multiple websocket instances at the same time on Linux.

You can run this simpler snippet to reproduce:

#include <thread>
#include <cpprest/ws_client.h>

int main() {
  //pplx::get_ambient_scheduler();  // uncomment this line to fix the data race
  std::thread a([] () { pplx::get_ambient_scheduler(); });
  std::thread b([] () { pplx::get_ambient_scheduler(); });
  a.join();
  b.join();
  return 0;
}

This is sanitizer's output:

==================
WARNING: ThreadSanitizer: data race (pid=4653)
  Read of size 8 at 0x7f96cf428c50 by thread T2:
    #0 std::__shared_ptr<pplx::scheduler_interface, (__gnu_cxx::_Lock_policy)2>::operator bool() const /usr/include/c++/8.2.1/bits/shared_ptr_base.h:1291 (libcpprest.so.2.10+0xa787a2)
    #1 pplx::_pplx_g_sched_t::get_scheduler() /home/bambino/projects/tradehelm/libfix-adapter/vendor/cpprest/Release/src/pplx/pplx.cpp:77 (libcpprest.so.2.10+0xa784e4)
    #2 pplx::get_ambient_scheduler() /home/bambino/projects/tradehelm/libfix-adapter/vendor/cpprest/Release/src/pplx/pplx.cpp:125 (libcpprest.so.2.10+0xa77e36)
    #3 operator() /data/projects/pruebas/c++/pplx-ambient-scheduler.cpp:7 (a.out+0x33a9)
    #4 __invoke_impl<void, main()::<lambda()> > /usr/include/c++/8.2.1/bits/invoke.h:60 (a.out+0x3b4e)
    #5 __invoke<main()::<lambda()> > /usr/include/c++/8.2.1/bits/invoke.h:95 (a.out+0x366b)
    #6 _M_invoke<0> /usr/include/c++/8.2.1/thread:244 (a.out+0x4198)
    #7 operator() /usr/include/c++/8.2.1/thread:253 (a.out+0x40c3)
    #8 _M_run /usr/include/c++/8.2.1/thread:196 (a.out+0x4024)
    #9 execute_native_thread_routine /build/gcc/src/gcc/libstdc++-v3/src/c++11/thread.cc:80 (libstdc++.so.6+0xbc062)

  Previous write of size 8 at 0x7f96cf428c50 by thread T1:
    #0 std::enable_if<std::__and_<std::__not_<std::__is_tuple_like<pplx::scheduler_interface*> >, std::is_move_constructible<pplx::scheduler_interface*>, std::is_move_assignable<pplx::scheduler_interface*> >::value, void>::type std::swap<pplx::scheduler_interface*>(pplx::scheduler_interface*&, pplx::scheduler_interface*&) /usr/include/c++/8.2.1/bits/move.h:195 (libcpprest.so.2.10+0xa78f48)
    #1 std::__shared_ptr<pplx::scheduler_interface, (__gnu_cxx::_Lock_policy)2>::swap(std::__shared_ptr<pplx::scheduler_interface, (__gnu_cxx::_Lock_policy)2>&) /usr/include/c++/8.2.1/bits/shared_ptr_base.h:1304 (libcpprest.so.2.10+0xa78da8)
    #2 std::enable_if<std::__sp_compatible_with<pplx::details::linux_scheduler*, pplx::scheduler_interface*>::value, std::__shared_ptr<pplx::scheduler_interface, (__gnu_cxx::_Lock_policy)2>&>::type std::__shared_ptr<pplx::scheduler_interface, (__gnu_cxx::_Lock_policy)2>::operator=<pplx::details::linux_scheduler>(std::__shared_ptr<pplx::details::linux_scheduler, (__gnu_cxx::_Lock_policy)2>&&) /usr/include/c++/8.2.1/bits/shared_ptr_base.h:1251 (libcpprest.so.2.10+0xa78bac)
    #3 std::enable_if<std::is_assignable<std::__shared_ptr<pplx::scheduler_interface, (__gnu_cxx::_Lock_policy)2>&, std::shared_ptr<pplx::details::linux_scheduler> >::value, std::shared_ptr<pplx::scheduler_interface>&>::type std::shared_ptr<pplx::scheduler_interface>::operator=<pplx::details::linux_scheduler>(std::shared_ptr<pplx::details::linux_scheduler>&&) /usr/include/c++/8.2.1/bits/shared_ptr.h:343 (libcpprest.so.2.10+0xa78947)
    #4 pplx::_pplx_g_sched_t::get_scheduler() /home/bambino/projects/tradehelm/libfix-adapter/vendor/cpprest/Release/src/pplx/pplx.cpp:82 (libcpprest.so.2.10+0xa7853c)
    #5 pplx::get_ambient_scheduler() /home/bambino/projects/tradehelm/libfix-adapter/vendor/cpprest/Release/src/pplx/pplx.cpp:125 (libcpprest.so.2.10+0xa77e36)
    #6 operator() /data/projects/pruebas/c++/pplx-ambient-scheduler.cpp:6 (a.out+0x3333)
    #7 __invoke_impl<void, main()::<lambda()> > /usr/include/c++/8.2.1/bits/invoke.h:60 (a.out+0x3910)
    #8 __invoke<main()::<lambda()> > /usr/include/c++/8.2.1/bits/invoke.h:95 (a.out+0x350d)
    #9 _M_invoke<0> /usr/include/c++/8.2.1/thread:244 (a.out+0x41f0)
    #10 operator() /usr/include/c++/8.2.1/thread:253 (a.out+0x412d)
    #11 _M_run /usr/include/c++/8.2.1/thread:196 (a.out+0x406e)
    #12 execute_native_thread_routine /build/gcc/src/gcc/libstdc++-v3/src/c++11/thread.cc:80 (libstdc++.so.6+0xbc062)

  Location is global 'pplx::_pplx_g_sched' of size 32 at 0x7f96cf428c40 (libcpprest.so.2.10+0x000000d58c50)

  Thread T2 (tid=4656, running) created by main thread at:
    #0 pthread_create /build/gcc/src/gcc/libsanitizer/tsan/tsan_interceptors.cc:915 (libtsan.so.0+0x2bf03)
    #1 __gthread_create /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/gthr-default.h:662 (libstdc++.so.6+0xbc359)
    #2 std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) /build/gcc/src/gcc/libstdc++-v3/src/c++11/thread.cc:135 (libstdc++.so.6+0xbc359)
    #3 main /data/projects/pruebas/c++/pplx-ambient-scheduler.cpp:7 (a.out+0x3435)

  Thread T1 (tid=4655, finished) created by main thread at:
    #0 pthread_create /build/gcc/src/gcc/libsanitizer/tsan/tsan_interceptors.cc:915 (libtsan.so.0+0x2bf03)
    #1 __gthread_create /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/gthr-default.h:662 (libstdc++.so.6+0xbc359)
    #2 std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) /build/gcc/src/gcc/libstdc++-v3/src/c++11/thread.cc:135 (libstdc++.so.6+0xbc359)
    #3 main /data/projects/pruebas/c++/pplx-ambient-scheduler.cpp:6 (a.out+0x3422)

SUMMARY: ThreadSanitizer: data race /usr/include/c++/8.2.1/bits/shared_ptr_base.h:1291 in std::__shared_ptr<pplx::scheduler_interface, (__gnu_cxx::_Lock_policy)2>::operator bool() const
==================

However, I don't see the actual data race on said function:

    sched_ptr get_scheduler()
    {
        switch (m_state)
        {
            case post_ctor:
                // This is the 99.9% case.

                if (!m_scheduler)
                {
                    ::pplx::details::_Scoped_spin_lock lock(m_spinlock);
                    if (!m_scheduler)
                    {
                        m_scheduler = std::make_shared<::pplx::default_scheduler_t>();
                    }
                }

                return m_scheduler;
            default:
                // This case means the global m_scheduler is not available.
                // We spin off an individual scheduler instead.
                return std::make_shared<::pplx::default_scheduler_t>();
        }
    }

It's easy to avoid the WARNING reported by the sanitizer, making a call to pplx::get_ambient_scheduler() beforehand. In my application, I use a global variable which makes a call to the function and I wonder if something similar should be applied to cpprestsdk to ease the task to other developers seeing the same data-race.

An alternative might be to call get_scheduler in _pplx_g_sched_t's constructor. Something like this:

_pplx_g_sched_t() { m_state = post_ctor; get_scheduler(); }

Thoughts? Ping @BillyONeal

HTTP redirect is currently supported by the WinHttp back-end, but has to be handled manually in user code when C++ REST SDK is built with the ASIO-based back-end. This kind of platform difference is frustrating for users.

Solving this issue has been requested several times, e.g. #222. A previous PR #373 was abandoned.

This PR enables us to pass the 'outside tests' that were identified as failing in #27, even after reverting both PR #499 (which worked around the problem by permitting MovedPermanent in the test) and another similar case from commit 4e19c0cfb439febf6b3ee20efc857313ca2ba7f7.

If this PR seems acceptable, it should be straightforward to use the new http_client_config options in the http_client_winhttp implementation also, which would solve #171 more elegantly.

Thoughts on how the headers sent with the redirect request are decided would be welcome!

[email protected]:~/repos/casablanca/Release/build.debug$ make Scanning dependencies of target cpprest [ 1%] Building CXX object src/CMakeFiles/cpprest.dir/http/client/http_client.cpp.o In file included from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/eventfd_select_interrupter.hpp:80:0, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/select_interrupter.hpp:25, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/epoll_reactor.hpp:29, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/reactor.hpp:21, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/impl/task_io_service.ipp:24, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/task_io_service.hpp:198, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/impl/io_service.hpp:71, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/io_service.hpp:767, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/ssl/context.hpp:26, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/ssl.hpp:19, from /home/alon/repos/casablanca/Release/include/cpprest/http_client.h:53, from /home/alon/repos/casablanca/Release/src/pch/stdafx.h:104, from /home/alon/repos/casablanca/Release/src/http/client/http_client.cpp:16: /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/impl/eventfd_select_interrupter.ipp: In member function ‘void boost::asio::detail::eventfd_select_interrupter::interrupt()’: /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/impl/eventfd_select_interrupter.ipp:122:23: error: conversion to ‘int’ from ‘ssize_t {aka long int}’ may alter its value [-Werror=conversion] int result = ::write(write_descriptor_, &counter, sizeof(uint64_t)); ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/impl/eventfd_select_interrupter.ipp: In member function ‘bool boost::asio::detail::eventfd_select_interrupter::reset()’: /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/impl/eventfd_select_interrupter.ipp:135:30: error: conversion to ‘int’ from ‘ssize_t {aka long int}’ may alter its value [-Werror=conversion] int bytes_read = ::read(read_descriptor_, &counter, sizeof(uint64_t)); ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/impl/eventfd_select_interrupter.ipp:148:30: error: conversion to ‘int’ from ‘ssize_t {aka long int}’ may alter its value [-Werror=conversion] int bytes_read = ::read(read_descriptor_, data, sizeof(data)); ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/impl/eventfd_select_interrupter.ipp:153:28: error: conversion to ‘int’ from ‘ssize_t {aka long int}’ may alter its value [-Werror=conversion] bytes_read = ::read(read_descriptor_, data, sizeof(data)); ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/epoll_reactor.hpp:248:0, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/reactor.hpp:21, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/impl/task_io_service.ipp:24, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/task_io_service.hpp:198, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/impl/io_service.hpp:71, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/io_service.hpp:767, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/ssl/context.hpp:26, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/ssl.hpp:19, from /home/alon/repos/casablanca/Release/include/cpprest/http_client.h:53, from /home/alon/repos/casablanca/Release/src/pch/stdafx.h:104, from /home/alon/repos/casablanca/Release/src/http/client/http_client.cpp:16: /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/impl/epoll_reactor.ipp: In member function ‘int boost::asio::detail::epoll_reactor::get_timeout()’: /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/impl/epoll_reactor.ipp:605:42: error: conversion to ‘int’ from ‘long int’ may alter its value [-Werror=conversion] return timer_queues_.wait_duration_msec(5 * 60 * 1000); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~ In file included from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/ssl/context.hpp:786:0, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/ssl.hpp:19, from /home/alon/repos/casablanca/Release/include/cpprest/http_client.h:53, from /home/alon/repos/casablanca/Release/src/pch/stdafx.h:104, from /home/alon/repos/casablanca/Release/src/http/client/http_client.cpp:16: /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/ssl/impl/context.ipp: In member function ‘boost::system::error_code boost::asio::ssl::context::use_certificate_chain(const boost::asio::const_buffer&, boost::system::error_code&)’: /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/ssl/impl/context.ipp:757:35: error: conversion to ‘int’ from ‘long unsigned int’ may alter its value [-Werror=conversion] result = ::ERR_peek_last_error(); ~~~~~~~~~~~~~~~~~~~~~^~ In file included from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/socket_ops.hpp:333:0, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/ip/impl/address_v4.ipp:22, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/ip/address_v4.hpp:240, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/ip/address.hpp:21, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/ssl/impl/rfc2818_verification.ipp:23, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/ssl/rfc2818_verification.hpp:99, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/ssl.hpp:23, from /home/alon/repos/casablanca/Release/include/cpprest/http_client.h:53, from /home/alon/repos/casablanca/Release/src/pch/stdafx.h:104, from /home/alon/repos/casablanca/Release/src/http/client/http_client.cpp:16: /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/impl/socket_ops.ipp: In function ‘int boost::asio::detail::socket_ops::close(boost::asio::detail::socket_type, boost::asio::detail::socket_ops::state_type&, bool, boost::system::error_code&)’: /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/impl/socket_ops.ipp:345:17: error: conversion to ‘boost::asio::detail::socket_ops::state_type {aka unsigned char}’ from ‘int’ may alter its value [-Werror=conversion] state &= ~non_blocking; ^~~~~~~~~~~~ /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/impl/socket_ops.ipp: In function ‘bool boost::asio::detail::socket_ops::set_user_non_blocking(boost::asio::detail::socket_type, boost::asio::detail::socket_ops::state_type&, bool, boost::system::error_code&)’: /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/impl/socket_ops.ipp:397:63: error: conversion to ‘boost::asio::detail::socket_ops::state_type {aka unsigned char}’ from ‘int’ may alter its value [-Werror=conversion] state &= ~(user_set_non_blocking | internal_non_blocking); ^ /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/impl/socket_ops.ipp: In function ‘bool boost::asio::detail::socket_ops::set_internal_non_blocking(boost::asio::detail::socket_type, boost::asio::detail::socket_ops::state_type&, bool, boost::system::error_code&)’: /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/impl/socket_ops.ipp:446:17: error: conversion to ‘boost::asio::detail::socket_ops::state_type {aka unsigned char}’ from ‘int’ may alter its value [-Werror=conversion] state &= ~internal_non_blocking; ^~~~~~~~~~~~~~~~~~~~~ /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/impl/socket_ops.ipp: In function ‘int boost::asio::detail::socket_ops::setsockopt(boost::asio::detail::socket_type, boost::asio::detail::socket_ops::state_type&, int, int, const void*, std::size_t, boost::system::error_code&)’: /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/impl/socket_ops.ipp:1458:17: error: conversion to ‘boost::asio::detail::socket_ops::state_type {aka unsigned char}’ from ‘int’ may alter its value [-Werror=conversion] state &= ~enable_connection_aborted; ^~~~~~~~~~~~~~~~~~~~~~~~~ /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/impl/socket_ops.ipp: In function ‘int boost::asio::detail::socket_ops::ioctl(boost::asio::detail::socket_type, boost::asio::detail::socket_ops::state_type&, int, boost::asio::detail::ioctl_arg_type*, boost::system::error_code&)’: /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/impl/socket_ops.ipp:1739:65: error: conversion to ‘boost::asio::detail::socket_ops::state_type {aka unsigned char}’ from ‘int’ may alter its value [-Werror=conversion] state &= ~(user_set_non_blocking | internal_non_blocking); ^ /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/impl/socket_ops.ipp: In function ‘boost::system::error_code boost::asio::detail::socket_ops::getnameinfo(const socket_addr_type*, std::size_t, char*, std::size_t, char*, std::size_t, int, boost::system::error_code&)’: /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/impl/socket_ops.ipp:3356:79: error: conversion to ‘socklen_t {aka unsigned int}’ from ‘std::size_t {aka long unsigned int}’ may alter its value [-Werror=conversion] int error = ::getnameinfo(addr, addrlen, host, hostlen, serv, servlen, flags); ^ /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/impl/socket_ops.ipp:3356:79: error: conversion to ‘socklen_t {aka unsigned int}’ from ‘std::size_t {aka long unsigned int}’ may alter its value [-Werror=conversion] /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/asio/detail/impl/socket_ops.ipp:3356:79: error: conversion to ‘socklen_t {aka unsigned int}’ from ‘std::size_t {aka long unsigned int}’ may alter its value [-Werror=conversion] In file included from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/thread/thread_time.hpp:10:0, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/thread/lock_types.hpp:18, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/thread/pthread/mutex.hpp:16, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/thread/mutex.hpp:16, from /home/alon/repos/casablanca/Release/src/pch/stdafx.h:62, from /home/alon/repos/casablanca/Release/src/http/client/http_client.cpp:16: /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/date_time/microsec_time_clock.hpp: In instantiation of ‘static time_type boost::date_time::microsec_clock<time_type>::create_time(boost::date_time::microsec_clock<time_type>::time_converter) [with time_type = boost::posix_time::ptime; boost::date_time::microsec_clock<time_type>::time_converter = tm* ()(const long int, tm*); time_t = long int]’: /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/date_time/microsec_time_clock.hpp:76:25: required from ‘static time_type boost::date_time::microsec_clock<time_type>::universal_time() [with time_type = boost::posix_time::ptime]’ /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/thread/thread_time.hpp:22:63: required from here /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/date_time/microsec_time_clock.hpp:86:36: error: conversion to ‘uint32_t {aka unsigned int}’ from ‘suseconds_t {aka long int}’ may alter its value [-Werror=conversion] boost::uint32_t sub_sec = tv.tv_usec; ~~~^~~~~~~ In file included from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/date_time/adjust_functors.hpp:13:0, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/date_time/gregorian/greg_duration_types.hpp:15, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/date_time/gregorian/gregorian_types.hpp:22, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/date_time/posix_time/posix_time_config.hpp:18, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/date_time/posix_time/posix_time_system.hpp:13, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/date_time/posix_time/ptime.hpp:12, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/date_time/posix_time/posix_time_types.hpp:12, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/thread/thread_time.hpp:11, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/thread/lock_types.hpp:18, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/thread/pthread/mutex.hpp:16, from /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/thread/mutex.hpp:16, from /home/alon/repos/casablanca/Release/src/pch/stdafx.h:62, from /home/alon/repos/casablanca/Release/src/http/client/http_client.cpp:16: /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/date_time/wrapping_int.hpp: In instantiation of ‘IntT boost::date_time::wrapping_int2<int_type, wrap_min, wrap_max>::calculate_wrap(IntT) [with IntT = short int; int_type = short int; int_type_ wrap_min = 1; int_type_ wrap_max = 12]’: /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/date_time/wrapping_int.hpp:126:35: required from ‘IntT boost::date_time::wrapping_int2<int_type_, wrap_min, wrap_max>::add(IntT) [with IntT = short int; int_type_ = short int; int_type_ wrap_min = 1; int_type_ wrap_max = 12]’ /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/date_time/adjust_functors.hpp:77:29: required from ‘boost::date_time::month_functor<date_type>::duration_type boost::date_time::month_functor<date_type>::get_offset(const date_type&) const [with date_type = boost::gregorian::date; boost::date_time::month_functor<date_type>::duration_type = boost::gregorian::date_duration]’ /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/date_time/date_duration_types.hpp:67:16: required from ‘boost::date_time::months_duration<base_config>::duration_type boost::date_time::months_duration<base_config>::get_offset(const date_type&) const [with base_config = boost::gregorian::greg_durations_config; boost::date_time::months_duration<base_config>::duration_type = boost::gregorian::date_duration; boost::date_time::months_duration<base_config>::date_type = boost::gregorian::date]’ /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/date_time/posix_time/date_duration_operators.hpp:33:37: required from here /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/date_time/wrapping_int.hpp:151:14: error: conversion to ‘boost::date_time::wrapping_int2<short int, 1, 12>::int_type {aka short int}’ from ‘int’ may alter its value [-Werror=conversion] value_ -= (wrap_max - wrap_min + 1); ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/alon/repos/voiceengine/voiceengine/voiceengine/boost_1_65_1/boost/date_time/wrapping_int.hpp:156:14: error: conversion to ‘boost::date_time::wrapping_int2<short int, 1, 12>::int_type {aka short int}’ from ‘int’ may alter its value [-Werror=conversion] value_ += (wrap_max - wrap_min + 1); ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~ At global scope: cc1plus: error: unrecognized command line option ‘-Wno-format-truncation’ [-Werror] cc1plus: all warnings being treated as errors src/CMakeFiles/cpprest.dir/build.make:62: recipe for target 'src/CMakeFiles/cpprest.dir/http/client/http_client.cpp.o' failed make[2]: *** [src/CMakeFiles/cpprest.dir/http/client/http_client.cpp.o] Error 1 CMakeFiles/Makefile2:85: recipe for target 'src/CMakeFiles/cpprest.dir/all' failed make[1]: *** [src/CMakeFiles/cpprest.dir/all] Error 2 Makefile:140: recipe for target 'all' failed make: *** [all] Error 2

I had been hoping to find a websocket server implementation to use alongside http_listener. Have I missed it, is it in the roadmap, or do you have any pointers on doing it myself (I'm currently looking at mashing something up wrapping websocketpp::server)?

Thanks!

Some applications will benefit from being able to enable tcp::no_delay as well as QUICKACK within both the client (http_client_asio.cpp) and listener (http_server_asio.cpp).

I have previously opened #1189. And I think this should potentially address #468 (This actually does mention enabling tcp::no_delay by someone recently.

I was previously experiencing horrendous RTT (roughly 100ms - 400ms+). Applying this on the client (both client and server use cpprestsdk) saw an improvement where now the average is 70ms RTT. I am still doing some experiments to see why this isn't lower, but this is a marked improvement because server profiling showed I was being blocked and hence "server CPU time" was more or less the RTT. Now, the "server CPU time" is roughly 4ms. So that in itself is dramatic.

Note that from my initial testing, the client side seems more important. Yet I'm still also indicating we allow this enabled on the listeners as well. I am by no means claiming to be an expert on this. I am only suggesting the ability to enable on the listener for parity and to allow for easier experimentation.

Ideally I wanted to create a wrapper handler in asio_connection's async_connect. This way anyone calling async_connect would have this automatically applied. However I could not get the syntax correct, so I ended up putting the code directly in the calling functions' handlers. Does anyone know how to properly create an "intermediary" handler so this could be more cleanly done?

I have a branch with my changes. Note this forces it into this mode. The clean solution is to make this optional. But if anyone wants to test for timings to help see if this reduces some performance issues, that would be awesome.

https://github.com/mobileben/cpprestsdk/tree/nagle-quickack

Note the "nagle" in the branch name is a little misleading. This ends up disabling Nagle by enabling tcp::no_delay.

Running a test that just contains this line:

::web::json::value::parse( R"([ { "k1" : "v" }, { "k2" : "v" }, { "k3" : "v" }, { "k4" : "v" } ])" );

...through Clang's address sanitizer, I get:

==9344==ERROR: AddressSanitizer: container-overflow on address 0x6030000029f8 at pc 0x00000059e020 bp 0x7fffeea53300 sp 0x7fffeea532f8
READ of size 8 at 0x6030000029f8 thread T0
    #0 0x59e01f in std::__1::unique_ptr<web::json::details::_Value, std::__1::default_delete<web::json::details::_Value> >::reset(web::json::details::_Value*) /opt/clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/../include/c++/v1/memory:2631:28
    #1 0x59e01f in std::__1::unique_ptr<web::json::details::_Value, std::__1::default_delete<web::json::details::_Value> >::~unique_ptr() /opt/clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/../include/c++/v1/memory:2588
    #2 0x59e01f in web::json::value::~value() ~/source/cpprestsdk-clang/include/cpprest/json.h:71
    #3 0xdd7d00 in std::__1::allocator<web::json::value>::destroy(web::json::value*) /opt/clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/../include/c++/v1/memory:1866:64
    #4 0xdd7d00 in void std::__1::allocator_traits<std::__1::allocator<web::json::value> >::__destroy<web::json::value>(std::__1::integral_constant<bool, true>, std::__1::allocator<web::json::value>&, web::json::value*) /opt/clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/../include/c++/v1/memory:1728
    #5 0xdd7d00 in void std::__1::allocator_traits<std::__1::allocator<web::json::value> >::destroy<web::json::value>(std::__1::allocator<web::json::value>&, web::json::value*) /opt/clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/../include/c++/v1/memory:1596
    #6 0xdd7d00 in std::__1::__vector_base<web::json::value, std::__1::allocator<web::json::value> >::__destruct_at_end(web::json::value*) /opt/clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/../include/c++/v1/vector:421
    #7 0xdd7d00 in std::__1::__vector_base<web::json::value, std::__1::allocator<web::json::value> >::clear() /opt/clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/../include/c++/v1/vector:364
    #8 0xdd7d00 in std::__1::__vector_base<web::json::value, std::__1::allocator<web::json::value> >::~__vector_base() /opt/clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/../include/c++/v1/vector:458
    #9 0xdd7a84 in std::__1::vector<web::json::value, std::__1::allocator<web::json::value> >::~vector() /opt/clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/../include/c++/v1/iterator:1427:74
    #10 0x7efd1d648a24 in web::json::array::~array() (~/source/cpprestsdk-clang/lib/libcpprest.so.2.10+0x57ea24)
    #11 0x7efd1d646780 in web::json::details::_Array::~_Array() (~/source/cpprestsdk-clang/lib/libcpprest.so.2.10+0x57c780)
    #12 0x7efd1d6467b8 in web::json::details::_Array::~_Array() (~/source/cpprestsdk-clang/lib/libcpprest.so.2.10+0x57c7b8)
    #13 0x59e131 in std::__1::default_delete<web::json::details::_Value>::operator()(web::json::details::_Value*) const /opt/clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/../include/c++/v1/memory:2321:5
    #14 0x59e131 in std::__1::unique_ptr<web::json::details::_Value, std::__1::default_delete<web::json::details::_Value> >::reset(web::json::details::_Value*) /opt/clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/../include/c++/v1/memory:2634
    #15 0x59e131 in std::__1::unique_ptr<web::json::details::_Value, std::__1::default_delete<web::json::details::_Value> >::~unique_ptr() /opt/clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/../include/c++/v1/memory:2588
    #16 0x59e131 in web::json::value::~value() ~/source/cpprestsdk-clang/include/cpprest/json.h:71
    #17 0x58ae2a in _DOCTEST_ANON_FUNC_4() my-working-directory/clang-address-sanitizer/../desktop/test_desktop/desktop_test.cpp:19:5
    #18 0xaa9e09 in doctest::Context::run() my-working-directory/clang-address-sanitizer/../3rdparty/doctest.h:5367:21
    #19 0xab0b88 in main my-working-directory/clang-address-sanitizer/../utility/test_main/test_main.cpp:30:29
    #20 0x7efd14eccb96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
    #21 0x4a50a9 in _start (my-working-directory/clang-address-sanitizer/desktop/test-desktop+0x4a50a9)

0x6030000029f8 is located 24 bytes inside of 32-byte region [0x6030000029e0,0x603000002a00)
allocated by thread T0 here:
    #0 0x57c152 in operator new(unsigned long) /tmp/final/llvm.src/projects/compiler-rt/lib/asan/asan_new_delete.cc:106:3
    #1 0xdd9857 in std::__1::__libcpp_allocate(unsigned long, unsigned long) /opt/clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/../include/c++/v1/new:252:10
    #2 0xdd9857 in std::__1::allocator<web::json::value>::allocate(unsigned long, void const*) /opt/clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/../include/c++/v1/memory:1799
    #3 0xdd9857 in std::__1::allocator_traits<std::__1::allocator<web::json::value> >::allocate(std::__1::allocator<web::json::value>&, unsigned long) /opt/clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/../include/c++/v1/memory:1548
    #4 0xdd9857 in std::__1::__split_buffer<web::json::value, std::__1::allocator<web::json::value>&>::__split_buffer(unsigned long, unsigned long, std::__1::allocator<web::json::value>&) /opt/clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/../include/c++/v1/__split_buffer:311
    #5 0x7efd1d65d48c in void std::__1::vector<web::json::value, std::__1::allocator<web::json::value> >::__emplace_back_slow_path<web::json::value>(web::json::value&&) (~/source/cpprestsdk-clang/lib/libcpprest.so.2.10+0x59348c)
    #6 0x7efd1d65b326 in web::json::details::JSON_Parser<char>::_ParseArray(web::json::details::JSON_Parser<char>::Token&) (~/source/cpprestsdk-clang/lib/libcpprest.so.2.10+0x591326)
    #7 0x7efd1d656f4b in web::json::details::JSON_Parser<char>::_ParseValue(web::json::details::JSON_Parser<char>::Token&) (~/source/cpprestsdk-clang/lib/libcpprest.so.2.10+0x58cf4b)
    #8 0x7efd1d652670 in web::json::details::JSON_Parser<char>::ParseValue(web::json::details::JSON_Parser<char>::Token&) (~/source/cpprestsdk-clang/lib/libcpprest.so.2.10+0x588670)
    #9 0x7efd1d65113a in web::json::value::parse(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) (~/source/cpprestsdk-clang/lib/libcpprest.so.2.10+0x58713a)
    #10 0x58ae1c in _DOCTEST_ANON_FUNC_4() my-working-directory/clang-address-sanitizer/../desktop/test_desktop/desktop_test.cpp:19:5
    #11 0xaa9e09 in doctest::Context::run() my-working-directory/clang-address-sanitizer/../3rdparty/doctest.h:5367:21
    #12 0xab0b88 in main my-working-directory/clang-address-sanitizer/../utility/test_main/test_main.cpp:30:29
    #13 0x7efd14eccb96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_container_overflow=0.
If you suspect a false positive see also: https://github.com/google/sanitizers/wiki/AddressSanitizerContainerOverflow.
SUMMARY: AddressSanitizer: container-overflow /opt/clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/../include/c++/v1/memory:2631:28 in std::__1::unique_ptr<web::json::details::_Value, std::__1::default_delete<web::json::details::_Value> >::reset(web::json::details::_Value*)
Shadow bytes around the buggy address:
  0x0c067fff84e0: fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00
  0x0c067fff84f0: 00 00 fa fa fd fd fd fd fa fa fd fd fd fd fa fa
  0x0c067fff8500: fd fd fd fd fa fa fd fd fd fd fa fa fd fd fd fd
  0x0c067fff8510: fa fa fd fd fd fd fa fa 00 00 00 fa fa fa 00 00
  0x0c067fff8520: 00 fc fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa
=>0x0c067fff8530: 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00 00[fc]
  0x0c067fff8540: fa fa 00 00 00 00 fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8550: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8560: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8570: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff8580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc

I've confirmed that this problem still occurs with a recent commit (7368961107986d1aa801dbc65cb8b22c1090b1f3).

I'm using:

clang version 7.0.0 (tags/RELEASE_700/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

Ubuntu 18.04.1 LTS
Linux 4.15.0-39-generic #42-Ubuntu SMP Tue Oct 23 15:48:01 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Why does code exhibit an apparent memory leak?

            TEST_F( WebServiceTests, client_request )
            {
               // Setup
               const String URL( L"https://url.net/Log/Messages/2.8" );

               // Software Unit Under Test
               web::http::uri TheURI( URL );
               web::http::client::http_client client( TheURI );

               client.request( web::http::methods::GET ).then( [&]( web::http::http_response response )
               {
                  if( response.status_code() == web::http::status_codes::OK )
                  {
                     auto result = response.extract_json().get();
                  }
                  if( response.status_code() == web::http::status_codes::NotFound )
                  {
                     Log::msg( MALFUNCTION, "http_response 404" );
                  }
               } ).get();

               // Analysis

               // Evaluate

               // Cleanup
            }

0 bytes in 0 Free Blocks. 416 bytes in 16 Normal Blocks. 12944 bytes in 14 CRT Blocks. 0 bytes in 0 Ignore Blocks. 0 bytes in 0 Client Blocks. Largest number used: 24252 bytes. Total allocations: 44796 bytes. C:\Dev\Couloir\3pLibs\Include\MemLeakListener.h(56): error: Failed Memory leak in WebServiceTests.client_request

Duplicated from CodePlex (issue 421) since the documentation says that issues should be reported to GitHub instead:

When calling http_listener.close().wait() as we're shutting down our service, the application will occasionally deadlock because the wait operation never returns. The deadlock appears to be in the http_windows_server::stop() function, there's a wait that never returns.

pplx::task<void> http_windows_server::stop()
{
    // Shutdown request queue.
    if(m_hRequestQueue != nullptr)
    {
        HttpShutdownRequestQueue(m_hRequestQueue);
         m_receivingTask.wait();

        // Wait for all requests to be finished processing.
        m_zeroOutstandingRequests.wait(); // Deadlock appears to be here

        HttpCloseRequestQueue(m_hRequestQueue);
    }