RESTinio -- это header-only, кросс-платформенный инструмент для встраивания HTTP/Websocket в С++ приложение. Он использует standalone версию ASIO Главная задача -- упростить асинхронную обработку запросов. Чтобы, грубо говоря, обработчик спокойно мог потратить 15 секунд на формирование ответа, но это бы не влияло на параллельные запросы.

Библиотека распространяется под BSD-3-CLAUSE лицензией. Мы говорим, что она находится в состоянии beta-версии, т.к. не уверены, что ее API в достаточной степени стабилизировался и не претерпит ломающих изменений в будущем. Но сама реализация достаточно стабильна (например, на RESTinio было сделано одно из решений для Mail.ru-шного HighloadCup-а, которое заняло 41-е место в финале конкурса).

Вот как будет выглядеть простейший http-сервер, который отвечает на все запросы hello-world сообщением:

#include <iostream>
#include <restinio/all.hpp>

int main()
{
  restinio::run(
    restinio::on_this_thread() // Run server on this thread.
      .port(8080)
      .address("localhost")
      .request_handler([](auto req) {
        return req->create_response().set_body("Hello, World!").done();
      }));

  return 0;
}

В данном примере обработчик запросов предельно прост, но, конечно, RESTinio дает доступ к о всем параметрам запроса, что позволяет делать более сложные обработчики.

Возможности:

• Асинхронная обработка запросов. В случаях, когда данные для ответа на запрос не могут быть получены сразу (или почти сразу), то можно сохранить хэндл запроса для дальнейшей обработки (например, в другом контексте исполнения) и вернуться к этому запросу, когда все данные будут готовы.
  
• HTTP pipelining. Хорошо работает в связке с асинхронной обработкой запросов.
  
• Контроль за таймаутами. *RESTinio* может помочь в обработке “плохих” соединений, например из которых приходит "GET /", а затем они просто висят.
  
• Построители ответов. Например, если нужно тело chunked-encoding, то в *RESTinio* есть и такой билдер.
  
• Поддержка TLS (HTTPS).
  
• Базовая поддержка websocket. При помощи restinio::websocket::basic::upgrade() можно начать websocket сессию используя соединение, в котором был получен исходный upgrade-запрос.
  
• Может быть запущен на стороннем asio::io_context. RESTinio отделен от контекста исполнения, что, например, позволяет запустить 2 сервера используя один asio::io_context или встраивать RESTinio в существующее приложение построенное на ASIO и для этого не потребуется отдельный io_context.
  
• Некоторые настройки для оптимизации. Можно задать дополнительные опции для акцептора и сокета. Если RESTinio работает на пуле, то можно задать чтобы соединения принимались параллельно и/или создание внутренних объектов для работы с соединением создавались отдельно, это позволит быстрее принимать новые соединения.

Репозиторий проекта: https://bitbucket.org/sobjectizerteam/restinio-0.3

Взгляд со стороны, пожелания, предложения и конструктивная критика приветствуются!

Здравствуйте, so5team, Вы писали:

S>RESTinio -- это header-only, кросс-платформенный инструмент для встраивания HTTP/Websocket в С++ приложение.

1. Каково ваше позиционирование фреймворка? Какова его ниша? Очевидно там где нужен максимум производительности, там будет голый epoll. В плане скорости разработки есть, например, Go обойти который на С++ мне представляется нереальным и который в сетевой части обеспечит такое же быстродействие как и ваш фреймворк.
2. Какой ваш опыт в разработке серверов? Почему вы считаете, что достаточно глубоко понимаете данную специфику чтобы написать фреймворк? Например, бегло посмотрев я не нашел какой механизм вы предлагаете для защиты от медленных клиентов.
3. Смотрели ли вы другие плюсовые фреймворки, например, https://github.com/ipkn/crow? Чем ваше решение лучше других?

Здравствуйте, MTD, Вы писали:

MTD>1. Каково ваше позиционирование фреймворка? Какова его ниша? Очевидно там где нужен максимум производительности, там будет голый epoll. В плане скорости разработки есть, например, Go обойти который на С++ мне представляется нереальным и который в сетевой части обеспечит такое же быстродействие как и ваш фреймворк.

Сначала немного о терминах, мы не позиционируем restinio как framework, это именно что библиотека, которая за рамками своей задачи не навязывает пользователю каких-то best practice правил. Так для меня фреймворк это что-то ближе к Poco или ACE, например.

На счет производительности, да, понятно что частное отшлифованное под конкретную задачу решение будет лучше чем созданное с помощью стандартных инструментов, но это если есть такая возможность. Но иногда можно пожертвовать максимальной производительностью, и потратить меньше времени и сил получить просто хорошую производительность.

В каких же случаях. Например, кейс который у нас и случался не раз: есть С++ приложение, которое уже есть как таковое, либо в силу каких-то причин будет разрабатывается на C++, и к нему требуется выставить REST API. То для такой задачи вполне подойдет restinio.

MTD>2. Какой ваш опыт в разработке серверов? Почему вы считаете, что достаточно глубоко понимаете данную специфику чтобы написать фреймворк? Например, бегло посмотрев я не нашел какой механизм вы предлагаете для защиты от медленных клиентов.

Опыт такой: периодически сталкиваемся (раз в год примерно) с задачей организовать REST API для старых C++ных систем или в новой системе REST API закладывается изначально. Мы пробовали разные библиотеки для этого, но в прод чаще всего это оказывался Poco. В первую очередь нам нужна была именно асинхронная обработка запросов (в Poco ее нет). Если заглянуть на более чем пару лет назад, то только restbed давал такую возмоность и был при этом зрелым инструментом, но он платный. Т.о. сами не раз выступали в роли пользователя и прочуствовали что таким пользователям как мы надо. И вот в начале года, когда очередной раз замаячила небходимость прикрутить к одной системе REST API, то мы собрали все требования к либе, с помощью которой это можно было бы сделать, и начали искать. И оказалось, что идеального кандидата не было, а т.к. сколько уже можно "брать что дают", то начали делать свой инструмент для себя исходя из своего опыта как пользователи подобного фрэймворка.

В restinio есть возможность контролировать время выполнения операций с соединением:

• Чтение запроса. Например, на получение очередного запроса отводится 5 секунд, тогда соединения который будут присылать на паре байт каждую секунду будут закрываться через 5 секунд.
  
• Запись ответа. Например, на отправку данных отводится 1 секунда, тогда если операция асинхронной записи в сокет не завершится в течении 1 секунду, то такое соединение будет также закрыто.

MTD>3. Смотрели ли вы другие плюсовые фреймворки, например, https://github.com/ipkn/crow? Чем ваше решение лучше других?

Да смотрели и под список своих хотелок не один не попал. CROW требует определится с ответом сразу в обработчике. Т.е. не получится просто принять запрос, мол да — будем на него отвечать, но попозже, а пока можно продолжить принимать другие запросы и не держать эту нить.

Здравствуйте, so5team, Вы писали:

S>В restinio есть возможность контролировать время выполнения операций с соединением:

S>

S>
• Чтение запроса. Например, на получение очередного запроса отводится 5 секунд, тогда соединения который будут присылать на паре байт каждую секунду будут закрываться через 5 секунд.
  S>
• Запись ответа. Например, на отправку данных отводится 1 секунда, тогда если операция асинхронной записи в сокет не завершится в течении 1 секунду, то такое соединение будет также закрыто.
  S>

Это не совсем то, что требуется в продакшене. Во-первых, не понятно откуда такие константы, во-вторых, это все равно не позволит отличить честного пользователя с модемом от злоумышленника. И это только одна из множества потенциальных проблем, судя по тому, что у вас нет достаточного опыта в этом, предполагается отлаживаться на реальных пользователях, а это годы и репутация. Почему бы просто не взять nginx — отлаженный сервер, который уже умеет все что нужно и делает это хорошо, надо только написать конфигурацию. Далее, пусть он сам работает с https, защищает от всяких нежданчиков и перенаправляет http трафик на нужный порт, а там уже пусть будет ваш сервер. В принципе удобный роутинг с асинхронными обработчиками — good enough, тут я вижу место для вашего фреймворка (я все-таки уверен, что это фреймворк, так как навязывает определенные правила).

Здравствуйте, MTD, Вы писали:

MTD>Это не совсем то, что требуется в продакшене.

И что же вам требуется в продакшене? И в каком именно продакшене?

MTD>Во-первых, не понятно откуда такие константы,

Из параметров, задаваемых пользователем.

MTD>во-вторых, это все равно не позволит отличить честного пользователя с модемом от злоумышленника.

Подскажите нужный вам способ.

MTD>И это только одна из множества потенциальных проблем,

Огласите весь список, пожалуйста.

MTD>судя по тому, что у вас нет достаточного опыта в этом, предполагается отлаживаться на реальных пользователях, а это годы и репутация.

Спасибо за заботу, но можно ли высказывать свои мысли более конструктивно?

Здравствуйте, so5team, Вы писали:

MTD>>Это не совсем то, что требуется в продакшене.

S>И что же вам требуется в продакшене? И в каком именно продакшене?

Поэтому я и говорю — не надо велосипедить там, где люди годами опыт нарабатывают — с наскока получится хуже. Сначала, хотел написать развернутый ответ, потом подумал, что у меня тоже опыта маловато, поэтому либо наймите тех людей, кто уже все знает, либо годами набивайте свои шишки, тренироваться на кошках пользователях, как-то не очень правильно.

MTD>>Во-первых, не понятно откуда такие константы,

S>Из параметров, задаваемых пользователем.

Где они? Как называются?

MTD>>И это только одна из множества потенциальных проблем,

S>Огласите весь список, пожалуйста.

На полноту не претендую, могу сказать только, что даже исходя из своего опыта понимаю, что ваша работа моих скромных требований не удовлетворяет.

MTD>>судя по тому, что у вас нет достаточного опыта в этом, предполагается отлаживаться на реальных пользователях, а это годы и репутация.

S>Спасибо за заботу, но можно ли высказывать свои мысли более конструктивно?

Я уже достаточно конструктивно высказался, можно послушать, а можно обидеться и жаловаться, что пользователь дурак, не оценил души порывов.

Здравствуйте, MTD, Вы писали:

MTD>>>Это не совсем то, что требуется в продакшене.

S>>И что же вам требуется в продакшене? И в каком именно продакшене?

MTD>Поэтому я и говорю — не надо велосипедить там, где люди годами опыт нарабатывают — с наскока получится хуже.

Так чего же вам не хватает в продакшене? Вы же сказали, что не хватает, так чего именно?

MTD>>>Во-первых, не понятно откуда такие константы,

S>>Из параметров, задаваемых пользователем.

MTD>Где они? Как называются?

В документации об этом написано.

MTD>>>И это только одна из множества потенциальных проблем,

S>>Огласите весь список, пожалуйста.

MTD>На полноту не претендую, могу сказать только, что даже исходя из своего опыта понимаю, что ваша работа моих скромных требований не удовлетворяет.

Ну т.е. список, может быть и существует у вас в голове, но озвучить вы его не можете. ok.jpg

S>>Спасибо за заботу, но можно ли высказывать свои мысли более конструктивно?

MTD>Я уже достаточно конструктивно высказался

Это вам так показалось. Пока пользы от ваших высказываний ноль целых ноль десятых.

Здравствуйте, MTD, Вы писали:

MTD>Я уже достаточно конструктивно высказался, можно послушать, а можно обидеться и жаловаться, что пользователь дурак, не оценил души порывов.

Братишка, со стороны выглядит что именно ты обиделся (непонятно на что, кстати) и жалуешься. Начиная прямо с первого твоего сообщения в этой теме. И нет, конструктива от тебя ещё не было.

Здравствуйте, so5team, Вы писали:

MTD>>Я уже достаточно конструктивно высказался

S>Это вам так показалось. Пока пользы от ваших высказываний ноль целых ноль десятых.

забей. только время потеряешь

Здравствуйте, antropolog, Вы писали:

A>Братишка, со стороны выглядит что именно ты обиделся (непонятно на что, кстати) и жалуешься. Начиная прямо с первого твоего сообщения в этой теме.

Чтобы не съезжать на пустое, допустим я обиделся, ок. Переходим к сути.

A>И нет, конструктива от тебя ещё не было.

Конструктив от меня был с самого первого сообщения — я задал конкретные вопросы, которые задает себе любой разработчик при выборе инструмента. Ответы дали мне понять, что у авторов нет опыта разработки и поддержки серверов которые бы обслуживали самых разных клиентов 7 * 24 * 365. Я ошибаюсь? Ну покажите мне ссылку, где автор написал, что такой опыт у него есть. Тебя бы это не насторожило? Далее, предложил идею для позиционирования — вылизанный и стабильный nginx принимает соединения, расшифровывает https, а на их фреймворке написан сервер с асинхронными обработчиками и удобным роутингом, на который nginx перенаправляет трафик — вполне себе неплохое вырисовывается решение. Это не конкретика? Ну ок.

Здравствуйте, so5team, Вы писали:

S>Так чего же вам не хватает в продакшене? Вы же сказали, что не хватает, так чего именно?

На многие ответы можно получить ответ, если вежливо интересоваться, а не заявлять, что конкретики 0. Да, даже если и ноль, с людьми надо уметь работать, а если тебе это не приятно и не хочется — ты занялся не тем. Конкретно мне лень сейчас тебе все расписывать — это труд, а тут придется работать даже не за спасибо, а за слабо.

MTD>>Где они? Как называются?

S>В документации об этом написано.

Это тоже хороший сигнал потенциальным пользователям — автору лень дать названия которые он знает, ты должен сам лопатить документацию, при чем это не ты к нему пришел, а он пришел сделать себе рекламу — делает успешно.

S>Ну т.е. список, может быть и существует у вас в голове, но озвучить вы его не можете.

Могу, но не хочу, попросил бы вежливо — получил бы вежливый ответ.

S>ok.jpg

Вы все еще не созрели использовать его фреймворк? Напрасно, смотрите как автор мастерски убеждает.

S>Это вам так показалось. Пока пользы от ваших высказываний ноль целых ноль десятых.

Казалось бы за столько лет человек мог бы задаться вопросом, почему его велосипеды никто не использует, но нет, автор твердо убежден — пользователи не те, с ним же все ок.

Здравствуйте, MTD, Вы писали:

MTD>Конструктив от меня был с самого первого сообщения — я задал конкретные вопросы, которые задает себе любой разработчик при выборе инструмента. Ответы дали мне понять, что у авторов нет опыта разработки и поддержки серверов которые бы обслуживали самых разных клиентов 7 * 24 * 365. Я ошибаюсь? Ну покажите мне ссылку, где автор написал, что такой опыт у него есть. Тебя бы это не насторожило? Далее, предложил идею для позиционирования — вылизанный и стабильный nginx принимает соединения, расшифровывает https, а на их фреймворке написан сервер с асинхронными обработчиками и удобным роутингом, на который nginx перенаправляет трафик — вполне себе неплохое вырисовывается решение. Это не конкретика? Ну ок.

Как раз авторы на РСДН давно и всем известны, их опыт тоже.
Никаких же конкретных вещей про С++ библиотеку, выполняющую указанные функции, тобой сказано не было.

Здравствуйте, MTD, Вы писали:

MTD>Я ошибаюсь?

Да.

MTD>Ну покажите мне ссылку, где автор написал, что такой опыт у него есть.

Покажите ссылку, где бы авторы сказали, что у них такого опыта нет.

Ну а если совсем уж сорвать покровы, то мы бросились делать RESTinio прочитав всего половину какой-то книжки по C++ и лишь бегло просмотрев описание HTTP 1.1 в русскоязычной Wikipedia. Мы пытались это старательно скрывать, но на поверку это оказался секрет Полишинеля. Посыпем себе головы пеплом и пойдем убъемся апстену.

MTD>Далее, предложил идею для позиционирования — вылизанный и стабильный nginx принимает соединения, расшифровывает https, а на их фреймворке написан сервер с асинхронными обработчиками и удобным роутингом, на который nginx перенаправляет трафик — вполне себе неплохое вырисовывается решение.

Очевидное решение с использованием reverse proxy. Дальше-то что? Ну вот перенаправил nginx запрос на приложение, что и как приложение должно с этим делать? Ну и какая разница приложению, стоит перед ним reverse proxy или нет?

Ну и это если не брать такую большую тему, как микросервисная архитектура с такими схемами развертывания, когда большинство микросервисов (написанных на разных языках, в том числе и на C++) вообще наружу никуда не смотрит.

И уж совсем не стоит заводить разговор про направление IoT, где могут быть локальные сети умных устройств, требующих взаимодействие по каким-то протоколам поверх HTTP (тот же REST, к примеру). И нет возможности поставить на дохлом умном устройстве еще и nginx для того, чтобы он работал как reverse proxy.

Здравствуйте, MTD, Вы писали:

MTD>Конструктив от меня был с самого первого сообщения — я задал конкретные вопросы, которые задает себе любой разработчик при выборе инструмента. Ответы дали мне понять, что у авторов нет опыта разработки и поддержки серверов которые бы обслуживали самых разных клиентов 7 * 24 * 365. Я ошибаюсь?

непонятно к чему ты вообще вопрос этот задал. Ну т.е. автор прям вот в стартовом сообщении написал, как он позиционирует эту библиотеку

кросс-платформенный инструмент для встраивания HTTP/Websocket в С++ приложение. Он использует standalone версию ASIO Главная задача -- упростить асинхронную обработку запросов

т.е. это альтернатива restbed, cpprestsdk, pion, cppnetlib и ещё доброй дюжины embeddable http-серверов для C++. К чему здесь вопрос о запредельном перформансе и возможности работать 24x7 ( для нагруженных серверов это вообще вопрос к инфраструктуре, а не к коду )?

MTD>Ну покажите мне ссылку, где автор написал, что такой опыт у него есть. Тебя бы это не насторожило?

меня бы это не насторожило, потому что исходя из позиционирования библиотеки и существующих альтернатив меня бы интересовали совершенно другие вопросы, нежели сколько библиотека выдаёт rps по сравнению с голым epoll

MTD>Далее, предложил идею для позиционирования — вылизанный и стабильный nginx принимает соединения, расшифровывает https, а на их фреймворке написан сервер с асинхронными обработчиками и удобным роутингом, на который nginx перенаправляет трафик — вполне себе неплохое вырисовывается решение. Это не конкретика? Ну ок.

идеи о позиционировании не нужны, т.к. позиционирование уже есть и явно озвучено топикстартером в первых же двух предложенях.

Здравствуйте, MTD, Вы писали:

S>>Так чего же вам не хватает в продакшене? Вы же сказали, что не хватает, так чего именно?

MTD>На многие ответы можно получить ответ, если вежливо интересоваться

Простите великодушно. Можем ли мы вас попросить описать, какие требования к HTTP/Websocket серверам вы предъявляете для использования в своем продакшен окружении? Опишите, пожалуйста, если сможете найти время и уделить внимание нашей скромной просьбе.

S>>Ну т.е. список, может быть и существует у вас в голове, но озвучить вы его не можете.

MTD>Могу, но не хочу, попросил бы вежливо — получил бы вежливый ответ.

Пожалуйста, огласите свой список. Мы приносим извинения за резкий тон в своих предыдущих высказываниях и просим принять во внимание тот факт, что данный список может быть интересен не только разработчикам RESTinio.

S>>Это вам так показалось. Пока пользы от ваших высказываний ноль целых ноль десятых.

MTD>Казалось бы за столько лет человек мог бы задаться вопросом, почему его велосипеды никто не использует, но нет, автор твердо убежден — пользователи не те, с ним же все ок.

Вы делаете ошибку предполагая, что у RESTinio всего один автор и предполагая, что общаетесь именно с тем человеком, которого подозреваете в авторстве.

Здравствуйте, Nuzhny, Вы писали:

N>Как раз авторы на РСДН давно и всем известны, их опыт тоже.

Мне тоже, я даже его блог временами читаю. Но чисто для понимания простой пример — специалист по криптографии, не факт, что шарит в 3Д. Еще раз — если я ошибаюсь и у авторов обширный опыт написания и поддержки серверов, которые работают 7*24*365 обслуживая самых разных клиентов, пусть покажет или хотя бы подтвердит, что такой опыт есть.

N>Никаких же конкретных вещей про С++ библиотеку, выполняющую указанные функции, тобой сказано не было.

Каких конкретных? Названия методов пообсуждать? Я спросил для примера как они с медленными клиентами предлагают работать. Вопрос конкретный?

Здравствуйте, so5team, Вы писали:

S>Простите великодушно.
S>Мы приносим извинения за резкий тон в своих предыдущих высказываниях

Ерничать не надо — не красиво.

S>>>Это вам так показалось. Пока пользы от ваших высказываний ноль целых ноль десятых.

S>Вы делаете ошибку предполагая, что у RESTinio всего один автор и предполагая, что общаетесь именно с тем человеком, которого подозреваете в авторстве.

Я такой ошибки не делаю:

Ответы дали мне понять, что у авторов нет опыта разработки и поддержки серверов которые бы обслуживали самых разных клиентов 7 * 24 * 365. Я ошибаюсь?

Но идеолог у всего этого один — если ты это не он, я бы на его месте с тобой не работал, а если это он — еще один велосипед в его копилку. Причем я его блог давно почитываю: CMake плохой, Mxx хороший и т.д., почему пользователи выбирают "плохое" вместо его "хорошего" ему очевидно. Можешь не верить, но я всерьез хотел в одном проекте использовать SObjectizer, прочел все статьи на хабре, написал хелло ворлд, но использовать не стал — я плохой, библиотека хорошая.

Здравствуйте, antropolog, Вы писали:

A>непонятно к чему ты вообще вопрос этот задал.

Вопросы задают чтобы получить ответ, мне было не понятно, я уточнил — получил обвинения в неконструктиве. Простите, даже не знаю какие реверансы делать, чтобы не задеть ничьих чувств.

A>т.е. это альтернатива restbed, cpprestsdk, pion, cppnetlib и ещё доброй дюжины embeddable http-серверов для C++.

И почему надо выбрать его?

A>К чему здесь вопрос о запредельном перформансе и

А где такой вопрос? Ткни пальцем, а то ощущение, что ты не мои посты комментируешь. Про турнир хай лоад, не я писал, а автор.

A>возможности работать 24x7

Мне не нравится, когда на меня тикеты заводят, хочу чтобы работало стабильно. Удивительно, да?

A>а не к коду )?

Ага, ошибки в коде и отсутствие поддержки нештатных ситуаций ни на что не влияют, ага.

MTD>>Ну покажите мне ссылку, где автор написал, что такой опыт у него есть. Тебя бы это не насторожило?

A>меня бы это не насторожило, потому что исходя из позиционирования библиотеки и существующих альтернатив меня бы интересовали совершенно другие вопросы,

А я если выбираю инструмент, то рассчитываю, что его писал человек который на этом собаку съел, а следовательно по определению сделает хорошо и точно лучше, чем я. Так, например, я не стал бы пользоваться криптобиблиотекой, если у автора нет лет 20 за плечами в этой области.

A>нежели сколько библиотека выдаёт rps по сравнению с голым epoll

Это твой тезис, не надо мне приписывать то, что я не говорил.

A>идеи о позиционировании не нужны

Ну тогда и удивляться нечему, что велосипеды пылятся.

Здравствуйте, MTD, Вы писали:

MTD>Ерничать не надо — не красиво.

В сухом остатке: у вас есть какой-то список хотелок и требований, но вы их не озвучите.

Ok. Мы сделаем вид, что не считаем вас дебиломтроллем-пустозвоном, что вы просто человек с тонкой душевной ориентацией, который не хочет на профильном ресурсе делиться своим опытом с коллегами из-за нанесенных вам оскорблений с нашей стороны. За оскорбления приносим свои извинения, это получилось случайно.

Спасибо за потраченное время, ваш фидбэк оказался бесполезным, как пользователь вы нам не интересны.

Здравствуйте, so5team, Вы писали:

MTD>>Я ошибаюсь?

S>Да.

Допускаю, переубедите меня.

MTD>>Ну покажите мне ссылку, где автор написал, что такой опыт у него есть.

S>Покажите ссылку, где бы авторы сказали, что у них такого опыта нет.

2. Какой ваш опыт в разработке серверов? Почему вы считаете, что достаточно глубоко понимаете данную специфику чтобы написать фреймворк?

Опыт такой: периодически сталкиваемся (раз в год примерно) с задачей организовать REST API для старых C++ных систем или в новой системе REST API закладывается изначально. Мы пробовали разные библиотеки для этого, но в прод чаще всего это оказывался Poco.

http://rsdn.org/forum/cpp.applied/6936918.1

Автор: so5team
Дата: 18.10.17

Ответ человека который имеет опыт выглядит так: пишем сервера более 15 лет, например: [идет список со ссылками, коротким описанием, перечислением архитектурных и технических решений, нагрузкой и т.д.]

S>Ну а если совсем уж сорвать покровы, то мы бросились делать RESTinio прочитав всего половину какой-то книжки по C++ и лишь бегло просмотрев описание HTTP 1.1 в русскоязычной Wikipedia.

Пока что у меня сложилось именно такое впечатление.

S>Мы пытались это старательно скрывать, но на поверку это оказался секрет Полишинеля. Посыпем себе головы пеплом и пойдем убъемся апстену.

Ерничать не красиво, если есть что сказать — можно просто дать конкретику, а это несерьезно, для человека который предлагает людям завязаться в своем коде на его решение.

S>Очевидное решение с использованием reverse proxy. Дальше-то что? Ну вот перенаправил nginx запрос на приложение, что и как приложение должно с этим делать?

Я же написал, тут простое решение с асинхронными обработчиками и удобным роутингом засияет.

S>Ну и какая разница приложению, стоит перед ним reverse proxy или нет?

Огромная. nginx написан людьми с большим опытом, там убраны все те грабли по которым вам только предстоит пройти.

S>И уж совсем не стоит заводить разговор про направление IoT, где могут быть локальные сети умных устройств, требующих взаимодействие по каким-то протоколам поверх HTTP (тот же REST, к примеру). И нет возможности поставить на дохлом умном устройстве еще и nginx для того, чтобы он работал как reverse proxy.

Есть мнение, что у вашего решения требования гораздо выше, чем у nginx. Ну и то, что на какой-то железке не будет С++ компилятора который умеет С++11 я прям уверен на 95% — снова ошибка позиционирования.