HTTP в C++ приложениях - C/C++. Прикладные вопросы

Еще раз уточню. Передо мной не стоит задача единоразово сделать какой-то HTTP запрос. Это в текущем приложении сделано (с помощью WinInet) — и благополучно сдано заказчику. Так есть опыт использования cURL.

Но! По ряду причин ни одно из решений, которые я использовал ранее, мне не нравятся.
Ключевые требования:
а) Кроссплатформенность. В разумных пределах. По крайней мере винда, линух, мак.
б) Продуманный С++ интерфейс, не слишком замороченный и без страшных compile-time наворотов — вдруг придется
портировать на убогую (в смысле хорошего наличия С++ компилятора) платформу
в) Удобный высокоуровневый интерфейс, не скрывающий тем не менее низкоуровневых деталей (escape hatches)
г) Возможность полноценной работы в асинхронном режиме со всеми вытекающими — прогресс, отмена на любой стадии итп
д) Поддержка HTTPS/прокси/кукисов — опционально
е) Не тянущее за собой не связанных с задачей библиотек (или тянущее по минимуму)

Я понимаю, что хочу многого

, но и решение ищется не на 1 день.
Возможно меня бы устроило что-то на базе ACE.

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

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

ST>>В общем, всё равно всё хорошо.
J>Неа (вредный я)... Это я должен на уровень сокетов спуститься. Если так то нафига мне вообще специальный HTTP класс? Я могу и руками по HTTP общаться, вот только геморно это. Да и как быть с тем же HTTPS? А с асинхронной отсылкой запроса или приемом респонз хидеров? А с резолвингом днс перед подключением, а с самим подключением? — то что ты показал будет работать только во время приема Response stream-а.
J>В общем полумеры не нужны, интересует ultimate solution

Осталось только сказать, что wxHTTP унаследован от wxSocketBase, у которого и есть перечисленные эвенты.

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

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

J>Еще раз уточню. Передо мной не стоит задача единоразово сделать какой-то HTTP запрос. Это в текущем приложении сделано (с помощью WinInet) — и благополучно сдано заказчику. Так есть опыт использования cURL.
А можно понтересоваться почему нельзя использовать libcurl? В ней есть все запрашиваемые функции. Имхо альтернатива только писать самому на сокетах

(ну, еще есть libwww, хотя мне она совсем не нравится)

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

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

J>>>Internet Explorer мне не нужен, явный оверкилл, мне просто GET запрос сделать надо.
O>>Ну так и послать GET и жлать ответа или прибить ожидание когда уже не надо ждать

J>В-первых не кроссплатформенно, как я уже уточнил. Но это не самое страшное.

J>Internet Explorer имеет кучу недостаков:
J>а) он может просто не стоять у пользователя

J>б) я завишу от его настроек — прокси, сертификаты итп. Понятно, что все настраивается, но это может затронуть другие приложения.
J>в) это ОВЕРКИЛЛ. мне не нужен броузер, мне нужно выполнить простой GET запрос с возможностью отследить прогресс и отменить в случае необходимости.
J>г) это не стандартный С++, а COM со всеми вытекающими.

J>Если бы мне нужен был IE я бы взял его и использовал бы, не создавая этого топика

Вы меня не поняли, я имел в виду "взять и самому послать GET напрямую", то есть ручками сформировать этот запрос и отправить его.

J>Все равно спасибо за высказанное мнение

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

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

J>>Еще раз уточню. Передо мной не стоит задача единоразово сделать какой-то HTTP запрос. Это в текущем приложении сделано (с помощью WinInet) — и благополучно сдано заказчику. Так есть опыт использования cURL.
C>А можно понтересоваться почему нельзя использовать libcurl? В ней есть все запрашиваемые функции. Имхо альтернатива только писать самому на сокетах

(ну, еще есть libwww, хотя мне она совсем не нравится)

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

, да и не С++. Из готовых врапперов юзал cURLpp, но тогда он был пожалуй сыроват, да и в целом оставил ощущение недоделанности.

Конечно можно плюнуть на все и написать свою либу (или свой враппер для cURL), но к необоснованному велосипедостроительству отношусь крайне отрицательно

. Да и — а вдруг повезет и найдется что-то готовое, юзают же что-то люди

, не верю что все сови врапперы пишут.

P.S. Насчет libwww солидарен — смотрел года два назад, впечатление — полное гуано

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

O>Вы меня не поняли, я имел в виду "взять и самому послать GET напрямую", то есть ручками сформировать этот запрос и отправить его.

А зачем вы используете CreateFile/fopen/fstream.open()/чтоещетам, а не работаете на прямую с файловой системой/секторами диска в машинных кодах/на ассемблере?

А если серьезно — слишком сложный HTTP протокол, чтобы его каждый раз ручками имплементить/плодить баги.

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

J>Да, наверное есть. Но тут тоже проблема — я буду вынужден таскать за собой (и покупать) QT. Сомневаюсь, что это библиотеку отделно от него можно использовать. Все равно спасибо — еще одна версия в копилку

В последних версия Qt, насколько мне известно, перестала быть кросс-платформенным GUI-фреймворком, а стала просто кросс-платформенным фреймворком — ребята из trolltech разделили все на набор независимых друг от друга библиотек. А кроме того, применимость для вашей задачи можно оценить, скачав GPL-версию — теперь она есть и под Windows.

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

С>В последних версия Qt, насколько мне известно, перестала быть кросс-платформенным GUI-фреймворком, а стала просто кросс-платформенным фреймворком — ребята из trolltech разделили все на набор независимых друг от друга библиотек. А кроме того, применимость для вашей задачи можно оценить, скачав GPL-версию — теперь она есть и под Windows.

Спасибо за информацию, посмотрю. Насчет задачи — я ниже в ветке написал

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

J>Да в общем-то на ней скорее всего и остановлюсь (в последнем проекте нельзя было использовать из соображений мимнимальности екзешника,
J>поэтому выбора не было — только WinInet). Но вот чего-то она мне не по вкусу

, да и не С++. Из готовых врапперов юзал cURLpp, но тогда он был пожалуй сыроват, да и в целом оставил ощущение недоделанности.
curlpp мне тоже не понравилась

J>Конечно можно плюнуть на все и написать свою либу (или свой враппер для cURL), но к необоснованному велосипедостроительству отношусь крайне отрицательно

. Да и — а вдруг повезет и найдется что-то готовое, юзают же что-то люди

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

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

C>Я в свое время остановился именно на этом варианте, то есть свой C++ враппер для libcurl, потому как ничего что бы меня устроило, не нашел. А вот к работе именно libcurl никаких серьезных нареканий у меня нет

Спасибо

. ну что ж, подождем может еще чего присоветует, а нет так — и правда займусь велосипедом

jedi wrote:

> Но! По ряду причин ни одно из решений, которые я использовал ранее, мне
> не нравятся.
Взгляни на всякий случай на libxml/nanohttp, вдруг понравится. Хотя, как я представляю, кроме того, что маленький размер
— никаких преимуществ перед libcurl нет.

Posted via RSDN NNTP Server 2.0

Мдя, очень печальные итоги опроса. ИМХО, очень четко проявились проблемы современного С++ — бесконечная удаленность от практического программирования. Посмотите в мир Java — подобный топик в их форуме вызвал бы смех: куча бесплатных библиотек, приятный выбор.

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

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

J>Мдя, очень печальные итоги опроса. ИМХО, очень четко проявились проблемы современного С++ — бесконечная удаленность от практического программирования. Посмотите в мир Java — подобный топик в их форуме вызвал бы смех: куча бесплатных библиотек, приятный выбор.
Позволю себе не согласиться. Практическое программирование в моем понимании все же программирование платное. А выбор платных библиотек для данной задачи весьма широк. В крайнем случае более-менее грамотный разработчик с этой задачей без особых проблем расправится за пару недель, что в принципе сравномо с ценой библиотеки. Хотя это только в данном конкретном случае. Обычно все же дешевле купить. Плюс нужно учитывать, что покупая библиотеку, одновременно получаешь и поддержку, то есть время вникания в нее сокращается, часто весьма значительно.

J>Из-за острой нехватки библиотек промышленного уровня решать задачи на С++ становится все труднее и труднее ... Печально это

Как это решение может стать труднее чем раньше?

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

эээ... кто здесь ?

Здравствуйте, Константин Л., Вы писали:

КЛ>можно посмотреть MSXML4::IXMLHTTPRequest/IServerXMLHTTPRequest2
КЛ>асинхронность есть, мониторинга прогресса нету

Мониторинг есть, см. XMLDOMDocumentEvents.