Здравствуйте, smeeld, Вы писали:
S>Здравствуйте, Аноним, Вы писали:
А>>Посоветуйте, пожалуйста, http клиент для c++, libcurl не предлагать S>Самому написать делов на пару часов.
-1, полноценный клиент писать очень сложно, RFC большой
+1, для очень небольшого подмножества HTTP — всё просто
Здравствуйте, Abyx, Вы писали:
S>>Самому написать делов на пару часов. A>-1, полноценный клиент писать очень сложно, RFC большой
Что там сложного? Начинать с основных компонентов, и с течением времени
добавлять поддержку всех остальных составляющих компонентов протокола из rfc.
Не криптография жеж.
Здравствуйте, smeeld, Вы писали:
S>Не криптография жеж.
А вы почитайте, к примеру, как реализована авторизация NTLM (через которую многие корпоративные прокси работают). Там и криптография, и connection: keepalive обязательно к реализации. А ежели еще, не приведи аллах, захочется HTTPS, так гораздо проще будет все-таки взять libcurl.
Здравствуйте, Хреннос, Вы писали:
S>>Не криптография жеж.
Х>А вы почитайте, к примеру, как реализована авторизация NTLM (через которую многие корпоративные прокси работают). Там и криптография, и connection: keepalive обязательно к реализации. А ежели еще, не приведи аллах, захочется HTTPS, так гораздо проще будет все-таки взять libcurl.
эм... а что такого в https? просто меняешь везде socket на ssl_socket, и добавляешь handshake.
по крайней мере в ASIO так
Здравствуйте, Хреннос, Вы писали:
Х>Здравствуйте, smeeld, Вы писали:
Х>А вы почитайте, к примеру, как реализована авторизация NTLM (через которую многие корпоративные прокси работают.
Класс connection, по одному на каждое соединение, реализующий конечный автомат. И поток реактор, асинхроный, занимающийся отправками/приёмами и
ведающий очередью.
> Там и криптография, и connection: keepalive обязательно к реализации. А ежели еще, не приведи аллах, захочется HTTPS
Говоря про криптографию, имелось ввиду разработку иных алгоритмов, а не использование существующих.
Здравствуйте, smeeld, Вы писали:
S>Что там сложного? Начинать с основных компонентов, и с течением времени S>добавлять поддержку всех остальных составляющих компонентов протокола из rfc.
А ты почитай сам RFC.
Нужно в реальности сразу же иметь:
1) Редиректы.
2) Keepalive.
3) Multipart. К примеру, тот же банальный Гугл работает только через них.
S>Не криптография жеж.
Криптография существенно проще.
Здравствуйте, Аноним, Вы писали:
А>Посоветуйте, пожалуйста, http клиент для c++, libcurl не предлагать
А таки лучше libcurl найти что-то сложно. У неё, конечно, интерфейс не самый приятный, но зато она работает.
Здравствуйте, Cyberax, Вы писали:
C>Нужно в реальности сразу же иметь: C>1) Редиректы.
Выкусываешь из заголовков директиву: есть
переводишь коннектион в соответствующее состояние,
нет-и не надо. C>2) Keepalive.
Очередь запросов. С этим keep-alive не всё так просто только для серверов,
потому что клиенты ведут себя не добросовестно.
Например, игрался с своим http серваком, и смотрел по отчётам как ведут себя клиенты.
Например, при отдаче html, в котором есть 20 картинок, firefox сначала честно
первые две/три запрашивает в рамках одного соединения, потом вдруг начинает плодить
ещё с десяток соединений и остальные картинки запрашивает через них. Но
самое плохое то, что fiefox сам эти соединения не закрывал, ждал каких-то ещё
данных с сервера, хотя весь прописанный в Content-Length объём был передан.
Настройки keep-alive уровня ОС с setsockopt и через sysctl почему-то не работали, приходилось прокручивать
очередь кондидатов на отсоединение, и, по истечению счётчика, закрывать сокет.
И вобще существующие клиенты, походу, все реализованы криво, всё бремя следования
протоколу ложиться на сервер.
C>3) Multipart. К примеру, тот же банальный Гугл работает только через них.
Пара дополнительных заголовков с небольшим усложнением логики передачи на сервер.
C>Криптография существенно проще.
Как одна из сложнейших разделов математики может быть проще http?
Здравствуйте, smeeld, Вы писали:
C>>1) Редиректы. S>Выкусываешь из заголовков директиву: есть S>переводишь коннектион в соответствующее состояние, S>нет-и не надо.
Ну-ну.
C>>2) Keepalive. S>Очередь запросов. С этим keep-alive не всё так просто только для серверов, S>потому что клиенты ведут себя не добросовестно.
И?
C>>3) Multipart. К примеру, тот же банальный Гугл работает только через них. S>Пара дополнительных заголовков с небольшим усложнением логики передачи на сервер.
Ну-ну.
В общем, если правильно реализовать всё — получится не сильно меньше кода, чем в libcurl. И это точно будет не занятие на 15 минут.
C>>Криптография существенно проще. S>Как одна из сложнейших разделов математики может быть проще http?
А вот так. В криптографии нет ничего сложного для понимания.
http? C>А вот так. В криптографии нет ничего сложного для понимания.
Для понимания вообще ничего сложного нет. Если один чел что-то
сумел придумать, то другой среднестатистический чел понять это точно сможет.
Но говорил про именно изобретение чего нового. А то вон опенбсдишники
зазывают криптографистов, для изобретения новых алгоритмов, кому такое слабо?
Здравствуйте, PM, Вы писали:
PM>Здравствуйте, Аноним, Вы писали:
А>>Посоветуйте, пожалуйста, http клиент для c++, libcurl не предлагать
PM>Зависит от требований к полноте реализации HTTP — своё, Urdl (от автора Boost.Asio), Pion, POCO
PM>Еще можно почитать про проект HTTP сервера для Google Summer of Code 2014
Здравствуйте, Sanik, Вы писали:
S>>>http://cpp-netlib.org/
A>>это сырое говно.
S>Бывает. Моргу предположить, что и libcurl не сразу стал стабильным. S>А так под требования вопроса вроде подходит
Емнип, cpp-netlib создана в 2009 или 2010 году. Когда-то я хотел использовать ее в одоном проекте, но вовремя передумал С тех пор за развитем cpp-netlib не сильно слежу, но не рекомендовал бы ее, хоть за эти несколько лет она пару раз и подвергалась кардинальной переработке. На мой взгляд, очень уж она переусложнена. Начальная версия вообще, классический образец стиля "укушен Александреску" С тех пор автор наступил на все возможные грабли шаблонов, набрался опыта, ушел работать в гугл и похоже подзабросил ее.
Здравствуйте, Sanik, Вы писали:
S>Pion трудно назвать клиентом.
Да, но в ней есть почти всё, чтобы клиента таки создать — парсер HTTP, поддержка SSL. При необходимости можно добавить обработку редиректов, gzip deflate (например с помощью Boost.Iostreams) и отладить всё это
Автору темы libcurl чем-то не подходит, так что это всего лишь одна из альтернатив.
