Почему ведущий слеш не соответствует моему RewriteRule?

Question

Почему ведущий слеш не соответствует моему RewriteRule?

1

Надеюсь, я упустил что-то глупое.

Я пытаюсь перенаправить URL-адреса, используя.htaccess на Apache 2.2, используя патч PHP 5.4 на бесплатном хостинге OpenShift.

Это соответствует URI/permalink/a123 (обратите внимание на отсутствие ведущей косой черты в шаблоне фильтра правил):

RewriteEngine On
RewriteRule permalink/a.*$ /permalink/b [R=301,L]

Это не соответствует URI/permalink/a123 (обратите внимание на косую черту в шаблоне фильтра правил):

RewriteEngine On
RewriteRule /permalink/a.*$ /permalink/b [R=301,L]

Итак, какая глупость у меня есть?

Благодарю.

J. B. Rainsberger 06 янв. 2016, в 21:06

Источник

0

Я проверил: ^ постоянная ссылка / a. * $ Соответствует, но ^ / постоянная ссылка / a. * $ Не соответствует. Может ли быть так, что PHP-картридж OpenShift PHP 5.4 удаляет меня и не говорит? Я не нашел ни одного файла конфигурации, который бы содержал такие директивы, но, возможно, я не знаю, где искать.
J. B. Rainsberger 06 янв. 2016, в 19:42
2

Начальный слеш подразумевается. Если вы хотите, чтобы оно было изменено, вы должны использовать RewriteBase / чтобы изменить базовое местоположение, к которому применяется правило.
Jon 06 янв. 2016, в 19:51
0

Используйте /permalink/(.*)$
devpro 06 янв. 2016, в 19:52
1

Начальная косая черта удаляется в RewriteRule (если используется в .htaccess)
anubhava 06 янв. 2016, в 19:53
0

<code> RewriteBase / </ code> выглядит как разница между этим файлом .htaccess, который ведет себя вопреки моим (теперь старым) ожиданиям, и файлом .htaccess на другом сервере, который ведет себя так, как я привык ожидать. Спасибо тебе за это.
J. B. Rainsberger 07 янв. 2016, в 23:16

Показать ещё 3 комментария

Теги:

php

apache

.htaccess

mod-rewrite

openshift

1 ответ

Ещё вопросы

Я проверил: ^ постоянная ссылка / a. * $ Соответствует, но ^ / постоянная ссылка / a. * $ Не соответствует. Может ли быть так, что PHP-картридж OpenShift PHP 5.4 удаляет меня и не говорит? Я не нашел ни одного файла конфигурации, который бы содержал такие директивы, но, возможно, я не знаю, где искать.
Начальный слеш подразумевается. Если вы хотите, чтобы оно было изменено, вы должны использовать RewriteBase / чтобы изменить базовое местоположение, к которому применяется правило.
Начальная косая черта удаляется в RewriteRule (если используется в .htaccess)
<code> RewriteBase / </ code> выглядит как разница между этим файлом .htaccess, который ведет себя вопреки моим (теперь старым) ожиданиям, и файлом .htaccess на другом сервере, который ведет себя так, как я привык ожидать. Спасибо тебе за это.

Jon Lin · Accepted Answer · 2016-01-06T19-07-00.000Z

URI, используемый для сопоставления шаблонов в RewriteRule, канонизируется в контексте для каждого каталога (либо в файле htaccess, либо в контейнере <Directory>), удаляя ведущий /. Поэтому, если запрашиваемый URL-адрес:

http://example.com/web/permalink/123

И из файла htaccess в корневом каталоге документа URI, используемый для соответствия правилам, является web/permalink/123. Но в файле htaccess в web папке URI является permalink/123 и т.д.

Таким образом, вы не можете создавать свои шаблоны с помощью / поскольку они удаляются из URI в контексте файла htaccess.

Все это имеет смысл, но не объясняет, почему у меня есть другой .htaccess в корне документа, который сопоставляет шаблоны с ведущей косой чертой. Теперь я вижу одно различие, упомянутое здесь в другом месте: <code> RewriteBase / </ code>. У меня есть эта директива в файле .htaccess в корне документа, который соответствует URI с ведущей косой чертой. Я предполагаю, что это важная информация, которую я пропустил. Тем не менее, я думаю, что понимаю, почему я не должен использовать начальную косую черту в этих шаблонах URI.
@JBRainsberger Директива RewriteBase не влияет на косую черту в шаблоне правила перезаписи, она влияет на цель правила (добавляет базу к относительным целям). Разница, вероятно, в RewriteRule /foo против RewriteRule ^/foo . Первый соответствует любому /foo любом месте URI, второй имеет ^ и соответствует только началу URI, и потерпит неудачу, потому что начало не имеет / .
Кристально чистый. Благодарю. Я думаю, я наконец понял.