Я управляю большим количеством приложений PHP, используя передний контроллерs и следующий файл htaccess:
FallbackResource /index.php
Да, это весь файл (для каждого приложения)!
Однако некоторые сайты находятся во вложенных папках, что требует следующих изменений:
FallbackResource /subfolder/index.php
Как вы могли догадаться, / в начале означает, что путь указан относительно сайта / vhost, а здесь путь должен быть относительно каталога.
(Если бы я использовал mod_rewrite для этого вместо mod_dir, Мне пришлось бы добавить RewriteBase в каждый подкаталог по мере необходимости аналогичным образом.)
Я думал, что смогу обойти это, выполнив:
FallbackResource index.php # No slash!
Однако, если перезапись сайта содержит косую черту, например, если приложение /store/ и путь внутри него products/1234, то Apache ищет /store/products/index.php вместо того /store/index.php и возвращает 500 со следующим сообщением в журнале:
Запрос превысил ограничение в 10 уровней вложенности подзапросов из-за возможной ошибки конфигурации. При необходимости используйте LimitInternalRecursion, чтобы увеличить лимит. Используйте «Отладка LogLevel», чтобы получить трассировку.
Я бы подумал, что FallbackResource Путь указывается относительно файла .htaccess, в котором он настроен, но кажется, что он фактически относительно запрошенного URL.
Есть ли способ получить FallbackResource действовать так, как я ожидал?
Я могу использовать его как есть, если это ответ, но это упростило бы управление имеющимися у меня сайтами, если бы это было возможно. На сайтах используется один и тот же базовый код с разными темами и подключениями к базе данных, и теперь мне приходится изменять файл htaccess каждый раз, когда мы развертываем новую версию кода (потому что он проверяется в Git). Если мы сможем сделать так, чтобы кому-то не приходилось каждый раз помнить о внесении этой модификации, это было бы действительно здорово.
Я не думаю, что это легко сделать. Я пробовал разные комбинации DirectoryMatch и LocationMatch в основных файлах конфигурации с использованием новой интерполяции переменных, доступной в этих двух директивах.
Хотя что-то вроде FallBackResource index.html является полностью допустимой конфигурацией, я разделяю опасения Майкла Хэмптона о том, что любое использование относительных URL-адресов может вызвать проблемы. В случае FallBackResource index.html для конкретного дерева каталогов index.html должен всегда присутствовать, иначе вы получите цикл рекурсии, который вы описываете для запросов, где index.html не может быть найден.
В вашем случае вам понадобится верхний уровень .htaccess файл с FallBackResource /index.html, затем FallBackResource /subfoldername/index.html в каждой соответствующей подпапке.
Самый безопасный вариант - простой сценарий для их создания.
Сайты, о которых я изначально задал этот вопрос, больше не работают, но вот что я в итоге сделал.
В итоге я переместил эти сайты на сервер, на котором работает Nginx, где вся конфигурация выполняется в файлах конфигурации сервера с использованием try_files директива. Так было намного проще.
Я считаю, что можно обойтись без DirectoryIndex вместо того FallbackResource может также работать. Следующее будет соответствовать /a/script/ в файл /some/path/to/a/script/index.py затем /some/path/to/a/script/index.html затем /some/path/to/subfolder/index.py и наконец /some/path/index.py. Это зависит от DirectoryIndex почитая абсолютные пути.
ScriptAlias / "/some/path/to/"
<Directory "/some/path/to/">
Options +ExecCGI
AddHandler cgi-script .py
DirectoryIndex index.py index.html
# Appending /index.py seems to work whereas FallbackResource does not
DirectoryIndex /subfolder/index.py
DirectoryIndex /index.py
FallbackResource /index.py
Require all granted
</Directory>
Повторные звонки на DirectoryIndex добавляются к предыдущим вызовам. В моем случае FallbackResource не работал, и я наткнулся на это как на решение. Вышеупомянутое относится к файлам CGI / Python, но я считаю, что это сработает и в вашем сценарии.