rewriteengine on что это

Apache Module mod_rewrite

Summary

The mod_rewrite module uses a rule-based rewriting engine, based on a PCRE regular-expression parser, to rewrite requested URLs on the fly. By default, mod_rewrite maps a URL to a filesystem path. However, it can also be used to redirect one URL to another URL, or to invoke an internal proxy fetch.

mod_rewrite provides a flexible and powerful way to manipulate URLs using an unlimited number of rules. Each rule can have an unlimited number of attached rule conditions, to allow you to rewrite URL based on server variables, environment variables, HTTP headers, or time stamps.

Further details, discussion, and examples, are provided in the detailed mod_rewrite documentation.

Topics

Directives

Bugfix checklist

See also

Logging

Example

RewriteLog

Those familiar with earlier versions of mod_rewrite will no doubt be looking for the RewriteLog and RewriteLogLevel directives. This functionality has been completely replaced by the new per-module logging configuration mentioned above.

RewriteBase Directive

The RewriteBase directive specifies the URL prefix to be used for per-directory (htaccess) RewriteRule directives that substitute a relative path.

This directive is required when you use a relative path in a substitution in per-directory (htaccess) context unless any of the following conditions are true:

In the example below, RewriteBase is necessary to avoid rewriting to http://example.com/opt/myapp-1.2.3/welcome.html since the resource was not relative to the document root. This misconfiguration would normally cause the server to look for an «opt» directory under the document root.

RewriteCond Directive

The RewriteCond directive defines a rule condition. One or more RewriteCond can precede a RewriteRule directive. The following rule is then only used if both the current state of the URI matches its pattern, and if these conditions are met.

TestString is a string which can contain the following expanded constructs in addition to plain text:

These variables all correspond to the similarly named HTTP MIME-headers, C variables of the Apache HTTP Server or struct tm fields of the Unix system. Most are documented here or elsewhere in the Manual or in the CGI specification.

SERVER_NAME and SERVER_PORT depend on the values of UseCanonicalName and UseCanonicalPhysicalPort respectively.

Those that are special to mod_rewrite include those below.

Other things you should be aware of:

If a substitution occurred and the rewriting continues, the value of both variables will be updated accordingly.

If used in per-server context (i.e., before the request is mapped to the filesystem) SCRIPT_FILENAME and REQUEST_FILENAME cannot contain the full local filesystem path since the path is unknown at this stage of processing. Both variables will initially contain the value of REQUEST_URI in that case. In order to obtain the full local filesystem path of the request in per-server context, use an URL-based look-ahead % to determine the final value of REQUEST_FILENAME.

If a HTTP header is used in a condition this header is added to the Vary header of the response in case the condition evaluates to true for the request. It is not added if the condition evaluates to false for the request. Adding the HTTP header to the Vary header of the response is needed for proper caching.

It has to be kept in mind that conditions follow a short circuit logic in the case of the ‘ ornext|OR ‘ flag so that certain conditions might not be evaluated at all.

For instance, to rewrite according to the REMOTE_USER variable from within the per-server context ( httpd.conf file) you must use % — this variable is set by the authorization phases, which come after the URL translation phase (during which mod_rewrite operates).

CondPattern is the condition pattern, a regular expression which is applied to the current instance of the TestString. TestString is first evaluated, before being matched against CondPattern.

CondPattern is usually a perl compatible regular expression, but there is additional syntax available to perform other useful tests against the Teststring:

This flag only returns information about things like access control, authentication, and authorization. This flag does not return information about the status code the configured handler (static file, CGI, proxy, etc.) would have returned.

-x Has executable permissions.
Treats the TestString as a pathname and tests whether or not it exists, and has executable permissions. These permissions are determined according to the underlying OS. For example:

You can also set special flags for CondPattern by appending [ flags ] as the third argument to the RewriteCond directive, where flags is a comma-separated list of any of the following flags:

Example:

To rewrite the Homepage of a site according to the « User-Agent: » header of the request, you can use the following:

Explanation: If you use a browser which identifies itself as a mobile browser (note that the example is incomplete, as there are many other mobile platforms), the mobile version of the homepage is served. Otherwise, the standard page is served.

RewriteEngine Directive

The RewriteEngine directive enables or disables the runtime rewriting engine. If it is set to off this module does no runtime processing at all. It does not even update the SCRIPT_URx environment variables.

Use this directive to disable rules in a particular context, rather than commenting out all the RewriteRule directives.

Note that rewrite configurations are not inherited by virtual hosts. This means that you need to have a RewriteEngine on directive for each virtual host in which you wish to use rewrite rules.

RewriteMap directives of the type prg are not started during server initialization if they’re defined in a context that does not have RewriteEngine set to on

RewriteMap Directive

The RewriteMap directive defines a Rewriting Map which can be used inside rule substitution strings by the mapping-functions to insert/substitute fields through a key lookup. The source of this lookup can be of various types.

The MapName is the name of the map and will be used to specify a mapping-function for the substitution strings of a rewriting rule via one of the following constructs:

$< MapName : LookupKey >
$< MapName : LookupKey | DefaultValue >

When such a construct occurs, the map MapName is consulted and the key LookupKey is looked-up. If the key is found, the map-function construct is substituted by SubstValue. If the key is not found then it is substituted by DefaultValue or by the empty string if no DefaultValue was specified. Empty values behave as if the key was absent, therefore it is not possible to distinguish between empty-valued keys and absent keys.

For example, you might define a RewriteMap as:

You would then be able to use this map in a RewriteRule as follows:

The meaning of the MapTypeOptions argument depends on particular MapType. See the Using RewriteMap for more information.

The following combinations for MapType and MapSource can be used:

Further details, and numerous examples, may be found in the RewriteMap HowTo

RewriteOptions Directive

The RewriteOptions directive sets some special options for the current per-server or per-directory configuration. The Option string can currently only be one of the following:

Like Inherit above, but the rules from the parent scope are applied before rules specified in the child scope.
Available in Apache HTTP Server 2.3.10 and later.

If this option is enabled, all child configurations will inherit the configuration of the current configuration. It is equivalent to specifying RewriteOptions Inherit in all child configurations. See the Inherit option for more details on how the parent-child relationships are handled.
Available in Apache HTTP Server 2.4.8 and later.

Like InheritDown above, but the rules from the current scope are applied before rules specified in any child’s scope.
Available in Apache HTTP Server 2.4.8 and later.

By default, mod_rewrite will ignore URLs that map to a directory on disk but lack a trailing slash, in the expectation that the mod_dir module will issue the client with a redirect to the canonical URL with a trailing slash.

When RewriteRule is used in VirtualHost or server context with version 2.2.22 or later of httpd, mod_rewrite will only process the rewrite rules if the request URI is a URL-path. This avoids some security issues where particular rules could allow «surprising» pattern expansions (see CVE-2011-3368 and CVE-2011-4317). To lift the restriction on matching a URL-path, the AllowAnyURI option can be enabled, and mod_rewrite will apply the rule set to any request URI string, regardless of whether that string matches the URL-path grammar required by the HTTP specification.
Available in Apache HTTP Server 2.4.3 and later.

Security Warning

Enabling this option will make the server vulnerable to security issues if used with rewrite rules which are not carefully authored. It is strongly recommended that this option is not used. In particular, beware of input strings containing the ‘ @ ‘ character which could change the interpretation of the transformed URI, as per the above CVE names.

When a relative substitution is made in directory (htaccess) context and RewriteBase has not been set, this module uses some extended URL and filesystem context information to change the relative substitution back into a URL. Modules such as mod_userdir and mod_alias supply this extended context info. Available in 2.4.16 and later.

This option allows the old behavior to be used where the document root is not prefixed to a local path that was reduced from a URL. Available in 2.4.26 and later.

RewriteRule Directive

Pattern is a perl compatible regular expression. What this pattern is compared against varies depending on where the RewriteRule directive is defined.

What is matched?

In VirtualHost context, The Pattern will initially be matched against the part of the URL after the hostname and port, and before the query string (e.g. «/app1/index.html»). This is the (%-decoded) URL-path.

The directory path where the rule is defined is stripped from the currently mapped filesystem path before comparison (up to and including a trailing slash). The net result of this per-directory prefix stripping is that rules in this context only match against the portion of the currently mapped filesystem path «below» where the rule is defined.

If you wish to match against the hostname, port, or query string, use a RewriteCond with the % , % , or % variables respectively.

Per-directory Rewrites

The Substitution of a rewrite rule is the string that replaces the original URL-path that was matched by Pattern. The Substitution may be a:

In addition to plain text, the Substitution string can include

Modifying the Query String

By default, the query string is passed through unchanged. You can, however, create URLs in the substitution string containing a query string part. Simply use a question mark inside the substitution string to indicate that the following text should be re-injected into the query string. When you want to erase an existing query string, end the substitution string with just a question mark. To combine new and old query strings, use the [QSA] flag.

Additionally you can set special actions to be performed by appending [ flags ] as the third argument to the RewriteRule directive. Flags is a comma-separated list, surround by square brackets, of any of the flags in the following table. More details, and examples, for each flag, are available in the Rewrite Flags document.

Home directory expansion

When the substitution string begins with a string resembling «/

This expansion does not occur when the PT flag is used on the RewriteRule directive.

Here are all possible substitution combinations and their meanings:

Inside per-server configuration ( httpd.conf )
for request « GET /somepath/pathinfo »:

Источник

HackWare.ru

Этичный хакинг и тестирование на проникновение, информационная безопасность

Полное руководство по mod_rewrite (часть 1): Как включить и как работает mod_rewrite

Оглавление. Полное руководство по mod_rewrite

8. Директива RewriteOptions, технические подробности, когда НЕ использовать mod_rewrite

Что такое mod_rewrite

mod_rewrite является одним из самых часто используемых модулей веб-сервера Apache. При этом он является и самым непонятным: очень многие ищут подходящие под свои нужды примеры выражений mod_rewrite и копируют их без полного понимания, как именно это работает и что именно происходит при обработке адресов.

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

mod_rewrite предоставляет возможность динамически изменять входящие URL-запросы, основываясь на правилах, использующих регулярные выражения. Это позволяет вам сопоставлять произвольные URL-адреса к вашей внутренней структуре URL любым способом. По умолчанию mod_rewrite сопоставляет URL-адрес пути к файловой системе. Однако он также может использоваться для перенаправления одного URL-адреса на другой URL-адрес или для вызова внутренней прокси передачи.

mod_rewrite предоставляет гибкий и мощный способ манипулирования URL-адресами, используя неограниченное количество правил. Каждое правило может иметь неограниченное количество прикреплённых условий правила, позволяя вам переписать URL на основе переменных сервера, переменных среды, заголовков HTTP, метки времени, запросы к внешним базам данных и различных других внутренних программ и обработчиков.

Правила перезаписи могут оперировать полными URL, включая path-info (информацию о пути) и строку запроса; отдельные правила можно настроить для использоваться в контексте всего сервера, отдельного для каждого виртуального хоста или для каждой директории (папки). Правила перезаписи могут вести к последующим правилам, внутренним подпроцессам, внешним перенаправлениям запросов или проксированию, в зависимости от флагов, которые вы добавили к правилам.

Поскольку mod_rewrite такой мощный, его изучение требует времени. Функциональность mod_rewrite пересекается с некоторыми другими модулями Apache и решение, что именно использовать, за вами. В этой инструкции дан подробный разбор всех возможностей mod_rewrite и показано много примеров, как использовать этот модуль, а когда лучше использовать другие альтернативы.

Для чего нужен mod_rewrite / Что умеет mod_rewrite

Слово «rewrite» в названии модуля буквально означает «перезапись». Эта «перезапись» относится к URL (адресу сайта, страницы, файла). Перезапись (преобразование) происходит между тем, что введено в строке браузера пользователя (фактически, отправлено на веб-сервер) и тем, что веб-сервер получит на самом деле.

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

Слеши (/) на веб-сервере разделяют вложенные подпапки. Но в случае с ЧПУ если в адресе страницы встречается строка /product/phone/Samsung/, то это не означает, что на веб-сайте действительно имеется папка product, в которой подпапка phone и в которой подпапка Samsung. Благодаря mod_rewrite строка вида /product/phone/Samsung/ перезаписывается в строку вида index.php?category=product&type=phone&brand=Samsung. Таким образом, пользователь набирает в веб-браузере, либо переходит по ссылке с удобным для его восприятия адресом, а веб-сервер получает данные в понятном для обработки виде, когда каждой переменной присваивается соответствующее значение и эти переменные передаются в скрипт веб-сервера для обработки, либо отображения информации.

Это очень популярное, но не единственное применение mod_rewrite. Этот модуль умеет делать перезапись на основе разных данных: к примеру, на основе типа браузера. Это позволяет показывать разные страницы в зависимости от типа браузера, IP адреса, языка пользователя, установленных кукиз и т.д.

mod_rewrite умеет делать редирект (перенаправление) на другой адрес. В результате, если ваш сайт переехал на другой домен или поменялась структура сайта, вы можете настроить автоматическую переадресацию со старых адресов страниц на новые.

mod_rewrite умеет запрещать доступ к определённым ресурсам, как по определённому условию, так и безусловно. Т.е. вы можете настроить контроль доступа, закрыв определённые страницы для всех пользователей, либо на основе их стран, языка, веб-браузера и т.д.

На самом деле – это не всё, что умеет mod_rewrite! И даже в этом мануале вы встретитесь с дополнительными примерами применения mod_rewrite.

Прежде чем мы перейдём к теории и практики использования mod_rewrite, нужно включить модуль mod_rewrite для веб-сервера, либо убедиться, что mod_rewrite уже включен. Если вы используетесь shared (совместным) хостингом, то у большинства хостеров этот модуль включен по умолчанию. Ниже показано, как включить этот модуль на своём собственном локальном (домашнем) сервере, либо веб-сервере на VPS.

Включение mod_rewrite

mod_rewrite – это опциональный (необязательный) модуль веб-сервера Apache, который по умолчанию отключён. Поэтому работу с mod_rewrite нужно начать с его включения в веб-сервере.

Начнём с небольшой теории. Правила mod_rewrite для преобразования URL можно описывать как в конфигурационном файле Apache apache2.conf (в некоторых системах называется httpd.conf), так и в файле .htaccess отдельно для каждой директории.

Если вы используете Debian, Ubuntu, Linux Mint, Kali Linux то mod_rewrite можно включить следующей командой:

В Debian, Ubuntu, Linux Mint, Kali Linux эта группа строк выглядит так:

В этой группе строк замените

После чего перезапустите веб-сервер (на некоторых дистрибутивах служба называется не apache2, а httpd):

Если вы используете Apache в Windows, то для включения mod_rewrite в файле httpd.conf (C:\Server\bin\Apache24\conf\httpd.conf) найдите и раскомментируйте строку:

В Windows она может выглядеть так:

В этой группе строк замените

Чтобы любые изменения, сделанные в конфигурационном файле Apache, вступили в силу, нужно перезапустить сервер.

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

Также должна быть включена опция Options FollowSymLinks (по умолчанию она включена). Если FollowSymLinks отключено, то невозможно использовать движок перезаписи. Это ограничение продиктовано причинами безопасности.

Журнал (логи) преобразований mod_rewrite

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

Тема логов Apache сама по себе довольно объёмная, не будем на ней заострять внимание. Но необходимо упомянуть, что если вы работали с предыдущими версиями mod_rewrite и использовали директивы RewriteLog и RewriteLogLevel, то теперь их функциональность полностью заменена директивой LogLevel, которая настраивать логи всего веб-сервера и всех модулей.

По умолчанию LogLevel установлено показывать предупреждение, в конфигурационном файле Apache это строка:

Можно заменить эту строку на:

Она означает, что для всего веб-сервера и остальных модулей настроен уровень журнала «error», т.е. показывать только ошибки и более важные сообщения, а для модуля mod_rewrite установлен уровень трассировки trace2.

mod_rewrite предлагает детальную запись его действий с уровней ведения журнала от trace1 до trace8. Уровень trace8 означает запись практически всех действий. Использование высоких уровней логов трассировки для mod_rewrite драматически замедлит ваш Apache HTTP сервер! Используйте уровень выше чем trace2 только для отладки!

Сообщения о работе mod_rewrite будут записываться в файл ошибок Apache (например, error.log). Чтобы из этого файла отфильтровать только строки, относящиеся к mod_rewrite, можно использовать поиск по «[rewrite:». К примеру, в Linux это можно делать примерно следующей командой:

Директивы RewriteEngine и RewriteRule

Модуль mod_rewrite использует несколько директив, и в этом руководстве мы рассмотрим их все. Но в каждом примере мы неизменно будем использовать две главные директивы, это RewriteEngine и RewriteRule. Первая директива, в виде

просто включает использование mod_rewrite в файле .htaccess.

Значение директивы можно установить на off:

В этом случае правила, которые следуют после отключения RewriteEngine off, не будут задействованы. Отключение RewriteEngine можно использовать вместо удаления или комментирования строк с правилами RewriteRule.

Конфигурации перезаписи не наследуются виртуальными хостами. Это означает, что нужно иметь директиву RewriteEngine on для каждого виртуального хоста, на которым вы хотите использовать правила перезаписи.

А вторая директива RewriteRule является главной рабочей лошадкой этого модуля. Именно с её помощью мы будем устанавливать правила перезаписи.

Она используется следующим образом:

Шаблон – это то, что мы ищем в передаваемом URL.

Подстановка – это новая строка, которая передаётся веб-серверу в том случае, если в исходных данных найдено совпадение с Шаблоном.

[флаги] – это условные обозначения, задающие дополнительные действия или поведение при перезаписи. Они являются необязательными. Мы также рассмотрим флаги в этой инструкции.

Шаблон RewriteRule

В качестве Шаблона используется регулярное выражение, которое представляет собой способ описать текст, который считается подходящим (совпадающим с шаблоном). Шаблоны можно выразить словами, например, «все слова, которые начинаются с буквы A» или «каждый десятизначный телефонный номер» или «каждое предложение с двумя запятыми и без заглавных букв Q».

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

Более подробно регулярным выражениемя (шаблонам) посвящена вся вторая часть данного руководства.

Какая часть запроса проверяется на совпадение с Шаблоном?

Как уже было сказано, правила преобразования могут быть установлены для всего веб-сервера (контекст всего сервера) в файле httpd.conf; для отдельного виртуального хоста (контекст виртуального хоста) в блоках ; и для отдельных директорий (папок) (контекст директорий) в файлах .htaccess и блоках ).

В контексте VirtualHost Шаблон первоначально проверяется на соответствие с частью URL после имени хоста (hostname) и номера порта и до строки запроса (т.е. к примеру «/app1/index.html»). Это (%-кодированный) URL-путь.

Путь до директории, где определено правило, отбрасывается из анализируемого запроса (вплоть до и включая конечный слэш). В конечном счёте, правилу для сравнения передаётся строка «ниже» папки, где определено правилов.

Подстановка RewriteRule

Подстановка правила перезаписи – это строка, которая заменяет оригинальный URL-путь, который совпал с Шаблоном. В качестве подстановки может быть:

Указывает местоположение в файловой системе ресурса, который будет доставлен клиенту. Подстановки обрабатываются как путь к файловой системе, когда правило настроено в контексте сервера (virtualhost), и первый компонент пути в подстановке существует в файловой системе.

Если указан абсолютный URL, mod_rewrite проверяет, совпадает ли имя хоста с текущим хостом. Если да, то схема и имя хоста отбрасываются и результирующий путь трактуется как URL-путь. В противном случае, выполняется внешний редирект (перенаправление) для заданного URL. Для принудительного внешнего редиректа на текущий хост (чтобы запрашиваемая страница поменяла адрес на другую страницу этого же хоста), смотрите флаг [R], описанный далее.

Чёрточка говорит о том, что не должна выполняться какая-либо подстановка (существующий путь должен быть пропущен нетронутым). Это используется когда нужно применить флаг (смотрите далее) без изменения пути.

В дополнении к простому тексту, строка Подстановки может включать:

Директива RewriteBase

Мы уже выяснили, что на совпадение проверяется только часть запроса – начиная от текущий папки и далее вложенные подпапки. Если Подстановкой, получившейся в результате перезаписи, является относительный путь, то чтобы найти этот ресурс, к полученному значению добавляется путь до текущей папки. Это является поведением по умолчанию, а директива RewriteBase позволяет изменить это поведение.

Директива RewriteBase определяет URL префикс, используемый для постановки перед относительным путём.

Обычно, эта директива не требуется. Но она нужна когда:

Логика работы mod_rewrite

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

Это так, но это не всё. Если указано несколько правил RewriteRule и, допустим, в запросе найдено совпадение с первым правилом и исходная строка запроса изменена в соответствии с этим правилом. Второму правилу передаётся не исходная строка запроса, а новая строка, получившаяся в результате обработки всеми предыдущими правилами. И также происходит ниже по цепочке.

Проверку по всем правилам можно назвать проходом (раундом, циклом). Если в данном раунде случилось хотя бы одно совпадение (сработало правило), то после завершения прохода начинается ещё один круг проверки по этим же самым правилам! Это неочевидно и мало где об этом говориться – поэтому обратите на это особое внимание. Т.е. на новый раунд передаётся уже изменённая строка запроса и именно она проходит оценку по всем правилам. И вновь: если сработало хотя бы одно правило, идёт заход на новый круг и т.д.

Это является поведением по умолчанию для mod_rewrite. Это поведение можно изменить несколькими флагами, о которых будет рассказано далее.

Тестирование правил mod_rewrite

Для тестов, на вашем веб-сервере в папке сайтов создайте новую папку mr, к примеру, на Windows это может быть каталог C:\Server\data\htdocs\mr\, а на Linux это /var/www/html/mr/

Поскольку я работаю с локальным, сервером, то у меня теперь эта папка доступна по адресу http://localhost/mr

В этой папке создайте файл index.html следующего содержания:

И создайте пустой файл .htaccess

Источник