Apache2.4.54 - Перезапись не работает в .htaccess
У меня есть этот файл .htaccess в /path/to/project/
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !system
RewriteRule ^(.*)/([^/]+)/?$ $1/some/folders/$2.php [PT]
</IfModule>
и, как видите, я хочу перенаправить https://example.com/path/to/project/folder на https://example.com/path/to/project/some/folders/folder.
Я знаю, что на это ответили около 1 миллиона раз, но даже RewriteRule ^ / без условий не работает.
Я включил mod_rewrite и проверил, что он включен, включив Header set в <IfModule>, и это сработало.
Я проверил, что AllowOverride All находится в каталоге /path/to/project/, например:
<Directory ${APACHE_ROOT_DIR}/path/to/project>
AllowOverride All
</Directory>
У меня больше нет идей. Я надеюсь, что кто-то может мне помочь.
ОБНОВЛЯТЬ:
Я протестировал перезапись на другом сервере, и там перезапись работает. Я скопировал точное переписывание, и оно не работает. Я даже воссоздал файловую структуру. Теперь проблема только у самого mod_rewrite или у сервера VirtualHost или у симулянта.
ОБНОВЛЕНИЕ 2:
У меня это работает в sites-available/default-ssl.conf, но не в .htaccess. Значит проблема в .htaccess и в mod_rewrite в комбинации. Потому что .htaccess работает с Header set test test, а mod_rewrite работает с default-ssl.conf.
@anubhava тоже не работает.
Я тоже так делал и уже говорил, что .htaccess работает, потому что можно устанавливать заголовки.
Почему у вас есть $2.php в вашем правиле? Кажется, это не входит в ваши требования.
$2 соответствует ([^/]+) в конце URL. См. раздел 2. с примером.
Я знаю, что не могу написать <Directory ...> в моем .htaccess, и я все равно не использую его здесь.
Внутри path/to/project/.htaccess просто держите только одну строку RewriteRule foo /bar [L,R] и посетите https://example.com/path/to/project/
С RewriteEngine on, верно?
Пробовал с RewriteEngine on и без. Оба ничего не делают.
Есть подозрение, что .htaccess не используется
Но если поставить Header set test test например, то работает.
Ответы 1
Я думаю, вы должны шаг за шагом отследить возможные проблемы.
Пожалуйста, не присоединяйтесь к некоторым тестам, так как каждый тест требует своего доказательства!
При этом, пожалуйста, оставайтесь на необходимом virtualhost.conf. Прыжки между default-ssl.conf и вашим virtualhost.conf могут дать некоторые подсказки, но бесполезны, когда вы пытаетесь систематически отследить проблему в ряде тестов.
1. Права доступа
Убедитесь, что посетителям разрешен доступ к каталогу. Так что добавьте Require all granted, если его еще нет:
Файл: httpd.conf или прилагается *.conf
<Directory "/var/www/vhosts/myhost/htdoc/PATH/TO/PROJECT">
Require all granted
AllowOverride All
</Directory>
После этой перенастройки требуется перезапуск демона Apache:
На веб-сервере введите команду:
apachectl -k graceful
Откройте URL вашего проекта http://example.com/PATH/TO/PROJECT/:
Вы не должны видеть 403 Access denied
=> В противном случае эта проблема должна быть решена в первую очередь. (присутствует индексный файл 0? / Apache перезапущен правильно? / Какие-либо правила перезаписи?)
СТАТУС-Обновление: Функциональность в норме
2. Проверьте использование файла .htaccess
К AllowOverride All использование файла .htaccess должно работать. Пожалуйста, проверьте это, так как опечатки и т. д. могут сделать недействительным любое предположение:
Добавьте строку ерунды в .htaccess папки вашего проекта:
Файл: /var/www/vhosts/myhost/htdoc/PATH/TO/PROJECT/.htaccess
asflksdflkj
Вызов страницы http://example.com/PATH/TO/PROJECT/ должен привести к
500 Server Error
Удалите строку ерунды в .htaccess и снова вызовите страницу:
=> Ошибка 500 должна исчезнуть.
.htaccess оценивается Apache, если поведение соответствует описанию.
СТАТУС-Обновление: Функциональность в норме
3. Проверьте наличие ReWrite Engine
Чтобы убедиться, что механизм перезаписи присутствует И доступ к файлу .htaccess есть:
Удалите или установите в качестве комментария проверку модуля на mod_rewrite.c, но оставьте активным RewriteEngine On:
# <IfModule mod_rewrite.c>
RewriteEngine On
# </IfModule>
Вызов страницы http://example.com/PATH/TO/PROJECT/ не должен вызывать
500 Server Error
=> Если это 500 происходит, модуль mod_rewrite не загружается.
При положительном результате вы можете повторно включить проверку модуля.
Что касается моих проектов, я дважды думаю об этом шаге, так как может быть лучше четко увидеть проблему сервера, чем получить неясные побочные эффекты из-за неоцененных правил перезаписи.
СТАТУС-Обновление: Функциональность в норме
4. Проверьте наличие параллельных правил перезаписи
Правила перезаписи оцениваются каталог за каталогом:
1. /.htaccess
2. /PATH/.htaccess
3. /PATH/TO/.htaccess
4. /PATH/TO/PROJECT/.htaccess
Таким образом, любые правила в родительских каталогах могут манипулировать REQUEST_URI таким образом, что каталог проекта не будет достигнут, и никакое правило в нем не будет запущено.
=> Если в родительских каталогах есть правила, отключите их на время тестирования.
=> Не забудьте проверить файлы Apache CONF на наличие параллельных правил перезаписи.
Чтобы увидеть ReWrite в действии, включите функцию DEBUG. Расширьте свой LogLevel для своего определения VirtualHost:
LogLevel notice rewrite:trace5
Теперь (после apachectl -k graceful) error_log должен быть чрезмерно заполнен.
Для всех правил перезаписи в родительских каталогах должен быть набор строк:
... applying pattern ...
... pass through ....
# or
... applying pattern ...
... RewriteCond: .... => not-matched, ...
... pass through ....
Для строк вашего проекта должен быть набор строк (и не только), например:
... applying pattern ...
... RewriteCond: .... => matched
... rewrite ....
Как тесты? => может быть полезно предоставить файл журнала
Обновление статуса:
- Есть правила перезаписи, выполненные до
- Ни одно из правил ReWrite не выходит из оценки
[L]eave.
([L]не будет проблемой, так как послеRewriteRule ... [L]ReWrite оценка будет перезапущена с самого начала) - По крайней мере, одно из ранее оцененных правил ReWrite изменяет URI проекта (добавляет DocumentRoot в URI) непреднамеренным образом, вызывая проблему.
=> Изменение рассматриваемого правила решило проблему.
5. Определите правильный RewriteBase
Файл: /var/www/vhosts/myhost/htdoc/PATH/TO/PROJECT/.htaccess
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !system
RewriteRule ^(.*)/([^/]+)/?$ $1/some/folders/$2.php [PT]
В зависимости от деталей и дальнейшего контекста может быть лучше другой RewriteBase. (предоставить отзыв? файл журнала?)
Для каждого шага предоставьте краткий результат, пожалуйста.
Во-первых, спасибо за длинные и подробные тесты
1. Я проверил, могу ли я получить доступ к папке /path/to/project/, и это работает. у меня там есть index.php и он загружается без проблем
2. Я добавил abcd и больше ничего в свой .htaccess и получил 500.
3. Я написал только RewriteEngine On и он не выдает 500.
4. Всего у меня есть 3 правила перезаписи: 1. Все http-запросы переписываются в https 2. Все PDF-файлы переписываются в программу просмотра PDF-файлов 3. Все https-запросы из моей внутренней сети переписываются в какой-то домен .local. - Все перезаписи не имеют флага [L] и разрешают дальнейшие перезаписи. Путь не меняется, только для файлов с расширением .pdf меняется на путь просмотра
Спасибо, я нашел проблему. Это была перезапись в мою внутреннюю сеть. он что-то сделал с URI и убил другие перезаписи. Я понятия не имею, почему, но теперь это работает.
Хорошо, поэтому проверка № 4 дала толчок. — Но с правилами перезаписи нужно быть осторожным и понимать, зачем они что-то делают. Так что я не успокоюсь, пока все правила и их возможные побочные эффекты не будут поняты и взяты под контроль.
Я также проверил другие перезаписи и понял, что ^$ создает проблему в RewriteRule. Я изменил все на .*.
Я хотел бы, чтобы были лучшие и простые инструменты для проверки и создания RewriteRules. Я нашел htaccess.madewithlove.com, но он не включает путь или другие специфичные для сервера вещи для получения результатов. Или лучше провести отладку в другом файле журнала, например, в Apache 2.2.
Поскольку вы можете определить отдельный error_log в каждом из ваших VirtualHost определений с помощью ErrorLog /var/log/apache/mydom_error.log, журнал отладки правил ReWrite является довольно эксклюзивным. Обратите внимание, что нет необходимости повышать уровень журнала для других событий журнала ошибок Apache: LogLevel notice rewrite:trace5 — Так что личная проверка правил ReWrite работает для меня вполне хорошо. — Довольно полезно начать с tail -fn0 error.log и открыть только один URL-адрес, чтобы вызвать ReWrite, чтобы увидеть, что происходит в этом отдельном запросе.
К сожалению, эти RegEx-тестеры, подобные тому, что вы связали, оценивают только одно правило или набор правил. Они понятия не имеют о других зависимостях, подобных тем, которые могут появиться в родительских папках. Я предпочитаю тестировать правила локально на виртуальной машине с запущенным apache, а мои сайты и тестовый сайт — как локальные версии. — Использование RewriteBase /PATH/TO/PROJECT/ с подобранным набором правил может быть сложнее на первых этапах, но очень помогает (1) ограничить влияние правил (2) повторно использовать правила без изменений в других каталогах (3) упростить регулярное выражение (4) при правила переключения между virtualhost.conf и .htaccess.
Ваше право: я могу изменить журнал ошибок для каждого виртуального хоста, но я не могу отделить перезапись от других ошибок без использования терминала. И да, эти инструменты не самые лучшие для конкретной потребности. Но не всегда возможно создать виртуальную машину для проверки перезаписи, и я постараюсь чаще использовать RewriteBase, чтобы сохранить охват в определенном каталоге.
Попробуйте:
RewriteRule ^(.+?)/?$ some/folders/$1 [L]