первый релиз PEAR::HTTP_Request2

valeraorg

Новичок
Спасибо вам за вашу работу!!! Кстати думаю вам будет приятно, видеть где реально используется ваша работа...
У меня есть проект http://unextupload.com Работа с файлами короче говоря. Так вот, ваша библиотека прогоняет через себя ежедневно 1-2 ТБ данных. А всего прогнала уже более 100 ТБ данных.
Как станем приносить прибыль обязательно уважу вас donate.

Кстати где можно забрать новую версию. У меня сейчас стоит пропатченная Request2.php,v 1.12 2009/04/03 21:32:48
У них API совместимо?
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Автор оригинала: valeraorg
Кстати где можно забрать новую версию. У меня сейчас стоит пропатченная Request2.php,v 1.12 2009/04/03 21:32:48
У них API совместимо?
На сайте PEAR, у меня ж эта ссылка в подписи даже. API (скорее всего) совместимо, читай Changelog'и.

Учитывая вашу специфику, обрати внимание на следующее:
Implemented workaround for PHP bug 47204, Curl Adapter can now handle
Digest authentication and redirects when doing POST requests, unfortunately
this requires loading the entire request body into memory.
Т.е. либо не пользуйся Curl'ом, либо не включай в нём поддержку Digest auth и redirect'ов, а то память кончится на здоровых закачках. Все вопросы к аффтарам PHP'шного расширения Curl.
 

valeraorg

Новичок
>На сайте PEAR, у меня ж эта ссылка в подписи даже. API (скорее всего) совместимо, читай Changelog'и.

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

Понравилось что есть теперь редиректы, а то мне приходилось давать HEAD запросы (так как заранее не известно что за ссылка:прямая или с редиректом) и читать location (их переводить в абсолютную форму). Короче все вручную делал.

На сокеты как то страшно переходить, боюсь за производительность. Профилировать нет возможности (долго). Как думаете производительность намного упадет?

-~{}~ 20.11.09 19:07:

Digest auth я нигде не испольую. Насколько я понял если у меня GET запросы, то редиректы я могу юзать?
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Автор оригинала: valeraorg
На сокеты как то страшно переходить, боюсь за производительность. Профилировать нет возможности (долго). Как думаете производительность намного упадет?
На сокеты переходить не обязательно, но лучше не включать redirect'ы при использовании Curl'а для закачки файла. При скачивании --- на здоровье.

Производительность не мерял, ежели кто померяет --- скажу спасибо.

Новую версию выложу на днях, думаю.

-~{}~ 20.11.09 20:07:

Автор оригинала: valeraorg
Насколько я понял если у меня GET запросы, то редиректы я могу юзать?
Да, именно.
 

valeraorg

Новичок
Тут такое дело... Немогу к сожилению локализовать ошибку, но думаю вам будет все понятно.
В понедельник перевел свой проект на новую версию вашей либы, до этого стояла самая первая. Все работает хорошо... в основном.
Стали поступать жалобы, что иногда файл не докачивается до конца с сервера. До этого таких жалоб небыло ниразу.
Иными словами, я так понимаю, сейчас перестали выбрасываться исключения в случае если имел место обрыв связи. Качаю файлы вашим обсервером для скачивания файлов, с минимальными дополнениями.
Может быть это все гонево какое-то конечно, но все равно подумайте над этим пожалуйста.

-~{}~ 25.11.09 10:48:

использую курл.

-~{}~ 04.12.09 09:18:

Нашел такую особенность:
Рассмотрим случай серии запросов.
$client = new HTTP_Request2($url, 'POST');
$client->addUpload(...);
...
$client->send();

$client->setUrl($url1);
$client->postParemeters(...);
$client->send();

Метод запроса сохраняется первый установленный - это нормально и понятно.
Но недоумение вызывает тот факт, что во втором запросе в теле реквеста будет ехать файл на сервер. Это как-то непонятно.
Может это и не бага, а архитектурная особенность, но тогда имхо должен быть метод типа такого $client->deleteBody();
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Автор оригинала: valeraorg
Тут такое дело... Немогу к сожилению локализовать ошибку, но думаю вам будет все понятно.
В понедельник перевел свой проект на новую версию вашей либы, до этого стояла самая первая. Все работает хорошо... в основном.
Стали поступать жалобы, что иногда файл не докачивается до конца с сервера. До этого таких жалоб небыло ниразу.
Иными словами, я так понимаю, сейчас перестали выбрасываться исключения в случае если имел место обрыв связи. Качаю файлы вашим обсервером для скачивания файлов, с минимальными дополнениями.
Может быть это все гонево какое-то конечно, но все равно подумайте над этим пожалуйста.
По такому сообщению думать особо не над чем. В исключения оборачиваются ошибки самого cURL'а, так что единственный вариант --- он ВНЕЗАПНО перестал возвращать ошибки.


Нашел такую особенность:
Рассмотрим случай серии запросов.
$client = new HTTP_Request2($url, 'POST');
$client->addUpload(...);
...
$client->send();

$client->setUrl($url1);
$client->postParemeters(...);
$client->send();

Метод запроса сохраняется первый установленный - это нормально и понятно.
Но недоумение вызывает тот факт, что во втором запросе в теле реквеста будет ехать файл на сервер. Это как-то непонятно.
Может это и не бага, а архитектурная особенность, но тогда имхо должен быть метод типа такого $client->deleteBody();
Это "архитектурная особенность", класс предназначен для отправки одного запроса HTTP, а не серии. Если надо забить какие-нибудь параметры, общие для нескольких запросов, то лучше сделать так:
PHP:
$req = new HTTP_Request2(...);
$req->setConfig(...);
$req->setMethod(...);
$req->setHeader(...);
// клонируем, отправляем
$req2 = clone $req;
$req2->addUpload(...);
$req2->addPostParameter(...);
$req2->send();
// клонируем, отправляем
$req3 = clone $req;
$req3->setBody(...);
$req3->send();
В принципе в свежей версии $req->setBody(''); очистит тело запроса, но опять же, это нерекомендуемый подход.
 

DeadMorozBLR

Новичок
Sad Spirit, нет ли у Вас в планах вынести «источник» части multipart body в отдельный интерфейс и реализовать разные типы источников (строка, файл, файловый дескриптор и т.д.) через отдельные классы с возможностью расширения? Методы интерфейса, соответственно, будут приблизительно такими: getSize(), read(), eof() и т.д.

Это я к тому, что в нынешней (v0.5.2) реализации в качестве источника данных для загружаемого файла нельзя указать сокет или удаленный файл (с использованием protocol wrappers), т.к. на них не работает функция rewind, которая вроде как используется при определении размера файла., а дальше я не разбирался.

Необходимость такая вытекает из задачи загрузить удаленный (ftp, http, etc.) файл прямо в веб-форму, минуя промежуточное сохранение в локальную файловую систему. Спасибо.
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Автор оригинала: DeadMorozBLR
Sad Spirit, нет ли у Вас в планах вынести «источник» части multipart body в отдельный интерфейс и реализовать разные типы источников (строка, файл, файловый дескриптор и т.д.) через отдельные классы с возможностью расширения? Методы интерфейса, соответственно, будут приблизительно такими: getSize(), read(), eof() и т.д.

Это я к тому, что в нынешней (v0.5.2) реализации в качестве источника данных для загружаемого файла нельзя указать сокет или удаленный файл (с использованием protocol wrappers), т.к. на них не работает функция rewind, которая вроде как используется при определении размера файла., а дальше я не разбирался.

Необходимость такая вытекает из задачи загрузить удаленный (ftp, http, etc.) файл прямо в веб-форму, минуя промежуточное сохранение в локальную файловую систему. Спасибо.
Ну да, насчёт приёма файловых дескрипторов и класса-обёртки для них есть идеи, тут, во-первых, уже болтается request #16863. Во-вторых, неэстетично получается, что открываемые файловые дескрипторы нихрена не закрываются.

Что касается удалённых файлов, то на них не действуют stat() / fstat() / fseek(), то бишь полноценно с ними работать, скорее всего, не получится.
 

DeadMorozBLR

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

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Автор оригинала: DeadMorozBLR
Насчет удаленных файлов я имел ввиду не работу с ними напрямую, а только лишь использование уже открытого сокета с http- или ftp-сервером для чтения данных из него. При этом предполагается, что все дополнительные атрибуты, такие как длина содержимого, уже получены из заголовков и указатель, откручен на то место, где начинаются данные.
Файл может понадобиться перемотать на начало (если вдруг у нас Digest аутентификация или redirect по хитрому коду). А так да, можно кнэшно принимать дескриптор и ожидаемое кол-во данных в этом дескрипторе... Надо подумать, тащемта.
 

Fludimir

Новичок
Можно ли с помошью HTTP_Request2 получить последний адрес на который был редирект? подразумевается что редиректов может быть несколько
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Автор оригинала: Fludimir
Можно ли с помошью HTTP_Request2 получить последний адрес на который был редирект? подразумевается что редиректов может быть несколько
Можно и первый, и последний, и предпоследний. При помощи Observer'ов.
 

whirlwind

TDD infected, paranoid
Отличная реализация! Для полного счастья не хватает cookie store для последовательности запросов. Имеется реализация через декоратор на адаптер, но не очень удобно. Планируется ли что нибудь по этой теме?
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Автор оригинала: whirlwind
Отличная реализация! Для полного счастья не хватает cookie store для последовательности запросов. Имеется реализация через декоратор на адаптер, но не очень удобно. Планируется ли что нибудь по этой теме?
Да, как раз это единственная ещё не реализованная большая фича. Планирую сделать с использованием Public Suffix List, дабы соответствовало поведению браузеров.
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Так, выпустил наконец бета-версию: http://news.php.net/php.pear.general/30976

Добавлен вышеупомянутый cookie jar, подклассы исключений и коды ошибок (дабы ошибки было проще обрабатывать автоматически), возможность передавать файловые дескрипторы вместо имён файлов в addUpload() и setBody() (правда пока берём только поддерживающие fstat() и rewind()). Ну и до того было несколько багов поправлено и новые тесты добавлены.

В принципе это уже можно считать feature-complete, стабильным можно будет объявлять когда выйдет стабильный Net_URL2.
 

stalxed

Новичок
Спасибо за библиотеку - её использование только в радость, очень удобный API.

Но вот на хостинге проблема, там походу вообще не стоит pear.
Прописал:
PHP:
set_include_path(dirname(__FILE__) . DIRECTORY_SEPARATOR . 'libs/' . DIRECTORY_SEPARATOR . PATH_SEPARATOR . get_include_path());
Дальше в libs распаковал:
HTTP_Request2
Net_URL2

Начал смотреть есть ли дальше зависимости, оказалось да:
PEAR Package: PEAR Installer 1.5.4 or newer

По сути у HTTP_Request2 зависимость от:
PHP:
class HTTP_Request2_Exception extends PEAR_Exception
Но пакет PEAR базовый просит в зависимостях:
PEAR Package: Archive_Tar 1.3.7 or newer
PEAR Package: Structures_Graph 1.0.2 or newer
PEAR Package: Console_Getopt 1.2 or newer
PEAR Package: XML_Util 1.2.0 or newer
PEAR Package: PEAR_Frontend_Web (conflicts with some versions)
PEAR Package: PEAR_Frontend_Gtk (conflicts with some versions)

А часть этих пакетов просит ещё пакеты...
Замкнутый круг какой-то.

А изменять ручками
PHP:
class HTTP_Request2_Exception extends PEAR_Exception
на
PHP:
class HTTP_Request2_Exception extends Exception
религия не позволяет(править библиотечный код), да и может там ещё какие-либо зависимости есть.

Никто не подскажет, какие есть правильные решения установки HTTP_Request2 в отсутствие на хостинге PEAR?
 
Сверху