- Boost - lists.preview.boost.org

Re: [boost] [Beast] Questions Before Review
by Artyom Beilis 01 Jul '17

01 Jul '17

http vs WebSocket -------------------------- I noticed some strange difference in these requests : // Wrap the now-connected socket in a websocket stream websocket::stream<tcp::socket&> ws{sock}; // Perform the websocket handhskae ws.handshake(host, "/", ec); if(ec) return fail("handshake", ec); This one is fast and easy to use does all it needed Now HTTP is very different story http::request<http::string_body> req; req.method(http::verb::get); req.target("/"); req.version = 11; req.set(http::field::host, host + ":" + std::to_string(sock.remote_endpoint().port())); req.set(http::field::user_agent, BEAST_VERSION_STRING); req.prepare_payload(); Most of stuff can be defined there by default: version 1.1, Host header - required by http/1.1 why should I bother? User agent put one by default unless user wants - you do all this stuff for WS handshake so why not there? Why so complicated? ----------------- Protocol Premier HTTP/1.1 example without host. Your example isn't valid HTTP /1.1 request. HTTP /1.1 unlike 1.0 requires host header Artyom

2 4

[Beast] Security issue note
by Artyom Beilis 01 Jul '17

01 Jul '17

Looking into parser/body code I noticed: parser: void on_body(boost::optional< std::uint64_t> const& content_length, error_code& ec) { wr_.emplace(m_); wr_->init(content_length, ec); } string_body: void init(boost::optional< std::uint64_t> content_length, error_code& ec) { if(content_length) { if(*content_length > (std::numeric_limits< std::size_t>::max)()) { ec = make_error_code( errc::not_enough_memory); return; } ec.assign(0, ec.category()); body_.reserve(static_cast< std::size_t>(*content_length)); } } Basically I can exhaust the memory of the server and kill it by providing huge content length from several connections and lead to its crash. Reasonable and configurable limit should be provided for content length. Artyom Beilis

2 6

[Beast] Questions Before Review
by Artyom Beilis 01 Jul '17

01 Jul '17

Hello Vinnie Falco, I have several design questions regarding this library before the review. DISCLIMER: My name is Artyom Beilis. I'm the author of CppCMS C++ Web Framework: http://cppcms.com It may seems like it can be in some competition with Beast but I don't see it this way as Beast is too low level library that does not addresses typical problems of developers needing Web API/Site running using C++. CppCMS addresses totally different problems in different way. So there are my design related questions: Header Only Design --------------------------- As somebody who worked with guys who do web development, it was very clear that compilation time is an issue. A simple build of http_server_small.cpp example requires about 6s(!) of compilation time g++ 5.4 http_server_fast.cpp takes 7s In comparison entire message board containing templates code flow SQL and more leads to only 4s - non paralel build. (https://github.com/artyom-beilis/cppcms/tree/master/examples/message_board ) I understand that you work on base of Boost.Asio - which itself has unacceptable compilation times but having for web application development may be serious deal breaker for big projects. Which Leads me to another design Choice Template Meta-programming Based Design instead of classic Object Oriented Design ---------------------------------------------------------------------------------------------------------------- I see that almost every object there is some kind of template object. It almost mimics the API of Boost.Asio which on its way has its limitations. I remember I needed to implement FastCGI over TCP and Unix domain sockets virtually leading to same code besides some initial bind - and it required to create the entire parser using template programming because the socket itself was template object different for UNIX and TCP. I have strong feeling that lots of stuff can actually be done using classic OOP. Example Question: > Can I implement same server code for both SSL and non SSL HTTP protocol > without use of templates in the class itself? And my current final question Who are the potential users of the library? ------------------------------------------------------- If I need to send a simple http request to server it does not seem to do simple enough job (see your FAQ) so I'll probably be better with feature rich libcurl. If I need to implement complex web server/service I don't have cookies, sessions, forms, html? If I need to implement RESTful API do I have all stuff like URL mapping of different paths to callbacks, protocol abstraction http/https (basic stuff - I don't see it there correct me if I wrong) Is it for web server developers? Maybe I'd be happier with simple HTTP protocol parser that I can integrate to any socket API? Can you please give more accurate description of who is this library intended for? Best Regards, Artyom Beilis

5 21

Follow-up to the CMake follow-up
by Peter Dimov 01 Jul '17

01 Jul '17

Due to the strong interest in my previous follow-up, I'm following it up with a more complete implementation of the support required for CMake scenario #1, installing configuration files during "b2 install" such that subsequent "find_package" calls work (assuming a suitably set CMAKE_PREFIX_PATH). You can find it in branch "feature/install-cmake-config" in the superproject (boostorg/boost). In other words, git clone --recursive --depth 64 -b feature/install-cmake-config https://githib.com/boostorg/boost bootstrap b2 headers b2 install cmake//install variant=debug,release link=static,shared runtime-link=static,shared This doesn't yet support installation with more than one toolset, and I'm sure that some libraries don't work, but a simple test using Filesystem and ProgramOptions does. /// CMakeLists.txt: /// cmake_minimum_required(VERSION 3.5) project(cmake_demo CXX) list(APPEND CMAKE_PREFIX_PATH C:/Boost) find_package(boost_filesystem 1.63.0) find_package(boost_program_options 1.63.0) # disable autolink globally # could also do it per-target add_definitions(-DBOOST_ALL_NO_LIB=1) # sample program add_executable(cmake_demo cmake_demo.cpp) target_link_libraries(cmake_demo boost::filesystem boost::program_options) /// cmake_demo.cpp: /// #include <boost/filesystem.hpp> #include <boost/program_options.hpp> #include <cerrno> #include <iostream> namespace fs = boost::filesystem; namespace po = boost::program_options; int main( int argc, char const* argv[] ) { po::options_description desc( "Allowed options" ); desc.add_options() ( "help,h", "produce help message" ) ( "path,p", po::value<std::string>(), "set initial path" ) ; po::variables_map vm; try { po::store( po::parse_command_line( argc, argv, desc ), vm ); po::notify( vm ); } catch( std::exception const & x ) { std::cerr << "Error: " << x.what() << std::endl; return 1; } if( vm.count( "help" ) ) { std::cout << desc << std::endl; return 1; } fs::path p = fs::current_path(); if( vm.count( "path" ) ) { p = vm[ "path" ].as<std::string>(); } std::cout << p << std::endl; }

2 1

Does Boost 1.64 support HP-UX?
by 장윤진 30 Jun '17

30 Jun '17

I read about the platform that boost supports on the boost homepage. However, I do not know if it supports HP-UX. http://www.boost.org/doc/libs/1_64_0/libs/log/doc/html/log/installation.htm… Supported compilers and platforms. The library should build and work with a reasonably compliant compiler. The library was successfully built and tested on the following platforms: Windows XP, Windows Vista, Windows 7. MSVC 8.0 SP1, MSVC 9.0 and newer. Linux. GCC 4.5 and newer. Older versions may work too, but it was not tested. Linux. Intel C++ 13.1.0.146 Build 20130121. Linux. Clang 3.2. Does that mean it supports HP-UX?

3 2

Noexcept
by Emil Dotchevski 30 Jun '17

30 Jun '17

The lively debates during the Outcome review show that there is a great deal of interest in solving the problem of error handling in environments where C++ exception handling is unavailable. Noexcept is a new C++11 library that implements a different approach to solving the same problem. Any feedback is welcome. https://zajo.github.io/boost-noexcept/ Emil

12 81

[review] Mp11 review starts in two weeks
by Bjorn Reese 29 Jun '17

29 Jun '17

The formal review of Peter Dimov's Mp11 library is scheduled for July 15 - July 24, 2017 [1]. Mp11 is a C++11 metaprogramming library for compile-time manipulation of data structures that contain types. It’s based on template aliases and variadic templates and implements the approach outlined in the article "Simple C++ metaprogramming" [2] and its sequel [3]. These articles are useful background information for the review. * Mp11 aims to make simple usage simple, and to support complex usage without complicating the simple use cases. * Mp11 works on any type-list, whether its own type-list mp_list, or standard type-lists such as std::tuple and std::variant, or user-defined type-lists. * Mp11 works with any meta-function, such as C++11 or Boost type-traits, or user-defined type-traits. Mp11 can be found here: * Documentation: https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html * Source code: https://github.com/pdimov/mp11 [1] http://www.boost.org/community/review_schedule.html [2] http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html [3] http://pdimov.com/cpp2/simple_cxx11_metaprogramming_2.html

1 0

CMake followup
by Peter Dimov 29 Jun '17

29 Jun '17

In a previous post I identified several scenarios for CMake support, where number one was 1. The user installs a Boost release as usual with `b2 install`, which makes the installation visible to CMake and usable via find_package(boost_libname). For this, I said "The changes to the `b2 install` procedure significantly exceed my bjam-fu however, so if we decide to proceed with this - and I don't see how we could claim CMake support in a meaningful way without it - the interested parties would need to figure out a way to make that happen." but I lied. (Well, not entirely, I had a lot of help.) Here https://github.com/pdimov/boost-cmake-demo is a proof-of-concept implementation that more or less works for our beloved test case of Boost.System. To test (the instructions are for Windows, where I tested), clone the repo, do b2 headers b2 --build-type=complete install as usual, then b2 cmake//install variant=debug,release link=static,shared runtime-link=shared (or whatever combination of options you prefer.) This should install -config.cmake files into $prefix/libs/cmake. Then, in a CMakeLists.txt, cmake_minimum_required(VERSION 3.5) project(cmake_demo CXX) #set(BOOST_BUILD_VARIANT RELEASE) #set(BOOST_LINK_TYPE SHARED) #set(BOOST_RUNTIME_LINK STATIC) find_package(boost_core 1.63.0) find_package(boost_system 1.63.0) # disable autolink globally # could also do it per-target add_definitions(-DBOOST_ALL_NO_LIB=1) # sample program add_executable(cmake_demo cmake_demo.cpp) target_link_libraries(cmake_demo boost::core boost::system) or similar. Ideally, cmake//install would be integrated into the install target (and cmake//stage into stage, respectively.)

1 0

[iterator][utility] Move utility/next_prior.hpp to Iterator module?
by Michel Morin 29 Jun '17

29 Jun '17

Andrzej Krzemienski wrote: >> Do you mean coupling of Boost.Iterator and Boost.Range? I think that would >> be fine, since Boost.Range already couples with Boost.Iterator. >> Boost.Range's `boost::distance` should call Boost.Iterator's >> `boost::distance`. >> > > I meant `next()` and `prior()` that are located in Utility: > http://www.boost.org/doc/libs/1_64_0/libs/utility/utility.htm Ah ok, got it. I think it would be better to move utility/next_prior.hpp to the Boost.Iterator module. After the move, the Boost.Iterator module will have: - include/boost/iterator/next_prior.hpp * Contains the actual code for `next` and `prior`. (Personally, I'd like to add `boost::prev` as a synonym of `boost::prior`.) - include/boost/utility/next_prior.hpp * Just includes <boost/iterator/next_prior.hpp>. This is how utility/declval.hpp was moved to the Boost.TypeTraits module. Regards, Michel

1 0

[beast] Formal "review" branch frozen
by Vinnie Falco 29 Jun '17

29 Jun '17

The "review" branch of Beast is now available and frozen for modifications. It contains the snapshot of the repository which will undergo the Boost formal review starting on July 1 and lasting for 10 days. Currently the review branch is even with the master branch, at version 70. The review branch repository is here: https://github.com/vinniefalco/Beast/tree/review The review documentation snapshot: http://vinniefalco.github.io/stage/beast/review/ Autobahn WebSocket Implementation Test Report: http://vinniefalco.github.io/autobahn/index.html Beast is a C++ header-only library serving as a foundation for writing interoperable networking libraries by providing low-level HTTP/1, WebSocket, and networking protocolvocabulary types and algorithms using the consistent asynchronous model of Boost.Asio. Beast empowers users to create their own libraries, clients, and servers using HTTP/1 and WebSocket. Code will be easier and faster to implement, understand, and maintain, because Beast takes care of the low-level protocol details. Please don't forget to "star" the repository on GitHub, the increased exposure will vitalize Beast and Boost with the new generation of programmers! Thanks! -- Follow me on Github: https://github.com/vinniefalco

1 0