Здравствуйте, Denis, Вы писали:
D>5.1 не имеет редистрибьюта и требует последних систем(WinXP SP1, Win2003, Win2k SP3(4 забыл какой точно))
Вот тут MS как всегда привирает. В составе SOAP Toolkit 3.0 идет merge-модуль WinHTTP 5.1 который ставится и работает даже на NT4. Сам его уже довольно долго использую.
D>WinInet не умеет работать с сервисами... так что почти не жилец.
Здравствуйте, Flamer, Вы писали:
F>Вот понадобилась такая простенькая вещь:
F>1. Платформа — Windows. F>2. Класс для получения информации по HTTP F>3. Поддержка GET/POST F>4. Поддержка HTTP-прокси и авторизации через прокси F>5. Без использования высокоуровневых оберток типа CString и пр.
F>Вот думаю: изобретать или есть готовый на С/С++? В принципе, изобретено уже процентов 60, но терзают смутные сомнения, что все уже украдено до нас.
F>Размер — имеет большое значение
F>To moderator: я намеренно запостил в форум по С/С++, т.к. нужно именно код, на 99% написанный на С/С++.
F>Что подскажут уважаемые?
И не так плох WinInet. Я в HtmLayout его использую синхронно в отдельных потоках — эдакий resource pump. Пример описан в MSDN.
И вроде ничего так. Там есть плюс что он пользует централизованный cache и cookies storage.
Здравствуйте, Flamer, Вы писали:
F>Вот понадобилась такая простенькая вещь:
По просьбам трудящихся совсем сырые исходники того, что нужно было в первом посте... Никакой оптимизации, код сырой, все писалось за 3 часа на коленке. Сорри за объем кода. Итак:
Оговорюсь, что юзается один сторонний класс CBase64Coder. Его исходник пойдет отдельным постом в форум "Исходники".
1. Сразу про использование. Пока тестировал так (на Билдере):
Все замечания, пожелания, тухлые помидоры, усовершенствования, оптимизации и пр. — велкам. Оченно хочется довести до простенького ума.
З.Ы. Каюсь — соответствие отсылаемого запроса RFC не проверял. Да и POST-запрос не тестировал. Еще одна оговорка — URL, передаваемый в MakeRequest, не должен содержать unsafe-characters. Вроде все.
1. Платформа — Windows.
2. Класс для получения информации по HTTP
3. Поддержка GET/POST
4. Поддержка HTTP-прокси и авторизации через прокси
5. Без использования высокоуровневых оберток типа CString и пр.
Вот думаю: изобретать или есть готовый на С/С++? В принципе, изобретено уже процентов 60, но терзают смутные сомнения, что все уже украдено до нас.
Размер — имеет большое значение
To moderator: я намеренно запостил в форум по С/С++, т.к. нужно именно код, на 99% написанный на С/С++.
Здравствуйте, Flamer, Вы писали:
F>Вот понадобилась такая простенькая вещь:
F>1. Платформа — Windows. F>2. Класс для получения информации по HTTP F>3. Поддержка GET/POST F>4. Поддержка HTTP-прокси и авторизации через прокси F>5. Без использования высокоуровневых оберток типа CString и пр.
А чем WinInet плох?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Flamer, Вы писали:
F>>Вот понадобилась такая простенькая вещь:
F>>1. Платформа — Windows. F>>2. Класс для получения информации по HTTP F>>3. Поддержка GET/POST F>>4. Поддержка HTTP-прокси и авторизации через прокси F>>5. Без использования высокоуровневых оберток типа CString и пр.
IT>А чем WinInet плох?
Если синхронный инет — хреново, асинхронный — геморно. Есть у меня класс на асинк-инете, но он написан хреново.. Работает хорошо, но слишком много там исправлений всяких. Если что-то серьезное качать — надо переписывать. Могу сбросить как семпл..
Да ничем, в принципе. Просто нужны такае вещи, как таймаут на коннект, на прием, прерывание скачивания в любое время. В общем, этакий коллбэк с UI. Как сказали выше — синхронный WinInet — лажа, асинхронный — гемор. Склонен с этим согласиться...
Да и потом — вполне возможно, что данный классец будет юзаться и под *nix.
З.Ы. В принципе, я уже написал все... Осталось продебажить и собрать ценные замечания. Если вдруг кому интересно — то могу кинуть в "Исходники"
Здравствуйте, Flamer, Вы писали:
F>З.Ы. В принципе, я уже написал все... Осталось продебажить и собрать ценные замечания. Если вдруг кому интересно — то могу кинуть в "Исходники"
F>По просьбам трудящихся совсем сырые исходники того, что нужно было в первом посте... Никакой оптимизации, код сырой, все писалось за 3 часа на коленке. Сорри за объем кода. Итак:
Здравствуйте, Flamer, Вы писали:
F>Вот понадобилась такая простенькая вещь:
F>1. Платформа — Windows. F>2. Класс для получения информации по HTTP F>3. Поддержка GET/POST F>4. Поддержка HTTP-прокси и авторизации через прокси F>5. Без использования высокоуровневых оберток типа CString и пр.
F>Вот думаю: изобретать или есть готовый на С/С++? В принципе, изобретено уже процентов 60, но терзают смутные сомнения, что все уже украдено до нас.
F>Размер — имеет большое значение
F>To moderator: я намеренно запостил в форум по С/С++, т.к. нужно именно код, на 99% написанный на С/С++.
F>Что подскажут уважаемые?
Здравствуйте, Flamer, Вы писали:
F>По просьбам трудящихся совсем сырые исходники того, что нужно было в первом посте... Никакой оптимизации, код сырой, все писалось за 3 часа на коленке. Сорри за объем кода. Итак: F>...
Эх... а я ожидал чего-то грандиозного
F>Все замечания, пожелания, тухлые помидоры, усовершенствования, оптимизации и пр. — велкам. Оченно хочется довести до простенького ума.
Пока особо внимательно не смотрел, но сразу обнаружил задачи, которые можно было бы обернуть в классы. Например сокеты. Кроме того, много сишного кода. Подобный код в деструкторе в современных плюсах вообще анахронизм:
if(m_strPrefix)
delete [] m_strPrefix;
Насчёт усовершенствования — можно было бы сделать потоки и пул потоков, чтобы можно было делать сразу несколько запросов.
Немгого погодя посмотрю повнимательнее, ещё что-нибудь скажу
Здравствуйте, ArtDenis, Вы писали:
AD>Пока особо внимательно не смотрел, но сразу обнаружил задачи, которые можно было бы обернуть в классы. Например сокеты.
Как-то оно не надо мне было
AD>Кроме того, много сишного кода.
Так это одно из требований к задаче у меня было...
AD>Подобный код в деструкторе в современных плюсах вообще анахронизм: AD>
AD>if(m_strPrefix)
AD> delete [] m_strPrefix;
AD>
Ну привык я так — чуть-что, везде проверять... Звиняйте...
AD>Насчёт усовершенствования — можно было бы сделать потоки и пул потоков, чтобы можно было делать сразу несколько запросов.
Здравствуйте, Flamer, Вы писали:
AD>>Пока особо внимательно не смотрел, но сразу обнаружил задачи, которые можно было бы обернуть в классы. Например сокеты. F>Как-то оно не надо мне было
Давай рассмотрим задачу с точки зрения здравого смысла. Что по идее должен делать класс CHTTPRequest? Ответ однозначный — делать запросы HTTP-серверу и принимать. И всё. Ну уж не как не стратовать/останавливать сокетную библиотеку, открывать/закрывать сокеты. Этот класс должен быть изолирован от низкоуровневой работы. Эту работу должен выполнять класс сокета. Следующее замечание. Этот класс хранит параметры запроса и ответ сервера. В принципе, можно так это и оставить, на запрос и ответ я бы тоже обернул в классы. Для чего это нужно? Всё очень просто: чтобы можно было хранить очередь запросов и очередь ответов.
AD>>Кроме того, много сишного кода. F>Так это одно из требований к задаче у меня было...
А если не секрет, где это предъявляют такие требования?
AD>>Подобный код в деструкторе в современных плюсах вообще анахронизм: AD>>
F>Ну привык я так — чуть-что, везде проверять... Звиняйте...
Скриплю зубами, но всё-таки извиняю .
AD>>Насчёт усовершенствования — можно было бы сделать потоки и пул потоков, чтобы можно было делать сразу несколько запросов. F>А зачем? Можно просто класс в поток и вперед...
Конечно можно. Но я только привык обегчать себе жизнь. Как только я вижу достаточно общую задачу, я сразу делаю соответствующую библиотеку.
А как насчёт HTTP/1.0 и chunked trasfer encoding?
Просто запросы в 1.0 могут сильно грузить сервер,
особенно в случае всяких там скриптов и иже с ними.
Опять таки keep alive сильно всё ускоряет,
особенно proxy keep alive
Я просто писал похожую штуку, и можно сказать собаку съел на этом
Несколько полезных идей: Content-Type handler, функция
которая по контент тайпу ответа определяет что делать
с ответом. Ибо какой-нибудь application/x-zip размером 100Mb,
наверное стоит сразу писать в файло, а в случае статуса 404 ответ
в общем-то совсем не нужен...
Почти наверняка понадабятся такие вещи как Cookie и Referer.
Свои сорки в общем-то запостить могу,
но разве что для целей ознакомления,
ибо они зависят от целой кучи других либ...
IT>>А чем WinInet плох?
L>Многим. Меня вот удивляет, что никто про WinHTTP не вспомнил. А это как раз прямая замена WinInet от MS. И умеет она все, что Flamer описал.
Ну многим пишут софт который под 9х виндой работает
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, AndrewJD, Вы писали:
L>>Многим. Меня вот удивляет, что никто про WinHTTP не вспомнил. А это как раз прямая замена WinInet от MS. И умеет она все, что Flamer описал.
AJD>Ну многим пишут софт который под 9х виндой работает
На ней можно XMLHttp юзать, хотя он конечно горазбо более убогий, чем WinHTTP.
L>На ней можно XMLHttp юзать, хотя он конечно горазбо более убогий, чем WinHTTP.
плюсы WinHTTP
— и в серверном и в клиенском можно применять
— удобно реализована autoproxy
минусы WinHTTP
— com библиотека по умолчание не заренистрированна в WIn2003 (кошмар на самом деле)
— баркдак с версиями:
5.0 есть редистрибьют и ставится куда угодно, но имеет кучу ограничений(обидное на TLS ограничение) и не поддерживается MS
5.1 не имеет редистрибьюта и требует последних систем(WinXP SP1, Win2003, Win2k SP3(4 забыл какой точно))
итого имеет слабо применимый вариант.(хотя я скрипя зубами использую 5.1)
WinInet не умеет работать с сервисами... так что почти не жилец.
>Вот думаю: изобретать или есть готовый на С/С++?
Так что нужна такая библиотека. только хорошо бы в ней основные фичи WinHTTP реализовать.
Здравствуйте, Flamer, Вы писали:
F>Вот понадобилась такая простенькая вещь:
F>To moderator: я намеренно запостил в форум по С/С++, т.к. нужно именно код, на 99% написанный на С/С++.
А мне нужно было быстро сделать похожую задачу, так я всё на Python сделал, а потом в плюсы результат отдал. F>Что подскажут уважаемые?