Здесь вы можете найти множество команд:
http://www.opensource.apple.com/source/shell_cmds/shell_cmds-170/
Чтобы понять, что mod_rewrite вам сначала нужно понять, как работает веб-сервер. Веб-сервер отвечает на HTTP-запросы . HTTP-запрос на самом базовом уровне выглядит следующим образом:
GET /foo/bar.html HTTP/1.1
Это простой запрос браузера на веб-сервер с запросом URL /foo/bar.html
. Важно подчеркнуть, что он не запрашивает файл , он запрашивает только некоторые произвольные URL-адреса. Запрос также может выглядеть так:
GET /foo/bar?baz=42 HTTP/1.1
Это так же верно, как и запрос на URL-адрес, и он явно не имеет ничего общего с файлами.
Веб-сервер это приложение, прослушивающее порт, прием HTTP-запросов, поступающих на этот порт, и возвращение ответа. Веб-сервер полностью может отвечать на любой запрос любым способом, который он считает нужным / каким-либо образом вы настроили его для ответа. Этот ответ не является файлом, это HTTP-ответ , который может или не может иметь ничего общего с физическими файлами на любом диске. Веб-сервер не обязательно должен быть Apache, есть много других веб-серверов, которые являются всего лишь программами, которые работают постоянно и привязаны к порту, который отвечает на HTTP-запросы. Вы можете написать его самостоятельно. Этот параграф был предназначен для развода с любым понятием, что URL-адреса напрямую равны файлам, что действительно важно для понимания. :)
Конфигурация по умолчанию для большинства веб-серверов - это поиск файла, который соответствует URL-адресу на жестком диске. Если document root сервера установлен, скажем, /var/www
, он может посмотреть, существует ли файл /var/www/foo/bar.html
и обслуживать его, если это так. Если файл заканчивается на «.php», он вызовет интерпретатор PHP и , после чего вернет результат. Вся эта ассоциация полностью настраивается; файл не должен заканчиваться на «.php» для веб-сервера для запуска его через интерпретатор PHP, и URL-адрес не должен соответствовать конкретному файлу на диске, чтобы что-то произошло.
mod_rewrite - это способ переписать внутреннюю обработку запросов. Когда веб-сервер получает запрос на URL /foo/bar
, вы можете переписать этот URL-адрес на что-то еще, прежде чем веб-сервер будет искать файл на диске в соответствии с ним. Простой пример:
RewriteEngine On
RewriteRule /foo/bar /foo/baz
Это правило говорит всякий раз, когда запрос соответствует «/ foo / bar», перепишите его на «/foo/baz". Затем запрос будет обработан как если бы /foo/baz
был запрошен. Это может быть использовано для различных эффектов, например:
RewriteRule (.*) $1.html
Это правило соответствует чему-либо (.*
), а захватывает it ((..)
), а затем перезаписывает его добавьте «.html». Другими словами, если /foo/bar
был запрошенным URL-адресом, он будет обрабатываться так, как будто запрошено /foo/bar.html
. См. http://regular-expressions.info для получения дополнительной информации о сопоставлении регулярных выражений, захвате и замене.
Другое часто встречающееся правило:
RewriteRule (.*) index.php?url=$1
Это опять-таки сопоставляет что-либо и переписывает его в файл index.php с первоначально запрошенным URL-адресом, добавленным в параметр запроса url
. Т.е. для любых входящих и входящих запросов файл index.php выполняется, и этот файл будет иметь доступ к исходному запросу в $_GET['url']
, поэтому он может делать с ним что угодно.
В первую очередь вы помещаете эти правила перезаписи в свой конфигурационный файл веб-сервера .
* Если разрешено первичным Apache, то вы можете поместить их в файл с именем .htaccess
в корне вашего документа (т. Е. Рядом с вашими файлами .php). Файл конфигурации; это необязательно, но часто разрешено.
mod_rewrite не волшебным образом делает все ваши URL «хорошенькими». Это распространенное недоразумение. Если у вас есть эта ссылка на вашем веб-сайте:
<a href="/my/ugly/link.php?is=not&very=pretty">
нет ничего, что мог бы сделать mod_rewrite, чтобы сделать это красиво. Чтобы сделать это красивой ссылкой, вы должны:
<a href="/my/pretty/link">
/my/pretty/link
, используя любой из описанных выше методов. (Можно использовать mod_substitute
для преобразования исходящих HTML-страниц
Существует много возможностей mod_rewrite и очень сложные правила соответствия, которые вы можете создать, включая цепочку нескольких переписываний, проксирование запросов на совершенно другую услугу или машину, возврат определенных кодов статуса HTTP в виде ответов, перенаправление запросов и т. д. Это очень мощный и может быть использован для хорошего использования, если вы понимаете основной механизм запроса HTTP-ответа. Он не автоматически делает ваши ссылки симпатичными.
См. Официальную документацию для всех возможных флагов и опций.
Многие базовые схемы виртуальных URL-адресов могут быть достигнуты без использования RewriteRules. Apache позволяет запускать скрипты PHP без расширения .php
и с виртуальным аргументом PATH_INFO
.
AcceptPathInfo On
часто включается по умолчанию. В основном это позволяет .php
и другим URL-адресам ресурсов переносить виртуальный аргумент: http://example.com/script.php/virtual/path
Теперь этот /virtual/path
отображается в PHP как $_SERVER["PATH_INFO"]
, где вы можете обрабатывать любые дополнительные аргументы, как вам нравится. Это не так удобно, как разделить сегменты входного пути Apache на $1
, $2
, $3
и передать их как различные переменные $_GET
в PHP. .php
.php
«Расширения файлов» в URL-адресах разрешены: Options +MultiViews
Это означает, что Apache выбирает article.php
для HTTP-запросов на /article
из-за соответствующего базового имени. И это хорошо работает вместе с вышеупомянутой функцией PATH_INFO. Таким образом, вы можете просто использовать URL-адреса, такие как http://example.com/article/virtual/title
. Это имеет смысл, если у вас есть традиционное веб-приложение с несколькими точками / сценариями PHP-скриптов. Обратите внимание, что MultiViews имеет другую / более широкую цель. Это повлечет за собой незначительное исполнение, потому что Apache всегда ищет другие файлы с соответствующими базовыми именами. Это фактически означает Content-Negotiation , поэтому браузеры получают лучшую альтернативу доступным ресурсам (например, article.en.php
, article.fr.php
, article.jp.mp4
). .php
.php
в URL-адресах, - это настройка обработчика PHP для других файловых схем. Самый простой вариант - переопределить тип MIME / обработчика по умолчанию с помощью .htaccess
: DefaultType application/x-httpd-php
Таким образом, вы можете просто переименовать свой скрипт article.php
только в article
(без расширения), но все же обработать его как PHP-скрипт. Теперь это может иметь некоторые последствия для безопасности и производительности, поскольку теперь все файлы без расширения будут переданы через PHP. Поэтому вы можете альтернативно установить это поведение только для отдельных файлов: <Files article>
SetHandler application/x-httpd-php
# or SetType
</Files>
Это несколько зависит от настройки вашего сервера и используемого PHP SAPI. Общие альтернативы включают ForceType application/x-httpd-php
или AddHandler php5-script
. Снова обратите внимание, что такие настройки распространяются от одного .htaccess
до подпапок. Вы всегда должны отключать выполнение сценария (SetHandler None
и Options -Exec
или php_flag engine off
и т. Д.) Для статических ресурсов и загрузки / каталогов и т. Д. mod_alias
, которые иногда работают так же хорошо, как и mod_rewrite
s RewriteRules. Обратите внимание, что большинство из них должны быть настроены в разделе <VirtualHost>
, но не в файлах конфигурации .htaccess
для каждого каталога. ScriptAliasMatch
в первую очередь предназначен для скриптов CGI, но также должен работать для PHP. Он позволяет регулярные выражения так же, как и любые RewriteRule
. На самом деле это, пожалуй, самый надежный вариант для конфигурирования переднего контроллера. И простой Alias
помогает с несколькими простыми схемами перезаписи. Даже простая директива ErrorDocument
может использоваться, чтобы позволить скрипту PHP обрабатывать виртуальные пути. Обратите внимание, что это обходное решение kludgy, однако, запрещает все, кроме запросов GET, и наводняет error.log по определению. См. http://httpd.apache.org/docs/2.2/urlmapping.html для получения дополнительных советов.