Форум PHP

Анналы софттайм хранят несколько решений проблемы проверки наличия страницы путем определения ее размера без скачивания содержимого. Например, такой способ:
http://www.softtime.ru/forum/read.php?id_forum=7&id_theme=15130

Но, как выяснилось, работоспособность этих решений зависит от установленного на проверяемой странице кода.

В частности, если все содержимое страницы исчерпывается кодом

<?php     @$gorod = $_POST["gorod"];     if (!$gorod)     {         include "../../str.php" ;         die();     } ?>

то в ответ получаем

Ошибка. Код ответа HTTP: 404

Похоже, что этот дефект носит фатальный характер...

предлагалось проверять этим кодом наличие файлов, а не отклик скриптов.
Это всё ж несколько разные вещи.

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

По конкретному примеру Axill ответит, как автор, если захочет.

Но 404 быть не должно

404 дает приведенный мною код. Даже пустая страница дает 200.

Изначально я взял вариант Trianon
http://www.softtime.ru/forum/read.php?id_forum=7&id_theme=15132
И сходу получил

HTTP/1.1 404 Not Found

Потому, что на странице был код

<?php     @$gorod = $_POST["gorod"];     if (!$gorod)     {         include "../../str.php" ;         die();     } ?>

В остальных случаях работает нормально. Но меня как раз интересует только этот, не работающий случай!..

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

С Вашим вариантом так же. Посмотрите пост чуть выше.

Ну и если самого скрипта и вправду нет - тоже будет 404. .
Что, собственно, Вы и проверяете.

А вот Код 200 вернется, если скрипт не вернет Content-Length.
А он не вернет. Ибо с чего ему. В нем же не написали.

Еще раз - нужно проверять наличие файлов, а не скриптовый отклик.
Иными словами - исполнение файлов .php в проверяемой иерархии следует заблокировать.

Тогда я сформулирую ситуацию заново.

Для проверки наличия файлов использован скрипт, разработанный Trianon и опубликованный вот здесь:
http://www.softtime.ru/forum/read.php?id_forum=7&id_theme=15132

При запуске скрипта, если Вы помните, открывается окошко.

В это окошко я ввожу адрес СУЩЕСТВУЮЩЕГО файла, работоспособность которого предварительно проверена. И получаю от скрипта ответ:

HTTP/1.1 404 Not Found

Это ответ на определение размера существующего файла.

Ответ ошибочный. И этот ошибочный ответ возникает тогда, когда в коде проверяемого файла есть код, приведенный выше. А в других случаях в ответ выдается размер файла.

>В это окошко я ввожу адрес СУЩЕСТВУЮЩЕГО файла, работоспособность которого предварительно проверена.

Вы вводите не адрес файла, а адрес скрипта.
Потому что apache у Вас (полагаю) настроен так, что файлы с расширением php не отдает браузеру, а передает php-интерпретатору на исполнение.
А значит при всем желании (не отменяя эту настройку) доступ к самому файлу по http оказывается закрыт.

Ну да, я ввожу адрес страницы, а на ней исполняемый код - что же мне еще вводить?

Получается, что этот метод в моем случае работать не способен?

Пока, на период проверки он не должен оказываться исполняемым.
Если все заинтересованные каталоги скриптов лежат в отдельном (от скрипта проверки) каталоге, можно в нем поставить .htaccess , который отключит исполнение php и (к примеру) выдаст .php-файл как application/octet-stream (тупой поток байт)

Если они там не лежат - их можно туда переложить . Операция перемещения обычно не отнимает ресурсы.

по идее

RemoveHandler .php .html AddType application/octet-stream .php .html

в каталоге запрета должно хватить для.

Структура папок оказалась как нельзя более подходящей для внедрения настроечного .htaccess

И как интересно всё обернулось...

Спасибо!

Я лишь надеюсь, что Вы понимаете, что делаете.
Если там у Вас приватная информация в этих файлах, то время проверки стоит сократить до минимума.
Бо файлы своим текстом торчат наружу.
Или ввести запрет в зависимость от обратившегося IP.

IP непостоянен, поэтому на соответствующие папки я ставлю права доступа 700, снимая их на время контроля.

а апач-то сам не загнется при таких правах?
Да и IP столь часто не меняется.
Вы ж не через GPRS к сайту обращаетесь?

-

Работаю по выделенке, но IP меняется непредсказуемо. Может за день пару раз измениться, может оставаться неизменным несколько дней.

На практике тут все не так то просто оказалось. Сколько времени потребуется на проверку - неясно. Может, сутки, а может и больше...

Пока что не удается проверить даже десять тысяч страниц, потому что приходит сообщение, что не удалось соединиться, хотя файл присутствует. Скриптом повторяю процесс соединения с таким файлом до пяти раз. Файлы, на которых происходят сбои, все время разные.

>Пока что не удается проверить даже десять тысяч страниц,...

не за один же вызов скрипта?
Браузер просто отваливается по таймауту.

Я уже знаю это свойство браузеров - встречался с этим в других случаях. Скрипт работает сам по себе, а останавливается при обнаружении нулевого размера страницы.
Эта страница автоматически запрашивается еще раз, а если получаем опять нулевое значение, то еще и еще раз. Всего до пяти запросов. После чего проверка останавливается и я ищу эту страницу. А она есть!

Может, перед повторением запроса нужно дать секундную паузу? Типа sleep(1);

Владимир, прошу прощения, но дальнейшее как-то за рамками интереса.
Без всякого подтекста, не поймите превратно.

Понял нормально. Дальше я справлюсь.

Спасибо!

Чтобы броузер не отваливался, надо его периодически подкармливать.
Если в начале скрипта поставить

<? set_time_limit(0); ob_implicit_flush();

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

Спасибо. Я еще Аякс иногда использую.

Но тут меня удивило вот что: скрипт запрашивает страницу на сайте и получает ответ, что такого файла нет. Повторно запрашивает и опять нет. И так пять раз. А страница имеется!

Может, это обычно для запроса информации с сайта?
Может, надо делать паузу перед запросом?
Может, надо какой-нибудь буфер каким-нибудь образом зачем-нибудь очищать?
Или еще что-то делать?
Или это такой ненадежный инструмент, что с этим надо смириться?

Я с этим встретился впервые и не пойму...

>Запросто может быть.
>Тем паче, если обращаться именно этим вариантом именно за откликом скрипта.

Это может быть только если в str.php явно посылается заголовок "HTTP/1.0 404 Not Found". Я так думаю.

>Это может быть только если в str.php явно посылается заголовок "HTTP/1.0 404 Not Found". Я так думаю.

Наличие включаемого файла str.php вообще не влияет на выдаваемый отклик. Пока сам str.php не начнут проверять.

404 даст подключение несуществующего файла

Эта ошибка к файлам отношения не имеет

А nginx, по-моему, действительно способен на такую подлость (404). У меня такая ситуация: документ отдаёт, а Status-Line говорит о 404