Проблемы индексации: Yandex Bot & Connection: keep-alive

Мда... нафлудили то...

Вы че? CGI это просто протокол взаимодействия. ISAPI - это способ подключения сторонних DLL/EXE внутрь IIS.

Причем тут "включен/выключен" если я полностью поток формирую сам? Весь. Заголовки, данные. Полностью, понятно?

Я пишу про IIS, а не про Apache. Причем тут вообще Апач? Вы хоть читайте сообщение прежде чем писать.

См. первый комментарий. Вы вообще все путаете в кучу - ISAPI, CGI, ASP...

Объясняю: ActivePerl под NT используется двумя способами: либо вы настраиваете IIS так, чтобы скрипт передавался на выполнение perl.exe (при каждом обращении spawnится новый процесс, exe отрабатывает и умирает) либо чтобы запрос передавался всегда сидящей в памяти DLLке по имени PERLIS.DLL. Это и есть ISAPI расширение IIS, которое грузится в память при первом обращении к скрипту и далее всегда сидит в памяти. В любом случае вы работаете по технологии CGI (Common Gateway Interface), который просто определяет что к скрипту CGI (неважно что это - файл pl, cgi, php, asp, java или что-то бинарное написанное на delphi или даже VB) напрявляются вот такие запросы, а оттуда ожидаются вот такие ответы.

Вы явно что-то путаете. Есть протокол обмена данными. Есть четко фиксированное не следование роботом этому протоколу. Вы же говорите какую-то ересь - кривизна, то, се. Вы конкретно можете сказать какая именно настройка и в чем приводит к тому-то и к тому-то? Нет? Тогда нечего здесь флудить. Если я вам говорю что проблема есть, значит она есть, значит она отловлена и доказана.

Если вы думаете что у вас с сайтами все в порядке - могу только разочаровать вас, я тоже долгое время так думал. Вы уверены, что ваш сервер отдает все 100% ответов на 100% запросов со стороны? А на чем зиждется ваша уверенность? На логах сервера? А если туда что-то просто не попадает? Вы понимаете вообще, что есть куча причин на системном уровне, на которые никакие настройки сервера не влияют?

Поэтому берется сканер трафика и смотрится - что в порт вошло, а что вышло. И никаких там "криво настроено" в системном администрировании не бывает. Бывает только причина, которую админ или может найти, или не может.

Кстати покажите мне, где яндекс говорит что он не умеет принимать gzip контент. Отсутствие заголовка Accept-Encoding приравнивается к умению принимать gzip по стандарту. А отсутствие gzip в перечне mime-typов ни о чем также не говорит.

А насчет рук - причем тут руки, я ж говорю - я НЕ ХОЧУ чтобы был keep-alive. Имею право. А когда он включен - в CGI НЕ ПОПАДАЕТ ЧАСТЬ ЗАПРОСОВ, это происходит где то выше скриптов - скорее всего на уровне интерпретатора perl (в perlis.dll). Никаких настроек там нет. Вообще. Так написана dll.

Я готов это подтвердить.

Про указатели сессий вы вообще пургу какую-то пишете. Причем тут вообще IIS и сессии? Сессия имеет отношение к конкретной реализации на каком-то языке. В ASP и PHP есть встроенные механизмы. На Perl сессий никаких нет, хочешь - делай сам. К IIS это вообще никак не относится. Обработка ASP сессий, например, реализована внутри обработчика языка ASP, который подключен к IIS как ISAPI расширение. Как там на дотнете не знаю, но идея та же.

Он вообще бредит по моему. SID в урлах парсятся яндексом, как и другие ключи. Пока не видел с этим никаких проблем. Тем более непонятно какое вообще отношение это имеет к тому с чего я начал.

Пора закрывать топик, все равно дельного никто ничего не подсказал.

> Кстати покажите мне, где яндекс говорит что он не умеет принимать gzip контент.

/ru/forum/comment/2005929 :)

CGI и ISAPI - это интерфейсы. Интерфейсы взаимодействия программы стороны сервера и веб-сервера. Если программа использует интерфейс ISAPI, то не использует CGI, и наоборот. Например, при установленном по умолчанию ActiveState Perl, скрипты .pl обрабатываются perl.exe и результат отдается IIS через интерфейс CGI, скрипты .plx обрабатываются perlis.dll и результат отдается IIS через интерфейс ISAPI. Посему либо ISAPI, либо CGI. Есть конечно CGI Wrapper но это извращение :)

Вы его на уровне HTTP формируете, а не на уровне TCP/IP. Если у IIS не включена поддержка keep-alive, соединение будет обрываться на уровне TCP/IP после отдачи контента. Ну выдаете вы хедер keep-alive, IIS-то откуда об этом знает, если у него в настройках стоит close? Отдал контент - закрыл сокет. Все.

А то, что бот Яндекса не понимает ответного close - это неправильно, тут никто не спорит. Но проще свой сервер наладить, чем ждать изменений у Яндекса.

Любой нормальный форум, как и любой сайт с авторизацией, держит инфу в куках, а не в сессиях.

Вы конечно много сказали, но только не о том, что писал я.

Вот это полная пурга. С IIS работаю давно, и могу сказать, что сессии в IIS - это его механизм, необходимы для внутренних связей и защиты приложений. А пхп, рерл, ява и т.д. при, CGI интерфейсе, - просто получают дуступ к ним, а для реализации через ASP (независимо от языка) - это встроенный экспортируемый объект.

IIS просто не может работать без сессий. Это одна из его основ (как сервера).

Все он понимает и close обрабатывать умеет, у ТС скорее всего дело совсем в другом - например IIS очень любит подставлять свои заголовки, которые ни разу не соответствуют стандарту - и что в результате получается на выходе - спрогнозировать сложно.

Дальше без телепатии ничего сказать нельзя.

Вот что пишет топикстартер:

Вот что написано в RFC 2616 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html):

Итого: поведение бота стандарту не соответствует.

Про несоответствие стандарту хедеров IIS - да, подставляет. Типа X-Powered-By: ASP.NET. Только каким образом сие может повлиять на индексацию, если HTTP/1.1 200 OK, Content-type, Content-length и все остальное необходимое в хедерах присутствует?

Да и не замечал я проблем с индексацией серверов на IIS.