Обработка разных URL на одной странице

Имеем запросы вида "сайт/страница". По дефолту веб сервер вернёт по такому запросу страницу, указанную после слеша, или выдаст ошибку 404, если соответствующей страницы не существует на сервере.
Мне надо, чтобы веб сервер не искал страницу из URL на сервере, а направлял все запросы на одну страницу, где они уже будут обрабатываться скриптом.
Как это можно сделать?

0

Сообщение от ChildOfFlowers Это я и хотел бы узнать

Вы ошибаетесь. Если убрать это условие, больше шансов, что запрос будет передан на обработку в index.php

Сообщение от ChildOfFlowers Потому что тогда уж надо все каталоги выносить за пределы корневого. Ведь имя любого каталога может пересечься с именем модуля.

Не все, а только с кодом. Каталоги со статичными файлами можно оставить в корневом каталоге. Так сервер будет их передавать быстрее, "не запуская PHP". Конечно, минимальный уровень защиты от конфликтов нужно обеспечить, но это не "костыль", а наоборот симбиоз: можно сделать так, чтобы "по адресам каталогов" обработку выполнял ваш скрипт, а "по адресам файлов" - непосредственно Web-сервер.

Добавлено через 6 минут
Например, по адресу /images может быть запущен модуль галереи для отображения графических файлов в указанном каталоге, а по адресам наподобие /images/image.jpg файлы будет отправлять непосредственно сервер. То же самое и при большей вложенности каталогов.

0

Сообщение от estic Вы ошибаетесь

А вот и нет. Конечно же, первым делом я попробовал убрать это условие. Когда оно не прописано, не подключается вообще ни один модуль. Хотя не очень понятно почему так происходит... но, видимо, это правило влияет на разрешение адресов и между компонентами сайта.

Сообщение от estic Каталоги со статичными файлами можно оставить в корневом каталоге

Так какая разница, какое содержимое каталога. Проблема возникает когда введённый url совпадает с адресом каталога. Т.е., гипотетически, эта проблема может возникнуть с любым каталогом, находящимся в корневой директории сайта.

Сообщение от estic по адресам наподобие /images/image.jpg файлы будет отправлять непосредственно сервер

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

0

Сообщение от ChildOfFlowers А вот и нет. Конечно же, первым делом я попробовал убрать это условие. Когда оно не прописано, не подключается вообще ни один модуль. Хотя не очень понятно почему так происходит..

Вот и ищите причину этой аномалии. По возможности помогу.

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

Тогда, естественно, убираете и такие статичные файлы. Типичные примеры - лог-файлы, "сессионные" и т.п. Им явно не место в корневом каталоге сайта.

0

Сообщение от estic Вот и ищите причину этой аномалии

Нашёл. Как всегда, ларчик просто открывался. У меня там была проверка на пустой $_SERVER['REDIRECT_URL']. Но я по первости, конечно, не мог знать, что при включённом RewriteRule $_SERVER['REDIRECT_URL'] не может быть пустым, а содержит, как минимум "/". Теперь то это кажется логичным, ведь RewriteRule и должно переводить все запросы на "/"... но кто ж знал
Ну да ладно, это я поправил. Но всплыл другой сюрприз. Если задать url, соответствующий адресу реального каталога, то в адресной строке браузера к запросу приписывается "?url_param=...". Т.е., в моём случае, когда я переходу по адресу "mysite/modules", теперь отображается нужная страница. Но при этом в адресной строке появляется "mysite/modules/?url_param=modules". Как эту напасть побороть, чтобы ничто не выдавало, что на сервере есть такая папка?
Ну и второе, о чём мы уже говорили. Если ввести полный путь к существующему файлу, этот файл отобразится. Почему на него не срабатывает RewriteRule? Ведь оно, по идее, должно срабатывать на все запросы без исключения?

0

Непонятные параметры сами по себе не появляются Тут или какое-то постороннее правило повлияло, или вы в действительности используете не то правило для перенаправления запросов в index.php, которое показали. Внешнее перенаправление скорее всего было вызвано неявно из-за обращения к каталогу (обратите внимание на то, что к адресу помимо строки параметров был добавлен еще и завершающий слеш пути). Я об этом уже писал в теме: Обработка разных URL на одной странице (последний абзац). Речь о DirectorySlash со значением по умолчанию On. Измените значение на Off или отключите mod_dir.

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

У вас должно было остаться условие, касающееся файлов. Как защитить содержимое каталога, я уже писал. Специальное правило (или отдельный .htaccess "с запретами" в самом защищаемом каталоге и во всех вложенных, если нет наследования) или то, что вы назвали "костылем" и что в действительности является наилучшим способом защиты.

1

Сообщение от estic Речь о DirectorySlash со значением по умолчанию On. Измените значение на Off или отключите mod_dir.

Помогло, спасибо

Сообщение от estic что в действительности является наилучшим способом защиты

Наверное вы правы. Хотя с точки зрения организации сайта мне кажется некорректно хранить контент за пределами корневого каталога. И всё-таки мне непонятно, почему правила из .htaccess не работают в этом случае.

0

Сообщение от ChildOfFlowers некорректно хранить контент за пределами корневого каталога

Файлы сайта хранятся в папке, к примеру, site.ru/, а файлы, доступные пользователю, в site.ru/public/. Т.е. файлы index.php, style.css, js-скрипты и т.п. выносятся в папку public, а к исходной папке site.ru/ пользователь не имеет доступа через браузер.

Ваши скрипты хранятся в site.ru/app/, например site.ru/app/SomeScript.php

Для этого нужно изменить document root в вашем веб-сервере (apache/nginx/оба сразу).

Сообщение от ChildOfFlowers почему правила из .htaccess не работают в этом случае

Вот это правило:
Отменяет редирект на index.php, если файл существует.

0

Сообщение от ChildOfFlowers Хотя с точки зрения организации сайта мне кажется некорректно хранить контент за пределами корневого каталога.

Корневой каталог обычно не является основным каталогом сайта, как показал Jodah. Это всего лишь место для размещения общедоступных, часто только статичных, файлов. В высоконагруженных динамичных сайтах он часто бывает пустой, чтобы не тратить время даже на тест существования файла. Также часто в нем могут быть размещены только основные статичные файлы с предопределенными именами наподобие favicon.ico, robots.txt, кэша карты сайта. А все прочие статичные файлы загружаются с других хостов. Вы можете сконфигурировать Apache в контексте виртуального хоста так, чтобы вынести из корневого каталога и index.php (заодно можно запретить выполнение скриптов в пределах всего корневого каталога). Например (условие перед правилом усложнено, потому что в данном контексте %{REQUEST_FILENAME} еще не содержит полный путь в файловой системе):
В результате получится примерно такая структура основного каталога:
logs
modules
public
index.php

Файл index.php можно разместить и в соседнем с корневым каталоге, но лично я часто размещаю все точки входа (index.php, cron.php и т.п.) прямо в основном каталоге.

Сообщение от ChildOfFlowers И всё-таки мне непонятно, почему правила из .htaccess не работают в этом случае.

Тоже уже ответили. Только это называется не правилом, как его назвал Jodah, а условием. Это не самостоятельная директива, а приставка перед директивой правила. Я же вам советовал убрать условие, касающееся каталогов (с "!-d"). А условие, касающееся файлов (с "!-f"), должно было остаться. Это и есть тот самый тест на существование файла, который я уже упоминал в этом сообщении. Это условие и препятствует перенаправлению запросов в index.php, когда присутствует запрашиваемый файл.

0