HTTP/1.1 200 OK Date: Tue, 02 Nov 2010 07:22:33 GMT Server: Apache/2.2.3 (CentOS) Last-Modified: Fri, 07 Nov 2008 20:04:29 GMT ETag: "32d833-26604-ebbcad40" Accept-Ranges: bytes Content-Length: 157188 Connection: close Content-Type: text/html
где тут 404?
Хм, перепроверил сейчас - действительно 200. Точнее даже 206, если верить мозиловскому плагину. Видимо когда проверял с сайтом какой-то косяк случился или с руками. Но сути не меняет - идет переадресация на главную. И так уже две-три недели точно. Раньше просто внимания не обращал, может и дольше.
Есть мнение, что Яша (или кто-то из сотрудников) начал приторговывать местами. Запрос "Детская бижутерия" регион Москва. На первом месте уже несколько недель сайт со страницей, которой не существует. Проверка на http_headers - 404 код, как для браузеров там и для робота Яши.
Три жалобы на поисковый спам и одно письмо непосредственно в техподдержку остались без ответа. Понимаю, звучит бредово, но я другого объяснения не вижу.
З.Ы. Проверил те страницы, что у сайта в кеше. Все те страницы, что оканчиваются на html в top3 по запросам, которые у них в тайтлах. Причем все страницы ведут на главную 404-ым редиректом. Увидеть страницу можно только через консольные браузеры. Кто-нибудь может объяснить такую ситуацию?
Вымораживает уже! 😡 "Детская бижутерия", Москва. На первом месте 100% обман яндекса. Страница с переадресацией. Никто кроме яндекса и консольных брузеров не видит этой страницы. Уже два раза после последних апов им написал, что там обманка. Ноль внимания. Зла не хватает... 😡
Видимо да. Спасибо большое. Но как выяснилось это не единственная проблема. Часть проксей жутко медленные и просто не успевают отдать все данные за отведенное время.
netwind: curl как раз и создан чтобы скрывать подобные детали в протоколе. а не страдаете ли вы какой-нибудь фигней? пишите проще.
Проще только curl в один поток последовательно. При большом кол-ве обращений получается слишком долго. У меня просто есть подозрение, что multi_curl может этого не уметь. Потому при последовательных запросах такой проблемы вроде как не возникало.
Hekcfy: окей, можно продолжить мою логику, написав модуль автоматического парсинга списков прокси с разных сайтов. Все что вам нужно будет сделать - это единожды составить список источников прокси.
К тому же оплаченные прокси еще не гарантия их постоянной и стабильной работы. Ибо при большом количестве запросов с одного прокси он успешно уйдет в бан.
В прочем, дело ваше. Описанная мной схема применяется лично и довольно успешно.
Да нет, я не спорю. Ваш вариант абсолютно нормальный и работоспособный. Собственно я и думал изначально получать списки проксей таким образом. Просто у меня есть средства, что бы покупать готовые списки (в смысле не из своего кармана). При прочих равных, мне кажется, что покупные прокси будут палиться не с такой скоростью, как те, что не находятся в общем доступе. Ну и как плюс - не надо парсить несколько сайтов, а можно получать сразу готовый список и тем самым уменьшить число телодвижений. Ведь если кому-то припрет сментить дизайн на сайте, мне придется садиться и переписывать парсер под изменения.
Hekcfy: arbuzzz, а в чем проблема запихнуть в файл вселенскую кучу бесплатных прокси, через курл грузить нужную страничку каждый раз используя новый прокси из списка. Те что отдали заголовок отличный от 200 или не тот контент или медленно - удалять из массива.
А саму выборку поставить на цикл до последнего живого прокси.
Скрипт должен работать автоматически и, соотвественно, я не хочу принимать в участия в его работе даже в виде подсовывания ему новых списков проксей. Посему мне наверное проще заплатить и забыть о поиске.
So1: 1. Купить, как тут уже и сказали
2. Список проксей ставите на крон, получаете страничку через прокси и смотрите время отклика (тут можно просто получать странички с сервреров гугла - US, RU, CN и т.д., чтобы определить отклик от серверов в разных странах), меняете UPTIME. Так у вас будет список проксей, их аптайм и время отклика, а там уже сами решаете насколько они "живые".
Еще не плохо бы анализировать заголовки, отдаваемые прокси.
а странности тем не менее продолжали появляться, 6,7 и 11, 13 одни и те же страницы и такое по нескольким проектам чудеса
6 - 4dsd.ru/coatrack.htm
7 - ww.Vica.ru›Реализованные проекты›Одежда
11 - www.mebelneo.ru/oborudovanie/136/
13 - www.mdm-group.ru/Product_Photo.asp
Вы в каком регионе смотрите?
где тут 404?
Хм, перепроверил сейчас - действительно 200. Точнее даже 206, если верить мозиловскому плагину. Видимо когда проверял с сайтом какой-то косяк случился или с руками. Но сути не меняет - идет переадресация на главную. И так уже две-три недели точно. Раньше просто внимания не обращал, может и дольше.
Есть мнение, что Яша (или кто-то из сотрудников) начал приторговывать местами. Запрос "Детская бижутерия" регион Москва. На первом месте уже несколько недель сайт со страницей, которой не существует. Проверка на http_headers - 404 код, как для браузеров там и для робота Яши.
Три жалобы на поисковый спам и одно письмо непосредственно в техподдержку остались без ответа. Понимаю, звучит бредово, но я другого объяснения не вижу.
З.Ы. Проверил те страницы, что у сайта в кеше. Все те страницы, что оканчиваются на html в top3 по запросам, которые у них в тайтлах. Причем все страницы ведут на главную 404-ым редиректом. Увидеть страницу можно только через консольные браузеры. Кто-нибудь может объяснить такую ситуацию?
Вымораживает уже! 😡 "Детская бижутерия", Москва. На первом месте 100% обман яндекса. Страница с переадресацией. Никто кроме яндекса и консольных брузеров не видит этой страницы. Уже два раза после последних апов им написал, что там обманка. Ноль внимания. Зла не хватает... 😡
Не может ли быть проблема в том, что:
http://ua2.php.net/manual/en/context.http.php
Еще тут - http://jaybyjayfresh.com/2008/09/02/chunks-chunks-chunks/
Видимо да. Спасибо большое. Но как выяснилось это не единственная проблема. Часть проксей жутко медленные и просто не успевают отдать все данные за отведенное время.
curl как раз и создан чтобы скрывать подобные детали в протоколе. а не страдаете ли вы какой-нибудь фигней? пишите проще.
Проще только curl в один поток последовательно. При большом кол-ве обращений получается слишком долго. У меня просто есть подозрение, что multi_curl может этого не уметь. Потому при последовательных запросах такой проблемы вроде как не возникало.
окей, можно продолжить мою логику, написав модуль автоматического парсинга списков прокси с разных сайтов. Все что вам нужно будет сделать - это единожды составить список источников прокси.
К тому же оплаченные прокси еще не гарантия их постоянной и стабильной работы. Ибо при большом количестве запросов с одного прокси он успешно уйдет в бан.
В прочем, дело ваше. Описанная мной схема применяется лично и довольно успешно.
Да нет, я не спорю. Ваш вариант абсолютно нормальный и работоспособный. Собственно я и думал изначально получать списки проксей таким образом. Просто у меня есть средства, что бы покупать готовые списки (в смысле не из своего кармана). При прочих равных, мне кажется, что покупные прокси будут палиться не с такой скоростью, как те, что не находятся в общем доступе. Ну и как плюс - не надо парсить несколько сайтов, а можно получать сразу готовый список и тем самым уменьшить число телодвижений. Ведь если кому-то припрет сментить дизайн на сайте, мне придется садиться и переписывать парсер под изменения.
arbuzzz, а в чем проблема запихнуть в файл вселенскую кучу бесплатных прокси, через курл грузить нужную страничку каждый раз используя новый прокси из списка. Те что отдали заголовок отличный от 200 или не тот контент или медленно - удалять из массива.
А саму выборку поставить на цикл до последнего живого прокси.
Скрипт должен работать автоматически и, соотвественно, я не хочу принимать в участия в его работе даже в виде подсовывания ему новых списков проксей. Посему мне наверное проще заплатить и забыть о поиске.
1. Купить, как тут уже и сказали
2. Список проксей ставите на крон, получаете страничку через прокси и смотрите время отклика (тут можно просто получать странички с сервреров гугла - US, RU, CN и т.д., чтобы определить отклик от серверов в разных странах), меняете UPTIME. Так у вас будет список проксей, их аптайм и время отклика, а там уже сами решаете насколько они "живые".
Еще не плохо бы анализировать заголовки, отдаваемые прокси.
Спасибо большое за алгоритм :)
Для Perl подойдет что-нибудь подобное:
http://search.cpan.org/~zoffix/WWW-ProxyChecker-0.002/lib/WWW/ProxyChecker.pm
С перлом, к сожалению, не знаком. Есть ли решение для php? Я его и сам готов написать, если пойму, как именно и что надо проверять.