Скрытые возможности mod_rewrite

Где размещать правила mod_rewrite

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

Регистрация запросов mod_rewrite

Ведение журнала можно включить из файла httpd.conf (включая <Virtual Host>):

# logs can't be enabled from .htaccess
# loglevel > 2 is really spammy!
RewriteLog /path/to/rewrite.log
RewriteLogLevel 2

Общие варианты использования

1. Чтобы направить все запросы в одну точку:

   RewriteEngine on
   # ignore existing files
   RewriteCond %{REQUEST_FILENAME} !-f   
   # ignore existing directories
   RewriteCond %{REQUEST_FILENAME} !-d   
   # map requests to index.php and append as a query string
   RewriteRule ^(.*)$ index.php?query=$1 
   

   Начиная с Apache 2.2.16 вы также можете использовать FallbackResource.

2. Обработка 301/302 редиректов:

   RewriteEngine on
   # 302 Temporary Redirect (302 is the default, but can be specified for clarity)
   RewriteRule ^oldpage\.html$ /newpage.html [R=302]  
   # 301 Permanent Redirect
   RewriteRule ^oldpage2\.html$ /newpage.html [R=301] 
   

   Примечание: внешние перенаправления неявно являются перенаправлениями 302:

   # this rule:
   RewriteRule ^somepage\.html$ http://google.com
   # is equivalent to:
   RewriteRule ^somepage\.html$ http://google.com [R]
   # and:
   RewriteRule ^somepage\.html$ http://google.com [R=302]
   

3. Принудительный SSL

   RewriteEngine on
   RewriteCond %{HTTPS} off
   RewriteRule ^(.*)$ https://example.com/$1 [R,L]
   

4. Общие флаги:

   • [R] or [redirect] - force a redirect (defaults to a 302 temporary redirect)
   • [R=301] или [redirect=301] — принудительная постоянная переадресация 301
   • [L] или [last] - остановить процесс перезаписи (см. примечание ниже в общих ловушках)
   • [NC] или [nocase] — укажите, что соответствие должно быть нечувствительным к регистру.

   
   Полная форма флагов часто более удобочитаема и поможет другим, кто будет читать ваш код позже.

   Вы можете разделить несколько флагов запятой:

   RewriteRule ^olddir(.*)$ /newdir$1 [L,NC]
   

Распространенные подводные камни

1. Смешивание стилей переадресации mod_alias с переадресацией mod_rewrite

   # Bad
   Redirect 302 /somepage.html http://example.com/otherpage.html
   RewriteEngine on
   RewriteRule ^(.*)$ index.php?query=$1
   
   # Good (use mod_rewrite for both)
   RewriteEngine on
   # 302 redirect and stop processing
   RewriteRule ^somepage.html$ /otherpage.html [R=302,L] 
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteCond %{REQUEST_FILENAME} !-d
   # handle other redirects
   RewriteRule ^(.*)$ index.php?query=$1                 
   

   Примечание: вы можете смешивать mod_alias с mod_rewrite, но это требует больше работы, чем просто обработка базовых перенаправлений, как описано выше.

2. Контекст влияет на синтаксис

   В файлах .htaccess косая черта не используется в шаблоне RewriteRule:

   # given: GET /directory/file.html
   
   # .htaccess
   # result: /newdirectory/file.html
   RewriteRule ^directory(.*)$ /newdirectory$1
   
   # .htaccess
   # result: no match!
   RewriteRule ^/directory(.*)$ /newdirectory$1
   
   # httpd.conf
   # result: /newdirectory/file.html
   RewriteRule ^/directory(.*)$ /newdirectory$1
   
   # Putting a "?" after the slash will allow it to work in both contexts:
   RewriteRule ^/?directory(.*)$ /newdirectory$1
   

3. [L] не последний! (иногда)

   Флаг [L] останавливает обработку любых дальнейших правил перезаписи для этого прохода через набор правил. Однако, если URL-адрес был изменен в этом проходе, и вы находитесь в контексте .htaccess или в разделе <Directory>, тогда ваш измененный запрос будет снова передан обратно через механизм анализа URL-адресов. И на следующем проходе на этот раз он может соответствовать другому правилу. Если вы этого не понимаете, часто кажется, что ваш флаг [L] не действует.

   # processing does not stop here
   RewriteRule ^dirA$ /dirB [L] 
   # /dirC will be the final result
   RewriteRule ^dirB$ /dirC     
   

   Наш журнал перезаписи показывает, что правила выполняются дважды и URL-адрес обновляется дважды:

   rewrite 'dirA' -> '/dirB'
   internal redirect with /dirB [INTERNAL REDIRECT]
   rewrite 'dirB' -> '/dirC'
   

   Лучше всего использовать флаг [END] (см. документацию по Apache) вместо флага [L], если вы действительно хотите остановить всю дальнейшую обработку правил (и последующие проходы). Однако флаг [END] доступен только для Apache версии 2.3.9+, поэтому, если у вас версия 2.2 или ниже, вы застряли только с флагом [L].

   Для более ранних версий вы должны полагаться на операторы RewriteCond, чтобы предотвратить сопоставление правил при последующих проходах механизма синтаксического анализа URL.

   # Only process the following RewriteRule if on the first pass
   RewriteCond %{ENV:REDIRECT_STATUS} ^$
   RewriteRule ...
   

   Или вы должны убедиться, что ваши RewriteRule находятся в контексте (например, httpd.conf), который не приведет к повторному анализу вашего запроса.

если вам нужно «заблокировать» внутренние перенаправления / перезаписи в .htaccess, взгляните на

RewriteCond %{ENV:REDIRECT_STATUS} ^$

условие, как описано здесь.

Сделка с RewriteBase:

Вам почти всегда нужно установить RewriteBase. Если вы этого не сделаете, apache догадается, что ваша база — это путь физического диска к вашему каталогу. Итак, начните с этого:

RewriteBase /

Другие подводные камни:

1- Иногда полезно отключить MultiViews

Options -MultiViews

Я не очень хорошо разбираюсь во всех возможностях MultiViews, но я знаю, что он портит мои правила mod_rewrite, когда он активен, потому что одно из его свойств — попытаться «угадать» расширение файла, который, по его мнению, я ищу. .

Я объясню: предположим, у вас есть 2 файла php в вашем веб-каталоге, file1.php и file2.php, и вы добавляете эти условия и правило в свой .htaccess :

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ file1.php/$1 

Вы предполагаете, что все URL-адреса, которые не соответствуют файлу или каталогу, будут захвачены file1.php. Сюрприз! Это правило не соблюдается для URL-адреса http://myhost/file2/somepath. Вместо этого вы попадаете внутрь file2.php.

Что происходит, так это то, что MultiViews автоматически догадался, что URL-адрес, который вам действительно нужен, был http://myhost/file2.php/somepath и с радостью пригласил вас туда.

Теперь вы понятия не имеете, что только что произошло, и в этот момент вы подвергаете сомнению все, что, как вам казалось, вы знали о mod_rewrite. Затем вы начинаете играть с правилами, пытаясь понять логику этой новой ситуации, но чем больше вы тестируете, тем меньше в ней смысла.

Хорошо, короче говоря, если вы хотите, чтобы mod_rewrite работал примерно по логике, отключение MultiViews — это шаг в правильном направлении.

2- включить FollowSymlinks

Options +FollowSymLinks 

Я не знаю подробностей об этом, но я много раз видел его упоминания, так что просто сделайте это.

Уравнение можно составить на следующем примере:

RewriteCond %{REQUEST_URI} ^/(server0|server1).*$ [NC]
# %1 is the string that was found above
# %1<>%{HTTP_COOKIE} concatenates first macht with mod_rewrite variable -> "test0<>foo=bar;"
#RewriteCond search for a (.*) in the second part -> \1 is a reference to (.*)
# <> is used as an string separator/indicator, can be replaced by any other character
RewriteCond %1<>%{HTTP_COOKIE} !^(.*)<>.*stickysession=\1.*$ [NC]
RewriteRule ^(.*)$ https://notmatch.domain.com/ [R=301,L]

Динамическая балансировка нагрузки:

Если вы используете mod_proxy для балансировки вашей системы, можно добавить динамический диапазон рабочего сервера.

RewriteCond %{HTTP_COOKIE} ^.*stickysession=route\.server([0-9]{1,2}).*$ [NC]
RewriteRule (.*) https://worker%1.internal.com/$1 [P,L]

Необходимо лучше понять флаг [L]. Флаг [L] является последним, вам просто нужно понять, что заставит ваш запрос снова пройти через механизм анализа URL. Из документов (http://httpd.apache.org/docs/2.2/rewrite/flags.html#flag_l) (выделено мной):

Флаг [L] заставляет mod_rewrite прекратить обработку набора правил. В большинстве случаев это означает, что если правило совпадает, дальнейшие правила обрабатываться не будут. Это соответствует последней команде в Perl или команде break в C. Используйте этот флаг, чтобы указать, что текущее правило должно быть применено немедленно, без учета дополнительных правил.

Если вы используете RewriteRule либо в файлах .htaccess, либо в <Directory> разделах, важно понимать, как обрабатываются правила. Упрощенная форма этого заключается в том, что после обработки правил переписанный запрос возвращается механизму синтаксического анализа URL, чтобы сделать с ним все, что возможно. Возможно, что при обработке переписанного запроса файл .htaccess или раздел <Directory> могут снова встретиться, и, таким образом, набор правил может быть запущен снова с самого начала. Чаще всего это происходит, если одно из правил вызывает перенаправление (внутреннее или внешнее), в результате чего процесс запроса начинается заново.

Таким образом, флаг [L] действительно останавливает обработку любых дальнейших правил перезаписи для которые проходят через набор правил. Однако, если ваше правило, отмеченное [L], изменило запрос, и вы находитесь в контексте .htaccess или в разделе <Directory>, тогда ваш измененный запрос будет снова передан обратно через механизм синтаксического анализа URL. И на следующем проходе на этот раз он может соответствовать другому правилу. Если вы не понимаете, что произошло, похоже, ваше первое правило перезаписи с флагом [L] не сработало.

Лучше всего использовать флаг [END] (http://httpd.apache.org/docs/current/rewrite/flags.html#flag_end) вместо флага [L], если вы действительно хотите остановить всю дальнейшую обработку правил (и последующую повторную обработку). Однако флаг [END] доступен только для Apache v2.3.9+, поэтому, если у вас v2.2 или ниже, вы застряли только с флагом [L]. В этом случае вы должны полагаться на операторы RewriteCond, чтобы предотвратить сопоставление правил при последующих проходах механизма синтаксического анализа URL. Или вы должны убедиться, что ваши RewriteRule находятся в контексте (например, httpd.conf), который не приведет к повторному анализу вашего запроса.

Еще одна замечательная функция — переписать карты-расширения. Они особенно полезны, если вам нужно обработать огромное количество хостов/перезаписей:

Они похожи на замену ключ-значение:

RewriteMap examplemap txt:/path/to/file/map.txt

Затем вы можете использовать сопоставление в своих правилах, например:

RewriteRule ^/ex/(.*) ${examplemap:$1}

Более подробную информацию по этой теме можно найти здесь:

http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html#mapfunc

mod_rewrite может изменять аспекты обработки запросов без изменения URL-адреса, например. установка переменных среды, установка файлов cookie и т. д. Это невероятно полезно.

Условно установите переменную среды:

RewriteCond %{HTTP_COOKIE} myCookie=(a|b) [NC]
RewriteRule .* - [E=MY_ENV_VAR:%b]

Вернуть ответ 503: флаг [R] RewriteRule может принимать значение, отличное от 3xx, и возвращать ответ без перенаправления, например. для управляемого простоя/обслуживания:

RewriteRule .* - [R=503,L]

вернет ответ 503 (не перенаправление как таковое).

Кроме того, mod_rewrite может действовать как сверхмощный интерфейс для mod_proxy, так что вы можете сделать это вместо того, чтобы писать директивы ProxyPass:

RewriteRule ^/(.*)$ balancer://cluster%{REQUEST_URI} [P,QSA,L]

Мнение: использование RewriteRules и RewriteConds для маршрутизации запросов к различным приложениям или балансировщикам нагрузки на основе практически любого мыслимого аспекта запроса просто невероятно эффективно. Контроль запросов на пути к серверу и возможность изменять ответы на обратном пути делают mod_rewrite идеальным местом для централизации всей конфигурации, связанной с маршрутизацией.

Потратьте время, чтобы изучить его, это того стоит! :)