Проблемы с перезаписью модов (Apache) с / косыми чертами

Question

Ставлю на очевидную проблему, которую здесь не вижу.

Вот важные сведения для тех, кто знаком с Mod-Rewrite

.htaccess файл с правилами перезаписи модов существует здесь: http://www.thedomain.com/.htaccess Пользователь переходит на этот URL: http://www.thedomain.com/test/blog Правила Mod-Rewrite должны указывать серверу доступ к этому URL: http://www.thedomain.com/index.php?page=blog

.htaccess:

Options FollowSymLinks
Options -MultiViews
RewriteEngine on
RewriteRule ^test/([^/.]+)$ /index.php?page=$1 [L]

Эта комбинация кода / запроса не работает. Если вас интересует, что фрагмент кода ^ test не является ^ / test, это потому, что, очевидно, это проблема в GoDaddy, код завершается ошибкой с / после ^ - кажется, это может быть связано с моей проблемой, который я объясню дальше ... Если я изменю строку кода .htaccess:

RewriteRule ^test/([^/.]+)$ /index.php?page=$1 [L]

до

RewriteRule ^test([^/.]+)$ /index.php?page=$1 [L]

(просто удалив / здесь: ^ test /([^/.]+))

Код работает, когда запрашиваемый URL-адрес изменяется для размещения (удалите косую черту; http://www.thedomain.com/testblog), поскольку пользователь просматривает правильный index.php? Page = ответ сервера блога. Мне кажется, я не могу использовать любые косые черты в пределах проклятой стороны RewriteRule. Что дает?

Обновление: Если это вообще необходимо, этот файл .htaccess и соответствующие файлы вопроса существуют в подкаталоге сервера GoDaddy, на котором он размещен, хотя домен указывает на подкаталог как корень. Не уверен, что это актуально.

Обновление: Этот сервер (в корне сервера) на самом деле работает под управлением WordPress с включенными симпатичными URL-адресами, и они прекрасно работают. Я предполагаю, что WordPress использует mod-rewrite для создания сумасшедших URL-адресов, например thedomain.com/2008/11/15/the-article-title.html work ...?

Большое спасибо.

Answer 1

здесь есть хорошая тестовая утилита для окон

http://www.helicontech.com/download-isapi_rewrite.htm

попробуйте изменить код на:

^/test/([^/]+)$ /index.php?page=$1 [L]

или без слешей

^test[^a-z]+([a-z]*)$ /index.php?page=$1 [L]

Answer 2

Является ли RewriteBase тем, что вы ищете?

Answer 3

Мне не удалось найти надежный метод решения этой проблемы на GoDaddy; по любой причине у меня не могло быть косых черт в URL, который пытался переписать, кроме базы (http://www.somedomain.com/testingthis сработало бы, но http://www.somedomain.com/testing/this умерло)

В итоге я вместо этого использовал WordPress .htaccess для отправки всех несуществующих запросов файлов / каталогов обратно в мой index.php. Затем я использовал переменную $ _SERVER ['REQUEST_URI'] с pathinfo (), чтобы проанализировать URL-адрес, а затем указать, какой контент загрузить из анализа. Это работает хорошо, быстро и, вероятно, тот же метод, который использует Wordpress.

Спасибо за попытки!

Answer 4

ОК, во-первых, я думаю, что на сервере Apache GoDaddy просто отключены некоторые параметры. Я думаю, что если у них нет AllowOverride FileInfo в их конфигурации, RewriteRule не будет работать так хорошо, или вообще не будет.

Что удивительно, что URL http://www.thedomain.com/testblog работает вообще и переписывается. Так что, думаю, я немного растерялся.

Вот идея: попробуйте создать каталог с именем test и поместите туда файл .htaccess! Это будет выглядеть так:

Options FollowSymLinks
RewriteEngine on
RewriteRule ^([^/]+)$ /index.php?page=$1 [L]

ОК, другая идея: используйте RewriteCond. Может быть, вы можете проверить URI запроса напрямую, например:

Options FollowSymLinks
RewriteEngine on
RewriteCond %{REQUEST_URI} ^/test/([^/]+)
RewriteRule . /index.php?page=%1 [L]

Последняя идея: возможно, ваш браузер видит URL http://www.thedomain.com/test/blog и считает, что это каталог, и добавляет косую черту? Таким образом, URL отправляет http://www.thedomain.com/test/blog/. В этом случае REGEX не будет совпадать, если вы не разрешите использовать косую черту:

RewriteRule ^test/([^/.]+)/?$ /index.php?page=$1 [L]

Упс. Приносим извинения за прилив - в HTTP-запросе, который проходит через переписывание, есть только несколько вещей, которые могут пойти не так, и так же много способов решить проблемы: -)

Answer 5

Если вас интересует, что фрагмент кода ^ test не является ^ / test вместо этого, это потому, что, очевидно, это проблема в GoDaddy, код завершается с / после ^ […]

Это не странно, но необходимо:

Перезаписей по каталогам

При использовании механизма перезаписи в .htaccess файлах префикс для каждого каталога (который всегда одинаков для определенного каталога) автоматически удаляется для сопоставления с шаблоном и автоматически добавляется после замены.

И этот префикс для каждого каталога предназначен для файла .htaccess в корне документа (/.htaccess) в корне пути URL (/). Таким образом, шаблоны с ^ должны быть записаны без этого префикса для каждого каталога /.

Аналогичным образом обрабатывается замена . После применения правила к замене добавляется префикс для каждого каталога . Поэтому попробуйте это правило:

RewriteRule ^test/([^/.]+)$ index.php?page=$1 [L]