Вопрос или проблема
Я установил веб-сайт в каталоге своего домена, например, example.com/website
.
Главная проблема в том, что он перенаправляет меня на example.com/website/
.
Я не хочу перенаправления и хочу, чтобы мой субкаталог веб-сайт никогда не перенаправлялся.
Я хочу, чтобы пользователь мог зайти на мой веб-сайт без последней косой черты, то есть example.com/website
.
Могу ли я сделать это с помощью функции PHP или, пожалуйста, поделитесь кодом .htaccess
, если это возможно.
Я прочитал много статей и даже вопросы пользователей на Stack Exchange, связанные с завершающей косой чертой, но это не помогло.
Также я пробовал различные коды .htaccess
, но это не помогло.
Пожалуйста, помогите мне с этим.
Основная проблема в том, что он перенаправляет меня на
example.com/website/
По умолчанию Apache (mod_dir) «исправляет» URL, выполняя перенаправление 301, чтобы добавить завершающую косую черту, если она пропущена в каталоге файловой системы. Это необходимо для правильного функционирования других функций Apache…
-
без завершающей косой черты документ
DirectoryIndex
не будет обслуживаться, и вернется ответ 403 Forbidden (если толькоOptions Indexes
не включен, в этом случае вы получите список каталогов, несмотря на наличие индексного документа – потенциальная уязвимость безопасности, см. ниже). -
Если запрос –
/website
(без завершающей косой черты), то директивы mod_rewrite в файле/website/.htaccess
не будут выполнены (поэтому фронт-контроллер WordPress не сработает).
Можно предотвратить добавление Apache (mod_dir) завершающей косой черты к каталогу /website
(используя DirectorySlash Off
), однако затем нужно будет предпринять дополнительные шаги, чтобы обойти вышеупомянутые проблемы и вручную добавить завершающую косую черту (или переписать URL напрямую к фронт-контроллеру WP) с внутренним переписыванием. Это нельзя сделать из файла /website/.htaccess
– это необходимо переместить в корень документа (родительский каталог).
Например:
-
Переместите уже существующий файл WordPress
/website/.htaccess
в родительский каталог (корень документа), то есть/.htaccess
. -
Затем необходимо внести такие изменения в файл
/.htaccess
и фронт-контроллер WordPress:
# mod_autoindex должен быть отключен
# Иначе ваш сайт будет уязвим к "раскрытию информации"
Options -Indexes
# Предотвратить добавление mod_dir завершающей косой черты к каталогам файловой системы
DirectorySlash Off
# BEGIN WordPress
RewriteEngine On
RewriteBase /website
# Удалить завершающую косую черту из "/website/", если обратиться напрямую
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteRule ^(website)/$ /$1 [R=301,L]
# Направляем запросы для самого каталога (то есть "домашняя страница")
# (DirectoryIndex иначе не срабатывает.)
RewriteRule ^website/?$ index.php [L]
# Фронт-контроллер для всех других URL-ов вида "/website/<something>"
RewriteRule ^[^/]+/index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^website/. index.php [L]
# END WordPress
Так как нам пришлось настраивать секцию # BEGIN WordPress
, вы должны предотвратить перезапись WordPress этого и создания другого (по умолчанию) файла .htaccess
в подкаталоге /website/
.
Вышеописанное также канонизирует любые запросы для /website/
(с завершающей косой чертой) и перенаправляет на /website
, чтобы убрать завершающую косую черту. Вы должны сначала протестировать с перенаправлением 302 (временное), чтобы избежать потенциальных проблем с кэшированием.
Вам нужно будет очистить кеш браузера перед тестированием, так как предыдущий 301 редирект (mod_dir/Apache) для добавления завершающей косой черты был сохранен в кэше браузера.
Обратите внимание, что директива DirectorySlash Off
применяется ко всем подкаталогам. Поэтому, если какие-либо другие подкаталоги должны быть доступны (я думаю, маловероятно), вам нужно будет принять дополнительные меры.
Могу ли я сделать это с помощью функции PHP
Добавление завершающей косой черты не связано с PHP – это «функция» Apache. Однако, вам нужно убедиться, что WordPress все еще может маршрутизировать URL, так как запрашиваемый путь URL теперь /website
, а не /website/
(который технически является другим URL).
Источник:
- https://httpd.apache.org/docs/2.4/mod/mod_dir.html#directoryslash
Обратите внимание на предупреждение о безопасности на этой странице, о котором я упомянул выше:
Предупреждение о безопасности
Отключение перенаправления с завершающей косой чертой может привести к
раскрытию информации. Рассмотрите ситуацию, когда mod_autoindex
активен (Options +Indexes), и DirectoryIndex настроен на
действительный ресурс (например, index.html), и нет другого
специального обработчика, определенного для этого URL. В этом случае
запрос с завершающей косой чертой покажет файл index.html. Но запрос
без завершающей косой черты приведет к отображению содержимого
каталога.
Ответ или решение
Чтобы решить проблему, описанную в вопросе, необходимо понять, как веб-сервер Apache обрабатывает URL, связанные с каталогами. По умолчанию Apache, используя модуль mod_dir, автоматически добавляет завершающий слэш к URL, если он отсутствует. Это связано с несколькими аспектами функционирования сервера и безопасности, которые мы обсудим ниже. Однако, если у вас есть конкретное требование избегать этой автоматической переадресации на URL с завершающим слэшем, это можно реализовать с помощью корректировки конфигурации сервера и файла .htaccess
.
Теория
Apache добавляет завершающий слэш по следующим причинам:
-
Безопасность и доступность:
- Если у каталога
/website
отсутствует завершающий слэш, сервер может вернуть ответ 403 Forbidden, если конфигурация не предусматривает иное. - Без завершающего слэша модули, такие как mod_rewrite, определяют каталог как файл, и это может привести к неработоспособности механизмов, таких как "фронт-контроллер" в WordPress.
- Если у каталога
-
Функции "index":
- Когда завершающий слэш отсутствует, сервер не сможет корректно вызвать
DirectoryIndex
, что может привести либо к отображению содержимого каталога (если включена опция Indexes), либо к ошибке доступа. Это также может стать источником утечки информации.
- Когда завершающий слэш отсутствует, сервер не сможет корректно вызвать
Пример
Для решения этой задачи потребуется внести изменения в файл .htaccess
, что обеспечит:
-
Отключение автоматического добавления слэша:
- Использование
DirectorySlash Off
отключит автоматическое добавление слэша к URL, указывающим на каталог.
- Использование
-
Настройка перенаправления:
- Перенаправление запросов, которые заканчиваются слэшом, на URL без него, используя правила mod_rewrite для корректного функционирования WordPress.
Пример корректировки файла .htaccess
выглядит следующим образом:
# Отключаем отображение содержимого каталогов
Options -Indexes
# Отключаем добавление завершающего слэша
DirectorySlash Off
# Начало раздела WordPress
RewriteEngine On
RewriteBase /website
# Удаление завершающего слэша из "/website/", если запрашивается напрямую
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteRule ^(website)/$ /$1 [R=301,L]
# Маршрутизация запросов для самого каталога (то есть домашней страницы)
RewriteRule ^website/?$ index.php [L]
# Фронт-контроллер для всех остальных URL вида "/website/<что-то>"
RewriteRule ^[^/]+/index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^website/. index.php [L]
# Конец раздела WordPress
Применение
После настройки файла .htaccess
вы должны убедиться в следующих моментах:
-
Предотвращение перезаписи WordPress:
- Убедитесь, что WordPress не перезаписывает ваш файл
.htaccess
, добавляя собственные правила, что может привести к нежелательным переадресациям.
- Убедитесь, что WordPress не перезаписывает ваш файл
-
Очистка кеша браузера:
- Очистите кеш браузера перед тестированием изменений, так как предыдущие 301 перенаправления могли быть закэшированы.
-
Учтите последствия для подкаталогов:
DirectorySlash Off
будет применено ко всем подкаталогам. Если какие-то из них должны быть доступны, необходимо будет настроить дополнительные правила.
Заключение:
Если вы действуете сознательно, избегая доменных завершающих слэшей, вы принимаете на себя обязательства по поддерживанию безопасности и функциональности вашего сайта путем более детального контроля за URL и их маршрутизацией. Всегда проводите тестирование после внесения изменений и следите за тем, чтобы настройки безопасности сервера оставались надежными.
Ссылки для дальнейшего изучения:
Помните, что вмешательство в настройки веб-сервера требует тщательного подхода и понимания безопасности, так как может привести к непреднамеренным последствиям.