ООП-обертка для PHP lib_curl

Работу через прокси прикрутите, полезная штука для «рутинной работы».

Попробовал.
Будет удобнее, если будет в наличии дефолтная конфигурация.

А какая проблема в получении HTTP статусов, все делается через CURL: CURLOPT_HEADER => true
Вы же обвертку сделали, и там как-то HTTP заголовки получаете, так нет проблемы сделать strpos($header,«404 Not Found») например.

А функциональность вся из CURL проброшена в классы? Например поддержка curl_multi_getcontent есть?

Эксепшены б еще кидало :)

Лучше бы повторили функционал и синтаксис php.net/http для тех, у кого хостинг не позволяет ставить экстеншны.
А пока у вас ООП ради ООП, да еще и менее функциональное, нежели сам курл.

Если у браузера (того же Firefox) стоит какой-то плагин типа Яндекс-бара, то юзер-агент будет подкорректирован (поправьте если я туплю). И Ваше тогда определение юзер-агента идет гулять :)

Snoopy на cURL?

Zend_Http_Client же есть. Умеет всё то что умеет Снусмумрик + умеет прокси + бросает эксепшены, имеет адаптер для работы через CURL или сокеты. Я не пробовал и могу ошибаться, но вроде работает с https. И вообще более авторитетен. Пожалуй, единственный минус — это монструозность.

Я бы советовал углубляться не в функционал, а в удобство.
Очень длинные имена, естественно (надеюсь) это сделано для удобства и понимания что происходит, но есть запросы которые итак интуитивно понятны:
$browser->get(...); // вместо $Browser->get_request_send(...)
Либо на крайняк $browser->get($params)->send(); // удобно, гибко, изменяемо
Как вараинт разбить на типы: $browser->request->get(...); $browser->response->clear(); (clearBody)
Как ни крути, повторяя один в один вы сделаете тот же самый курл но со стрелочками =) А нужно сделать качественную и удобную библиотеку, которая инкапсулирует курл, это не одно и то же. Бейте на классы, разжелите запрос и ответ, не бойтесь сделать длинней, дайте возможность переопределять любую часть вашей библиотеки, подумайте над апи и удобством пользования и будет Вам счастье. Сейчас это копия курла в виде обьекта. ООП — не набор функций в классе, это не стоит забывать.

не хватает поддержки кук

пользуюсь www.phpclasses.org/package/4322-PHP-Perform-HTTP-requests-using-Curl.html
меня вполне устраивает

Можно ссылку на агрегатор комиксов? Кажется догадываюсь о каких сайтах идет речь, действительно неудобно прыгать по закладкам, а руки все не доходят что-то предпринять.

Товарищ nalimka, хватит исходить на желчь. Любой разработчик на PHP когда-нибудь писал свои обертки к Curl и MySQL. Писать их самому, в сравнении с использованием фреймворков, может быть полезно по нескольким причинам:

— во-первых, ZF, хоть и хороший и известный фреймворк, но при этом уродливый монстр. Тянуть чуть ли не полгигабайта файлов ради того, чтобы отправить 1 GET-запрос — верх маразма. Эти файлы, мало того, что напрасно занимают место на диске, еще и СИЛЬНО увеличивают потребление памяти и время, которое PHP тратит на их загрузку и разбор (в случае использования кешера они еще и в нем дофига памяти отъедают). Возможно, некоторым недопрограммистам, пришедшим с Явы и нравится для каждой задачи порождать сотни файлов по 10 строчек, и каждую селочь делать через абстрактные фабрики, но это все же сказывается на производительности. Плюс, там много лишнего хлама, типа транспорта, который работает через fsockopen() вместо curl. Если у вас на хостинге нельзя ставить курл — купите за 70 рублей в месяц VPS в селектеле и хоть на C# там код пишите.

— во-вторых, менее монструозные штуки типа Snnopy или httpClient — недоделанные, несовершенные, часто устаревшие (PHP 4 живее всех живых), неэффективные. Пишет их обычно кто попало. Если можно написать лучше, почему бы и нет.

— в-третьих, полезно для собственного развития и лучшего понимания например HTTP-протокола.

Я сам например, написал аж 2 обертки над курлом: Util_Curl — для самых примитивных вещей (get/post), и обертку с многопоточным скаичиванием, проксями, ограничением частоты запросов, автоматическим перекодированием кодировок, разбором HTTP Response headers, ручной работой с куками, коллбеками, преобразованием УРЛов в абсолютный вид. ZF такое вряд ли умеет, плюс моя обертка состоит из 3 файлов, а не тонны кода.

Так что, уважаемый автор, пишите дальше, а этот код все же спрячьте куда нибудь и никому не показывайте, пока не перепишете нормально.

Что касается вашего кода, то во-первых, методы с подчеркиваниями смотрятся ужасно, во-вторых, 6 аргументов к функции — это маразм и нечитабельно, в-третьих, имхо, лучше использовать конструкторы в виде статических методов, а не безликий несемантичный бессмысленный new. Советую поменять интерфейс на такой:

$page = Snufkin::init($options)->getBody('http://example.org', $getData, $requestOptions);
$code = Snufkin::init($options)->get('http://example.org', $getData = array(), $requestOptions = array())->getHttpCode();
$code = Snufkin::init($options)->post('http://example.org', $postData, $requestOptions)->getHeader('Location');

Ну и перекодировку, рефереры, response_clean() (ручное управление памятью??) и прочую ненужную хрень уберите куда-нибудь в опции.

Эх, держите меня семеро, пока я свои разработки на хабр не запостил.

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

вот и выросло поколение, которое среди готового не ищут первым делом в pear
посмотрите PEAR::HTTP_Request2

Какой смысл использовать COOKIE FILE, если его отлично можно получить/собрать/отправить простой строкой.

Регулярки для примера:
/Set-Cookie:\040(.+?)(\n|$)/is — получение
/((expires|path|domain)=.+?|secure|httponly|\S+=deleted)(;|$)/i — фильтрация

А где там ООП то?

Рефакторить надо, наверное, долго и упорно:) Только открыл — и у меня уже вызывает вопросы например этот участок кода

function
      __construct($conf = false) {
        $conf = array(
          'timeout'  => 5,
          'redirects' => 2,
          'agent'   => 'Snufkin 4.0',
          'referer'  => 'http://github.com/Shushik/Snufkin/',
          'charset'  => 'utf-8',
          'encoding' => 'gzip/deflate',
          'ssl'    => array(),
          'headers'  => array(),
        );

        if ($conf) {
          // Change default config values
          foreach ($conf as $alias => $value) {
            $conf[$alias] = $value;
          }
        }

* This source code was highlighted with Source Code Highlighter.

Дело в том, что $conf сразу же переопределяется. Что, такое и правда будет работать??
При передаче в параметрах $conf лучше делать null, чем false. Хотя в данном случае, при переопределении параметров, задающихся массивом, и ожидаться должен пустой массив. И естественно, нет никакой нужды заново изобретать array_merge :)) А сами параметры по умолчанию — членом класса, чтобы их в случае необходимости можно было быстро менять или использовать в других методах.

Конструктор лучше сделать public, а название метода не переносить ёлочкой на следующую строку — таких гайдлайнов я нигде ещё не видел. Ну и по именованию — $conf всё же это традиционные $params (реже $options).
Итого с учётом сказанного выглядеть это должно примерно так:

protected $defaultParams = array(
      'timeout'  => 5,
      'redirects' => 2,
      'agent'   => 'Snufkin 4.0',
      'referer'  => 'http://github.com/Shushik/Snufkin/',
      'charset'  => 'utf-8',
      'encoding' => 'gzip/deflate',
      'ssl'    => array(),
      'headers'  => array(),
    );

    public function construct($params = array()) {
        $params = array_merge($this->defaultParams, $params);

* This source code was highlighted with Source Code Highlighter.

Касательно именований методов: методы cookies(), charset(), headers(), header(), head(), headы(), http(),… etc — абсолютно неясно из названий, что они делают. Методы — по определению глаголы, а не существительные. То есть set_cookies() намного более понятно, чем просто cookies(). Ведь установка далеко не единственное возможное действие с ними.

Остальной код не смотрел.
Всё вышеописанное отправил пулл-реквестом github.com/Shushik/Snufkin/pull/1