Ищу http сервер для интеграции его в С++ приложение. Требования следующие:

многопоточность
возможность асинхронного ответа
поддержка https
OS: windows

желательно с современным удобным интерфесом (лямбды, смартпоинтеры и т.д.). Удобство разработки важнее скорости работы самого сервера.
Посоветуйте, кто чем пользуется для плюсов?

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

S>Посоветуйте, кто чем пользуется для плюсов?
pion как проверенная временем имплементация
restbed как современная C++11 имплементация, правда лицензия AGPL

cpp-netlib не брать ни в коем случае, просто бракованая вещь.

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


S>Посоветуйте, кто чем пользуется для плюсов?

http://cpp-netlib.org/ , всем перечисленным требованиям удовлетворяет. Единственный минус для виндовой разработки — зависимость от OpenSSL для поддержки https, что периодически приводит к геморрою со сборкой в некоторых ситуациях, но это проблемы OpenSSL, а не netlib, можно использовать пребилд-библиотеки OpenSSL, тогда проблем нет.

Конкретно по функциональности: пример простого http-сервера — http://cpp-netlib.org/0.12.0/examples/http/hello_world_server.html, реализация http-сервера с https — https://github.com/cpp-netlib/cpp-netlib/blob/0.11-devel/libs/network/example/http/ssl/ssl_server.cpp

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

S>возможность асинхронного ответа

Что имеется ввиду? http — синхронный протокол, под асинхронностью тут разные люди разное имеют ввиду. Для кого-то это асинхронный api, для кого-то это comet.

S>Посоветуйте, кто чем пользуется для плюсов?

Зависит от того что тебе нужно, какие возможности протокола должны быть реализованы
Я лично использьую libmicrohttpd — там хорошая поддержка протокола, но нет сжатия и вроде еще каких-то мелочей. cpp-netlib вроде как не поддерживал chunked transfer encoding. В общем, все зависит от того что тебе нужно. Погугли(погитхабь) c++ embedded http server.

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

S>Ищу http сервер для интеграции его в С++ приложение.
...
S>желательно с современным удобным интерфесом (лямбды, смартпоинтеры и т.д.). Удобство разработки важнее скорости работы самого сервера.
S>Посоветуйте, кто чем пользуется для плюсов?

Посмотри casablanca, Poco.

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

S>Посоветуйте, кто чем пользуется для плюсов?

На Reddit/cpp не так давно было похожее обсуждение: https://www.reddit.com/r/cpp/comments/4o5zdm/a_good_c_or_c_honestly_so_long_as_it_works_http/

S>желательно с современным удобным интерфесом (лямбды, смартпоинтеры и т.д.). Удобство разработки важнее скорости работы самого сервера.
S>Посоветуйте, кто чем пользуется для плюсов?

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

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

A>cpp-netlib не брать ни в коем случае, просто бракованая вещь.

А не могли бы Вы поделиться подробностями на эту тему? Использовал неоднократно, все было замечательно. Подозреваю, что Ваши сведения могли устареть, за последние пару лет библиотека радикально улучшилась, Вы имеете в виду последние версии?

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

S>Удобство разработки важнее скорости работы самого сервера
Qt-шный сервер тюфяк, следовательно:

— С++11
— сигнал-слотовое взаимодействие
— потоки вообще не проблема ибо сигнал-слоты рулят
— удобство разработки наидеальнейшее

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

J>А не могли бы Вы поделиться подробностями на эту тему? Использовал неоднократно, все было замечательно. Подозреваю, что Ваши сведения могли устареть, за последние пару лет библиотека радикально улучшилась, Вы имеете в виду последние версии?
хм, я попробовал "работать" с этой библиотекой года три назад, и мне прямо с ходу встретилось несколько детских дефектов ( вроде некорректного URL-decode и что-то ещё с парсингом HTTP ), после которых мне резко расхотелось с ней работать. Может конечно за 3 года и улучшилось что-то, но уже давно есть проверенные решения ( тот же pion ).

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

A>хм, я попробовал "работать" с этой библиотекой года три назад, и мне прямо с ходу встретилось несколько детских дефектов ( вроде некорректного URL-decode и что-то ещё с парсингом HTTP ), после которых мне резко расхотелось с ней работать. Может конечно за 3 года и улучшилось что-то, но уже давно есть проверенные решения ( тот же pion ).

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

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

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

S>>Удобство разработки важнее скорости работы самого сервера
__>Qt-шный сервер тюфяк, следовательно:
__>

__>- С++11
__>- сигнал-слотовое взаимодействие
__>- потоки вообще не проблема ибо сигнал-слоты рулят
__>- удобство разработки наидеальнейшее
__>

Спасибо, интересно. Попробую поковырять.
А как он по производительности?

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

__>>Qt-шный сервер тюфяк
SaZ>А как он по производительности?

А вот фиг знает, там где я его использовал нагрузки были минимальны.

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

J>Но сейчас это — очень качественно, на мой взгляд, сделанная библиотека, постоянно ее использую.

В чем это "качество" выражается, можно узнать?

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

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

__>>>Qt-шный сервер тюфяк
SaZ>>А как он по производительности?

__>А вот фиг знает, там где я его использовал нагрузки были минимальны.

Я просто как-то делал Qt обвязку поверх fastcgi. Но у нас тоже не было необходимости в высокой производительности.

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

CK>В чем это "качество" выражается, можно узнать?

Хороший С++ плюс стабильная работа (я, правда, использую клиент в основном, а не сервер, получается писать очень производительных "пауков").