Ifmodule mod rewrite c что это

Обновлено: 02.07.2024

В статье я привожу описание логики работы правила RewriteRule и синтаксис некоторых директив модуля mod_rewrite сервера Apache. Также я выделил и обобщил несколько выводов-постулатов, которые, как мне кажется, нужно обязательно знать и понимать при использовании этого модуля. Надеюсь, что все это позволит вам, так же, как и мне ранее, разобраться с работой этого модуля, предоставляющего мощный функционал для выполнения различных преобразований над URL .

Иногда пишут, что логика модуля mod_rewrite несколько запутана, но это только на первый взгляд. На самом деле сложного ничего в ней нет, просто эту логику нужно осваивать на практических примерах правил и нужно четко знать несколько главных постулатов, и тогда все станет очень понятно и просто. Для начала несколько теоритических постулатов, которые нужно именно зазубрить перед началом работы с практическими примерами, ибо без них не возможно разобраться в mod_rewrite.

Вот эти постулаты:

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

• Правило преобразования URL ( RewriteRule директива) это условие и правило одновременно. Если вы посмотрите на синтаксис RewriteRule директивы, то увидите, что она содержит условие, которому должен соответствовать текущий URL, что бы это правило преобразования начало выполняться, и само по себе правило преобразования (это то как изменить текущий URL). Здесь под словом правило подразумевается некое выражение, согласно которому будет выполнено изменение URL. Я, для наглядности, что бы избежать путаницы со словом «правило» сказал бы, что RewriteRule содержит условие и алгоритм изменения URL, который называют правилом изменения URL. Т.е. что бы правило начало выполняться (именно начало, т.к. по ходу выполнения возможны разные варианты и не всегда это приведет к указанному в правиле преобразованию URL) должно выполняться заданное в правиле условие для этого URL. Иными словами, правило преобразования срабатывает и начинает выполняться только если текущий URL соответствует условию из этого правила. Здесь можно провести аналогию для директивы RewriteRule как бы с подпрограммой, которая запускается по условию и выполняет некие манипуляции, в том числе и изменение URL. Но результат выполнения этой подпрограммы не всегда изменение URL. Т.е. нужно понимать, что запушенное правило преобразования не обязательно приведет к изменению URL, по ходу его работы возможны разные варианты исполнения правила, которые задаются дополнительными условиями. Об этом следующий пункт.

• К правилу ( RewriteRule ) помимо условия, содержащегося в самом правиле (это условие запускает исполнение самого правила) можно задать дополнительные условия при помощи директив RewriteCond. Дополнительных условий может быть несколько (несколько строк с RewriteCond директивами). Вот тут начинается разрыв шаблона. Но не пугайтесь, сейчас все объясню. Зачем нужны дополнительные условия и почему их не вставить в правило сразу? Тут дело в том, что условие в правиле, если оно выполняется, только запускает процесс исполнения правила, а дополнительные условия начинают проверяться только в ходе исполнения правила и позволяют управлять ходом исполнения этого правила! Таким образом дополнительные условия позволяют уже в процессе выполнения правила определить выполнить ли в конечном итоге преобразования этого несчастного URL или нет. И, еще один разрыв шаблона, записываются эти дополнительные условия (RewriteCond) не после самого правила (как было бы логично), а перед правилом(RewriteRule). Это выглядит нелогично и когда начинаешь разбираться с этим в первый раз сбивает с толку. Но такая запись дополнительных условий перед правилом объясняется историческими причинами. Просто так сложилось. Да, это не логично, но примите это как данность и запомните, что дополнительные условия (RewriteCond директивы) записываются ПЕРЕД их правилом (RewriteRule), а не после, и начинают эти условия проверяться только тогда, когда правило запустилось на выполнение. О логике исполнения именно дополнительных условий ниже.

• Понятие текущего URL. Здесь под «текущим» подразумевается значение URL, когда проверяется и применяется текущее правило. Этот URL не обязательно совпадает с первоначально запрошенным URL, потому что любое количество правил возможно уже были применены к нему и соответственно преобразовали изначальный URL, т.к. этот модуль может выполнять несколько последовательно следующих друг за другом преобразований URL. Это значит, что если вы указали несколько правил (RewriteRule) для преобразования URL, то все те правила, которые соответствуют указанным в них условиям, будут выполнять изменения (преобразования) URL последовательно от предыдущего правила к следующему правилу. Отсюда очень важный постулат: первичный URL, который, так сказать, пошел по этапам обработки будет меняться от одного выполненного правила к другому, и каждое последующее правило будет начинать работать (проверять на условие и изменять) уже НЕ с первичной строкой URL, а уже с той измененной строкой, которая получилась на выходе от применения предыдущего правила(преобразования). Это очень важно понимать, что каждое последующее правило преобразования работает НЕ с первичной строкой URL, а работает со строкой URL уже преобразованной предыдущим исполненным правилом (именно исполненным правилом, т.е. правилом которое последним выполнило преобразование).

• Порядок расположения правил ( RewriteRule ) в файле имеет значение. Как видите из выше описанного, порядок расположения правил обработки URL имеет важное значение, т.к. URL передается от правила к правилу. Также Порядок правил в наборе важен еще потому, что механизм преобразований обрабатывает их по следующей логике. Сначала механизм преобразований просматривает последовательно весь набор правил строчка за строчкой (RewriteRule директивы) и когда он встречает правило (RewriteRule) условие из которого применительно к текущему URL является истинным, то механизм преобразований начинает исполнять это правило. Если же условие из правила (RewriteRule) ложно для текущего URL, то механизм преобразования НЕ исполняет это правило, а переходит к следующему правилу.

• Логика исполнения правила ( RewriteRule ). Исполнение же правила подразумевает следующие действия: первым делом механизм преобразования выполняет поиск дополнительных условий для этого правила (RewriteCond директивы). Помним, что по историческим причинам дополнительные условия находятся перед правилами(RewriteRule). Если дополнительные условия для этого правила отсутствуют, то механизм преобразований тупо выполняет указанное в правиле преобразование текущего URL и переходит к следующему правилу. Однако если для исполняемого правила (RewriteRule) существуют дополнительные условия, указанные ПЕРЕД НИМ в директивах RewriteCond, то запускается внутренний цикл для обработки этих дополнительных условий в том порядке, в котором они перечислены, сверху вниз. Если из имеющихся для правила дополнительных условий хотя бы одно условие НЕ выполняется это приводит к остановке запущенного процесса исполнения правила, и преобразование над URL, заданное в правиле, НЕ выполняется. Что бы запущенное на исполнение правило выполнилось до конца и изменило URL, необходимо, что бы выполнились ВСЕ дополнительные условия, указанные в директивах RewriteCond перед этим правилом! Тут нужно дополнительно пояснить, что директивы RewriteCond по умолчанию объединены между собой оператором AND в одно составное условие. Просто этот оператор(AND) не записывается по умолчанию. От сюда и такая логика, что нужно, что бы все дополнительные условия были истинными (т.к. они объедены через AND) для удачного завершения преобразования URL. Однако директивы RewriteCond можно объединить условием OR при помощи флагов (см. синтаксис директивы). Про это нужно помнить, при задании дополнительных условий.

• После исполнения правила можно дополнительно переопределить алгоритм обработки измененного URL сервером apache. Здесь имеется в виду то, что вы можете после изменения URL при помощи специальных флагов указать для apache нужные вам действия, например отказать в выдачи файла, или выполнить ридирект на новый URL.

• Нужно помнить, что mod_rewrite является частью apache, это значит, что вы можете применить его функционал (директивы) на разных уровнях конфигурации apache. На глобальном уровне, путем записи директив в главный конфиг apache или в конфиги подключаемые к нему, на уровне виртуального хоста путем добавления директив в файлы конфигурации виртуальных хостов, и на уровне каталога путем добавления директив в файл. htaccess.

Логическая схема исполнения правила (RewriteRule)

Теперь, когда мы рассмотрели главные постулаты и логику обработки правила, рассмотрим синтаксис директив.

Синтаксис директивы RewriteRule:

RewriteRule Шаблон Подстановка [Флаги]

Попытка номер раз создать почти идеальный htaccess

Профессионалы знают, что такое htaccess.
Тем кто собираются уйти с народ.ру на php-хостинг только предстоит узнать, что это такое.
Те кто только что установил свои первые jooml'у или wordpress срочно должны узнать о нашем герое — htaccess

Зачем нам .htaccess ?

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

Или другой пример. Скажем ваш ресурс начинает набирать популярность, но переезжать на выделенный сервер ещё рано, а мощностей VPS уже не хватает. Вас очень может выручить htaccess.

А ещё htaccess может решить некоторые вопросы с безопасностью вашего сайта.

Хочу идеальный .htaccess !

Оказывается в интернете много различной противоречивой информации относительно того как использовать .htaccess. Пришлось долго и нудно экспериментировать, чтобы понять что истинно, а что ложно. В большинстве случаев авторы советов в своих блогах забывают упомянуть, что для работы определенных условий нужен тот или иной модуль Апача.
Впрочем хватит слов, пора к делу. Попробуем создать почти идеальный .htaccess

1. Первой строкой задаем основные опции:

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

Опция -ExecCGI запрещает запуск CGI скриптов. Лучше разрешить только для конкретных папок. Повысит безопасность.
Опция -Indexes запрещает показывать содержимое каталогов, если в них нет индексного файла. На виртуальном хостинге обычно включена по умолчанию. Изменив минус на плюс +Indexes можете наоборот разрешить просмотр содержимого каталога (или каталогов).
Опция -Includes запрещает SSI. Если не знаете, что это — запрещайте (Можно поЯндексировать(! ) по запросу Server Side Include если хотите узнать об этом побольше). Можно использовать опцию IncludesNOEXEC, которая разрешит использовать SSI без запуска скриптов.
Опция +FollowSymLinks позволяет использовать символические ссылки на файлы или каталоги, не находящиеся в пределах корня вашего сайта.

Вы можете использовать htaccess с разными настройками для разных каталогов. В корне сайта вы можете объявить -Indexes, а в избранных каталогах создать ещё один файл .htaccess и в нем объявить +Indexes. Помните, что действие опций htaccess распространяет сверху вниз по дереву каталогов до самой глубокой вложенности, пока не будут отменены другим htaccess.

Необязательно полностью перечислять все опции в дочерних .htaccess если они не изменяются. Достаточно указать (переназначить) только те опции и директивы, которые изменяются. Остальные опции также унаследуются от родителя.

Скажем, у вас есть вот такой путь /site/folder_one/subfolder/other/
В файле /site/.htaccess вы указываете:

В файле /site/folder_one/.htaccess указываете:

В файле /site/folder_one/subfolder/.htaccess указываете:

Получиться вот что:
В папке site будут показываться файлы любого содержания, если только к ним напрямую обратиться. Или индексный файл, если не явного обращения к одному из файлов. В случае отсутствия индексного файла получена 403 ошибка.
К папке folder_one доступ закрыт. Даже если знать имя файла и набрать его в адресной строке в ответ сервер вернет ошибку 403.
Папка subfolder разрешена для обращений по прямому адресу или же в случае отсутствия индексного файла покажет содержимое каталога. Эти же права распространяться и на папку other.
Если убрать файл ,htaccess из папки folder_one, то она унаследует права от родительской site.

2. Немного SEO (куда же без него)

Обязательно не забыть про условие <IfModule mod_rewrite.c>. Не окажись у хостера данного модуля и ваш сайт станет выдавать 500-ую ошибку. Данный конкретный модуль входить в сборку Апача по-умолчанию. Ну а вдруг… Хостеры и их админы бывают всякие.

В данной части пользы больше для SEO. Модуль rewrite как следует из его названия занимается перенаправлениями (привет Кэпу) .

3. Кто в папке главный?

Если у вас папке есть файлы index.html и index.php (не знаю, зачем и кому такое было нужно, но не раз видел такое) то как указать серверу кто их них более индексный?

А ещё можно там указать скажем roosso.php и тогда набрав в строке запроса адрес сайт.бла/бла/бла/ вы увидете не index, а roosso

4. Ещё настройки…

Первая строчка устанавливает часовой пояс. Например в Apache 2.22.22 был баг связанный с этой опцией. Функции времени в php не работали, пока не установишь часовой пояс.

Вторая строка это подпись сервера. Вы их не раз видели на всяких системных страницах типа 500ой ошибки или 403ей. Обычно там какая-нибудь техническая информация и почта вебмастера. Я предпочитаю даже в таких мелочах скрывать данные о софте на сервере. Коллеги параноики меня поддержат.

Угадайте, что делает третья строка?

5. Когда нет доступа к php.ini

С помощью .htaccess мы также можем управлять рядом настроек PHP. На виртуальном хостинге, как правило, нет возможности изменять настройки php.ini. Чаще всего этого и не требуется. Но все же есть ряд опций контроль над которыми может нам быть полезен. Например, увеличить лимит на загрузку файлов, или лимит передачи данным методом POST.

Первая строчка разрешить загружать файлы размером до 32 Мегабайт. По умолчанию в php обычно это значение 8 или 16 мегабайт.
Второй строкой разрешаем постинг объемом до 10 мегабайт. По умолчанию это значение обычно 2 Мегабайта.
Третья строка устанавливает кодировку по используемую вашими скриптами. По своей сути она дублирует строку: «AddDefaultCharset UTF-8». Но я чаще прибегаю к установке кодировки именно через php.
Четвертой строкой изменяем лимит времени выделенный на выполнение скрипта. По умолчанию он обычно равен 30 секундам. Но иногда для выполнения каких нибудь сложных обработок требуется больше времени.

6. Типы файлов. Ловкость рук и ни какого мошенничества.

В моей практике случалось пару раз, что после какого либо обновления провайдером софта, слетали типы файлов. Хотя такое редко. За 10 лет, всего два случая. Но иногда мне нужно было заставить html работать как php. А иногда требуется научить апач различать типы файлов, которые ему неизвестно. (Как оказалось Апачу вообще мало что известно из редких типов файлов.) В такой ситуации нас спасет следующий код:

Первая строчка позволит нашим php файлам иметь расширение html, но выполняться как php. Полезно бывает во многих случаях. А в старые добрые когда поисковики индексировали ЧПУ лучше, такая строчка всегда приходила на выручку.
Мы можем переназначить, добавить или подменить любые типы файлов под удобные нам разрешения.

Кстати, вы можете легко написать к примеру вот такую строку:

Потом переименовать все ваши файлы, изменив расширение на .i (не забыв конечно про ссылки) и адреса файлов у вас на сайте будут не сайт.мой/index.php?uri а сайт.мой/index.i?uri

Например я пишу

Второй строкой указано, какие расширения файлов должны выполняться как cgi скрипты.

Третья, четвертая и пятая строки, на всякий случай уточняют мим-тип файлов с разрешением css, js, xml. Не путайте с присвоением заголовка в ответе сервера на запрос, как это сделано в первых двух строках.

Шестая строчка это участка, нужна если на вашем сайте есть скачиваемый для пользователей контент. Если добавить эту строку, то при обращении к данным файлам им будет предлагаться скачать их на компьютер, а не как это сейчас в современным браузерах куча плагинов, которые даже word открывают в браузере.

Седьмую строку я закомментировал. Это строчка в принудительно-добровольном порядке, будет все файлы с вашего сервера запустить как php. Её лучше использовать лишь в отдельных папках, при необходимости.

7. Знают взрослые и дети, что архивы меньше весят…

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

У Апача есть два модуля сжатия. Оба не являются модулями по умолчанию, поэтому необязательно могут присутствовать у вашего провайдера. Но как показала практика у 99% провайдеров один из них стоит. Наиболее распространен mod_deflate. Чтобы его с помощью сжимать весь контент на вашем сайте добавьте в .htaccess следующие строки:

Как видите мы должны перечислить mime type файлов, которые следует подвергать сжатию. Сюда можно добавить и видео и картинки, но толку это даст мало. Потому что jpeg или gif уже сами по себе являются сжатыми форматами. Также как avi или flv. Вы фактически нечего не выиграете указав их.

Второй менее популярный модуль это mod_gzip, Чтобы включить сжатие с его помощью добавьте вот такие строчки:

Данный модуль умеет работать с масками, что несомненно большой плюс. Да и синтаксис у него куда более гибкий чем у предыдущего. Но используют его реже. А по сжатию я даже не берусь судить, который из модулей лучше. Я сильной разницы не заметил при тестах.

8. А ещё быстрее можно?

Можно. Если применить кеширование страниц. У кеширования есть и плюсы и минусы, поэтому подходить к этому вопросу надо подготовившись. Для динамически обновляющегося сайт каждый 2-3 минуты, например популярного форума, нужно учесть, что пользователь должен видеть актуальную информацию. Но у любого сайт есть контент, который более или менее статичен. Например те же картинки, или файлы стилей. Поэтому нам потребуется по разному использовать кеширование различного содержимого на сайте. В html разметки мы всегда можем использовать meta теги. И через php мы может устанавливать заголовки ответа сервера. Остается вопрос, как быть с css, js, image и т.д. и т.п.

Помочь нам в этом могут два модуля: mod_headers и mod_expires которые могут установить заголовки в ответ сервера и подсказать вашему браузеру, что и как нужно кешировать. Один из модулей обычно стоит у провайдера, но как и в случае с любым модулем, который не входит в стандартную сборку Апача, 100% гарантии никто вам не даст. Поэтому снова во избежание 500й ошибки указывает условия для каждого из модулей.

Вот такой синтаксис у mod_headers. Думаю по комментариям ясно что к чему.
В данной секции я отключил кеширование php файлов. Хотя по моему мнению небольшой временной интервал кеширования им не повредит. 5-30 секунд, это интервал времени, за который мало что меняется. А многие пользователи любят пользоваться клавишей back (вернуться назад). Чтобы не загружать им страницу второй раз, а подхватить её из кеша, разумный интервал кеширования все же уместен.

Во второй секции где идут условия для mod_expires я именно так и делаю — для php ставлю небольшой интервал кеширования.

9. Правила вежливого тона…

Для 400-х ошибок можно использовать и динамические страницы на php. А вот для 500 лучше сделать на html и js. Это часть ошибок обычно связана с ошибками сервера (в большинстве случаев) и php или cgi как правило в такой ситуации не работают.

Если вам лень делать столько страниц устанавливайте страницей ошибок главную страницу своего сайта или карту сайта.

Все это вы делаете исключительно для людей. Поисковым роботам плевать на то есть у вас страницы ошибок или нет. Они видят ответ сервера с кодом ошибки и блокируют вашу страницу в поиск. Так что имейте ввиду, это не панацея. Это лишь вежливость к вашей аудитории и имидж вашего сайта.

10. Подведем итог

Знатоки понимают, что в этой статье описано далеко не все. Я коснулся здесь лишь поверхности «айсберга». На самом деле возможности .htaccess куда много обширней, чем описано в статье. Но я и не преследовал целью перевести манаул по htaccess на русский язык. Всего чего я хотел это создать небольшой костяк файла .htaccess для тех, кто только приступил к изучению данного вопроса, чтобы сэкономить их время на поисках информации по сети.

В результате всех манипуляций у нас должен был получить файл следующего содержания:

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

И напоследок для любителей экспериментов несколько строк .htaccess. Сужу по своему опыту — на практике знания усваиваются лучше чем в теории.

mod_rewrite — просто о сложном

Hello world

Простейший пример. Допустим, Вы захотели, чтобы никто не знал, что Ваш сайт написан на PHP и решили замаскировать расширения файлов. Можно, конечно, внести соответствующую директиву в конфигурацию Apache и тогда все файлы с расширением ".msl" («My Super Language») будут обрабатываться интерпретатором PHP. Но можно поступить проще:
создаем в корне нашего сайта файл .htaccess со следующим содержимым
RewriteEngine On
RewriteBase /
RewriteRule ^(.*)\.msl$ $1.php [QSA,L]

Первая директива включает механизм mod_rewrite в текущей папке и во всех ее подпапках. Вторая указывает модулю mod_rewrite, что текущая папка в файловой системе соответствует корню сайта. Третья — непосредственно правило преобразования URL.

Прочесть его можно так:
Если сразу после начала строки ("^") идет произвольное количество любых символов ( "(.*)" ), причем мы хотим запомнить, что именно это за символы, окружая их скобками, затем идет точка ("\.") (экранируем точку, потому что одиночная точка — это просто любой символ), затем символы «msl» и на этом строка заканчивается ("$"), то заменим исходный URL на следующий: возьмем первую запомненную подстроку в скобках из правила, прибавим к ней ".php", добавим все дополнительные параметры адреса, которые могли быть "[QSA]" и на этом закончим, не будем применять дальнейшие преобразования, если они есть "[L]"

Все, теперь Вы можете смело менять все ссылки, заканчивающиеся на ".php" на ".msl" и писать в своем блоге, что изобрели новый скриптовый язык. Apache, встретив ссылку на «index.msl» с помощью mod_rewrite на лету преобразует ее в «index.php» и вызовет нужный скрипт.

А что еще умеет mod_rewrite?

О, этот модуль умеет многое. Лично я жду, когда же кто-нибудь достаточно продвинутый в магии и PCRE напишет «Морской бой» на mod_rewrite.

Но пока этого не случилось, покажу еще несколько вариантов использования этого замечательного модуля.

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

Первичная фильтрация данных

Предположим, что адреса пользовательских блогов будут иметь вид "/blogs/ABC/", а скрипт, который будет показывать ленту записей определенного блога, будет называться «viewblog.php».
Несложное правило mod_rewirte позволит нам отсеять некорректные имена блогов, которые могут использовать злоумышленники:
RewriteRule blogs/([a-z0-9_-]+)([\/])$ viewblog.php?blogname=$1 [L]
RewriteRule viewblog.php - [F]

В квадратных скобках, в соответствии с синтаксисом PCRE, мы задаем класс символов, включая в него цифры, буквы латинского алфавита, минус и знак подчеркивания. Все адреса, в которых будут какие-то другие символы, не пройдут проверку этим правилом и приведут к ошибке 404. Флаг [L] необходим, чтобы движок mod_rewrite, успешно сделав преобразование, не пошел далее, на второе правило. Этот флаг аналогичен оператору break внутри цикла.

Второе правило не задает напрямую преобразование адреса (символ "-"), а запрещает прямой доступ к скрипту viewblog.php (флаг "[F]"), тем самым закрывая злодеям возможность передать в параметрах что-то вредоносное.

Кстати:
Хорошим тоном будет начинать Ваши правила со строчки
RewriteRule .htaccess - [F]
Это запретит доступ к файлу .htaccess в случае дурно настроенного хостинга.

Использование для кэширования в ФС

И тут mod_rewrite может придти на помощь, если по каким-то причинам Вы не хотите переходить на свой сервер.

Во-первых, модифицируйте свой скрипт viewblog.php таким образом, чтобы при обращении к нему он не только выдавал сформированную страницу в браузер, но и записывал ее в файловую систему по адресу /blogs/ABC.html

Проще всего это сделать, использовав функции управления буферизацией. Предположим, что исходный код скрипта viewblog.php выглядит у Вас примерно так:
<?php
$blogname = $_GET['blogname'];
if ( !Blogs::exists($blogname) )
die("No blog!");

Применим буферизацию вывода и запишем вывод в файл.
<?php
$blogname = $_GET['blogname'];
if ( !Blogs::exists($blogname) )
die("No blog!");

ob_start();
Blogs::display($blogname);
$content = ob_get_contents();
ob_end_flush();

$f = fopen(_YOUR_SITE_ROOT . "/blogs/" . $blogname . ".html", "w");
fwrite($f, $content);
fclose($f);
?>

Теперь остается только немного модифицировать Ваши правила в .htaccess, чтобы получить полноценную систему кэширования контента:

RewriteRule blogs\/([a-z0-9_-]+)([\/])$ blogs\/$1\.html

RewriteCond % blogs\/([a-z0-9_-]+)\.html$
RewriteCond % !-s
RewriteRule (.*) viewblog.php?blogname=%1

В первой строке мы преобразуем URL вида blogs/ABC/ в blogs/ABC.html, таким образом перенаправляя Apache на сгенерированный нами файл кэша страницы.
Следующие три строки представляют собой одно большое правило. Если идет запрос на blogs/ABC.html и при этом в файловой системе нет такого файла — запрос перенаправляется на скрипт viewblog.php

Таким образом нам остается только предусмотреть систему своевременной очистки кэша и задача решена.

Другие применения

Лично я использую модуль mod_rewrite аналогично последнему примеру для генерации и хранения в ФС превью изображений.

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

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

А вообще — это Вуду :)
Чертовски интересное Вуду, позволяющее каждый день открывать новые стороны и применения.

Как написать .htaccess файл для сайта

Файл .htaccess являются по своему назначению конфигурационным файлом уровня каталога(директории) для web сервера Apache . Это означает, что директивы из этого файла исполняются Apache локально только при обращении к директории, содержащий этот файл. Область действия этих директив распространяется только на каталог, в котором расположен файл, и на вложенные каталоги, до тех пор пока они не будут переопределены в других файлах .htaccess из вложенных каталогов. Файл.htaccess перечитывается при каждом обращении к веб-серверу, так что изменения, внесенные в этот файл, вступают в силу немедленно.

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

Делается это разрешение при помощи следующего блока кода:

Здесь в теге <Directory> указывается физический путь на сервере до корня вашего сайта, и внутри тега указывается директива AllowOverride. Эта директива может быть установлена в None, чтобы сервер не читал файл .htaccess. Если она установлена в All - сервер будет допускать все директивы .htaccess файла. Значение по умолчанию: AllowOverride All.

Теперь пару слов о названии файла .htaccess. Этот файл может называться и по другому, и это тоже устанавливается в глобальном конфиге apache директивой AccessFileName. По умолчанию эта директива установлена в конфиге как AccessFileName .htaccess, и это значение обычно никто не меняет, но вы должны знать, что изменить его на другое возможно.

Синтаксис файлов .htaccess в общем случае аналогичен синтаксису главного файла конфигурации apache. Однако, администратор может ограничивать для пользователей доступ к тем или иным директивам. То есть, несмотря на то, что команда, в принципе, может исполняться из .htaccess, администратор может запретить доступ к конкретной директиве. Учитывайте это при работе. Также хочу заметить такой момент, когда вы пишите директивы работающие с каталогами? то в главных конфигурационных файлах apache их нужно оборачивать в тег <Directory /path/. > с указанием каталога к которому они применимы, однако при написании этих директив в .htaccess файле уже не нужно их оборачивать в тег <Directory>, если вы хотите что бы они применялись к текущему каталогу файла .htaccess, если же вы хотите применить их только к вложенному каталогу то тогда, опять же, нужно обернуть в тег <Directory>.

Для чего мы можем использовать .htaccess файл. Вариантов здесь немало, вот самые распространенные из них:
1.Для управления разрешениями на доступы к каталогам сайта (запаролить директорию, запретить доступ к файлам определенного формата, или доступ к сайту в определенный промежуток времени, запретить или открыть доступ с определенных IP адресов, управлять роботами поисковиков)
2.Для перезаписи текущего URL на новый в зависимости от условий (см. также описание mod_rewrite сервера Apache и логику его обработки правил )
3.Для явного указания кодировки сайта.
4.Для разрешения или запрета просмотра файлов сайта
5.Для защиты от хотлинка
6.Для выполнения ридирктов
7.Для задания своих страниц ошибок
8.Для переопределения индексного файла
9…. и многое другое.

Расшифрую некоторые флаги из директив:

RewriteCond . [NC] - NC значит регистр нечувствительное сравнение выполнять
RewriteCond . [NC,OR] - NC см. выше, OR - значит объединять RewriteCond через OR, по умолчанию если ничего не указана то RewriteCond объединяются через AND оператор.
RewriteRule . [L] - L значит закончить (остановить обработку) на этом RewriteRule правиле любые дальнейшие преобразования URL, т.е. последующие RewriteRule не выполнять.
RewriteRule . [L,R=302] - L см. выше, R=302 значит выполнить редирект с кодом 302 на преобразованный URL
RewriteRule . [R=301,QSA,L] - L и R см. выше, QSA - при преобразовании URL выполнять при стыковку заданных частей, а не замену.
RewriteRule . [F] - F, значит отказать в выдачи результата по этому URL кодом 403 Forbidden .
RewriteRule . - [G,L] G|Gone - [G] flag значит отдать код 410Gone status - рекомендация забыть этот URL

AuthUserFile - задает путь к файлу с паролями для http авторизации пользователя. Путь может быть абсолютный от корня файловой системы Linux сервера или относительный от ServerRoot apache. В Ubuntu ServerRoot "/etc/apache2" по умолчанию. При задании относительного пути от ServerRoot apache начальный слеш в пути не указывается, иначе путь будет восприниматься как абсолютный от корня Linux. Также, если путь содержит недопустимые символы и пробелы его нужно заключать в кавычки, это общее правило.

Order, Deny, Allow

Теперь еще раз, но уже более детально, хотелось бы вернуться к директивам управление доступом: Order, Deny, Allow и более детально описать ее синтаксис и логику.

Директивы Allow , Deny , Order модуля mod_access_compat нежелательны к использованию и считаются устаревшими, хотя и поддерживаются еще в версиях Apache 2.3 и 2.4. В следующих версиях они будут удалены. Вместо них, начиная с версии Apache 2.3, этот функционал реализуется директивой Require, которая позволяет более гибко настраивать доступы, чем устаревшие директивы. Детали смотрите в статье "Контроль доступа клиента в Apache", которая подробно описывает директивы Require, Allow, Deny, Order с примерами их использования.

Директива Order синтаксис: Order [Deny,Allow] или [Allow,Deny]

По умолчанию директива Order имеет порядок: Deny,Allow. Обратите внимание, что Deny,Allow пишутся без пробела.

В зависимости от того в каком порядке указаны директивы Deny,Allow или Allow,Deny меняется логика работы.

Если Deny,Allow то запрещается доступ со всех IP кроме указанных, если Allow,Deny разрешается доступ со всех IP кроме оговоренных. Далее идут секции описания для доступа и запрета. Ключевое слово all означает со всех IP.

Например, что бы запретить (блокировать) доступ с IP x.x.x.x и x.x.x.xx и разрешить доступ всем остальным необходимо добавить в .htaccess следующий код:

Обратите внимание что IP записаны через пробел. Можно также указать IP как IP/маска.

Для обратной ситуации, что бы запретить доступ со всех IP кроме x.x.x.x и x.x.x.xx нам необходимо добавить в .htaccess следующий код:

Запрет или разрешение можно указывать и на отдельный файл или группы файлов. Например, что бы запретить доступ всех кроме IP x.x.x.x к файлу passwd.html, который расположен в текущей директории.

Аналогично можно запретить или разрешить доступ к определенной группе файлов описав их через регулярное выражение. Например, к файлам с расширением ".key":

Шаблон получился большой, но на практике нужно стремиться использовать только действительно крайне необходимые директивы. Особенно осторожно нужно поступать с внешними редиректами, так как они приводят к общему увеличению времени обработки запроса. Поэтому делайте их только если они действительно необходимы. Еще хочется предостеречь Вас от прямого копипаста директив из приведенного мною шаблона в ваши реальные конфиги. Код приведенный здесь используйте только для примера, что бы получить представление, что вообще возможно и как это будет выглядеть. В свои же файлы вставляете только те директивы, синтаксис которых вы понимаете, можете расшифровать и которые вы проверили по официальному руководству apache . Ошибки по исполнению директив из файла .htaccess смотрите в логах apache.

Читайте также: