.htaccess

Файл .htaccess (сокращение от «hypertext access») переопределяет настройки самого популярного типа веб-серверов Apache и его аналогов.

Файл нужен для более гибкой настройки сервера под задачи оптимизатора. Задавать правила в .htaccess не стоит, если у вас есть доступ к главному конфигурационному файлу сервера httpd.conf или apache.conf (название зависит от настроек операционной системы). Изменения в нем вступают в силу быстрее, запросы не перегружают сервер. Однако очень часто такого доступа нет, например, в случае с виртуальным хостингом. Тогда приходится прописывать нужные настройки через .htaccess.

Схема работы .htaccess

1. Когда web-сервер получает запрос по протоколу HTTP (или HTTPS) к какому-либо файлу на сервере (определенной странице сайта), он предварительно проверяет наличие файла .htaccess в той же папке (или в одной из вышестоящих по иерархии каталогов папок, начиная с корневого каталога сайта). 
2. Если файл найден, то web-сервер считывает из него конфигурационные команды и применяет их в своей работе. 

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

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

Как выглядит .htaccess?

.htaccess - это текстовый файл.

Каждая строка файла означает определенную команду конфигурации (директиву) Apache.

Пустые строки игнорируются.

Строки, которые начинаются с символа решетки “#”, - это комментарии, и они не влияют на конфигурацию web-сервера.

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

    # убираем слэш в конце адреса
    RewriteCond %{REQUEST_URI} .+/$ [NC]
    RewriteRule ^(.+)(/)$ $1 [L,R=301]

Несмотря на непривычное название, создавать и редактировать файл можно в любом текстовом редакторе.

Файл имеет название именно «точка»htaccess

.htaccess должен быть записан в UNIX-формате, то есть, перевод строки должен задаваться в нем одним символом (десятичный 10, шестнадцатиричный 0A), а не двумя (десятичный 13, шестнадцатиричный 0D + десятичный 10, шестнадцатиричный 0A), как в DOS или Windows. Для тех, кто работает из под Windows, полученный тексовой файл потребуется открыть в 16-ричном редакторе и запустить замену 0D на 20 (пробел в 16-ричном варианте). Есть и другие способы превращения Windows-файла в UNIX-формат.

Правила написания .htaccess

• Пути к файлам (директориям) указываются от корня сервера.
  
  Правильный пример:

  DirectoryIndex /home/st1331/www/data/main.html

  Ошибка:

  DirectoryIndex /www/news/main.html

• Адресация к документам, расположенным на других сайтах должно выполняться с указанием протокола
  Правильный пример:

  Redirect /oldsite/ http://www.site.ru/

  Ошибка:

  Redirect /oldsite/ www.site.ru/

• Комментарии - строки, начинающиеся с символа #.
• В выражениях можно использовать переменные окруженияc, например %{REMOTE_ADDR} или %{HTTP_REFERER}.

Обычное использование .htaccess

• Авторизация, аутентификация — Файл .htaccess часто используется для установки ограничений безопасности для каталога, помните про “access” в имени файла? .htaccess часто сопровождается файлом .htpasswd, в котором собраны валидные имена пользователей и их пароли.
• Переписывание URL — Серверы часто используют .htaccess для перезаписи длинных, чрезмерно сложны URL в более короткие и лёгкие для запоминания.
• Блокировки — Используются allow/deny для блокировки IP адреса или домена. Также полезен для блокировки плохих ботов, рипперов и рефереров. Часто используется для ограничения доступа паукам поисковых машин.
• SSI — включают инклуды на стороне сервера.
• Листинг каталогов — Контролирует, как сервер будет реагировать, когда специфичная веб-страница (обычно это index.htm, index.html, index.php или любая другая — в зависимости от настройки) отсутствует.
• Настройка страниц ошибок — Изменение страницы, которая показывается при возникновении ошибки на стороне сервера, например, ошибки HTTP 404 Страница не найдена или дают знать поисковым машинам, что страница была перемещена — HTTP 301 Moved Permanently.
• MIME types (типы) — Инструктирует сервер, как работать с различными типами файлов.
• Cache Control (контроль кэша) — .htaccess файлы позволяют серверу контролировать кэширование веб-браузерами и проксями для уменьшения нагрузки на сеть, на сервер и предотвращения проявления лагов.

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

Преимущества .htacces

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

Недостатки .htaccess

Контролировать Apache только главными файлами конфигурации сервера часто предпочтительно по причинам безопасности и производительности:

• Потеря производительности — Для каждого HTTP запроса, когда используется .htaccess, требуется дополнительный доступ к файловой системе в родительскую директорию — для проверки возможных существующих файлов .htaccess в этих родительских директориях, которым разрешено работать с файлами .htaccess.
• Безопасность — Позволение индивидуальным пользователям модифицировать конфигурационные файлы сервера может стать причиной прорех в безопасности, если настройка не проведена должным образом.

Синтаксис htaccess
Метасимволы

Пример:

RewriteRule ^old(.*)$ /new.php [L,R=301]

Используются для задания групп символов или «меток» в шаблоне. Например, метки начала или конца строки.

Дополнение. Все, что расположено после символа '#', считается комментарием.

Модификаторы

Пример:

RewriteRule (.*) $1? [R=301,L]

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

Примеры использования:

^stena

Любые строки, начинающиеся со слова stena. Строка, начинающаяся со слова dom-stena не удовлетворит критерию.

stena$

Любые строки, заканчивающиеся набором символов stena. Строка, заканчивающаяся на stena-dom под выбор не попадёт.

.*

Любой символ повторяется любое количество раз. Под критерий попадут все строки.

^(.*)$

Выбрать любую строку и сохранить её как переменную $1 для дальнейшего использования.

[0-9]{1,6}$

Выбрать все строки, оканчивающиеся от 1 до 6 цифами из диапазона от 0 до 9.

^(.+)/(.+)$

Разбить строку на две части: до слэша и после, части строки будут доступны по переменным $1 и $2.

RewriteRule ^(.+)/(.+)$ /?a=$1&b=$2 [R=301,L]

https://www.site.com/1/2/3/4/5 →
https://www.site.com/?a=1/2/3/4&b=5

Флаги

Пример:

RewriteRule ^htaccess-fake$ - [G]
RewriteRule (.*) page.php\?%1 [L]

Флаги - дополнительные опции. Перечисляются в квадратных скобках через запятую, скажем [NC] или [R=301,L].

Проверки

Пример:

RewriteEngine on

RewriteCond %{REQUEST_FILENAME} !-d

RewriteCond %{REQUEST_FILENAME}\.html -f

RewriteRule ^(.*)$ $1.php

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

1. Вы можете предварить шаблон символом '!', чтобы обозначить несоответствие шаблону.

2. Можно выполнить лексикографическое сравнение строк:

3. Сравнение, как целых чисел:

4. Тест на различные атрибуты файлов:

5. Все эти проверки также могут быть предварены префиксом восклицательный знак ('!') для инвертирования их значения.

Переменные

Пример:

RewriteCond %{REQUEST_URI} /+[^\.]+$

RewriteRule ^(.+[^/])$ %{REQUEST_URI}/ [R=301,L]

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

Исполнение же правила подразумевает следующие действия: первым делом механизм преобразования выполняет поиск дополнительных условий для этого правила (RewriteCond директивы). Помним, что по историческим причинам дополнительные условия находятся перед правилами(RewriteRule). Если дополнительные условия для этого правила отсутствуют, то механизм преобразований тупо выполняет указанное в правиле преобразование текущего URL и переходит к следующему правилу. Однако если для исполняемого правила (RewriteRule) существуют дополнительные условия, указанные ПЕРЕД НИМ в директивах RewriteCond, то запускается внутренний цикл для обработки этих дополнительных условий в том порядке, в котором они перечислены, сверху вниз.

Если из имеющихся для правила дополнительных условий хотя бы одно условие НЕ выполняется это приводит к остановке запущенного процесса исполнения правила, и преобразование над URL, заданное в правиле, НЕ выполняется. Что бы запущенное на исполнение правило выполнилось до конца и изменило URL, необходимо, что бы выполнились ВСЕ дополнительные условия, указанные в директивах RewriteCond перед этим правилом!

Тут нужно дополнительно пояснить, что директивы RewriteCond по умолчанию объединены между собой оператором AND в одно составное условие. Просто этот оператор(AND) не записывается по умолчанию. От сюда и такая логика, что нужно, что бы все дополнительные условия были истинными (т.к. они объедены через AND) для удачного завершения преобразования URL. Однако директивы RewriteCond можно объединить условием OR при помощи флагов (см. синтаксис директивы). Про это нужно помнить, при задании дополнительных условий.

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

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

Пример:

RewriteRule ^(.*)$ index.php?/$1 [L,QSA]

Где:

1.    RewriteRule  – это название директивы – правила.
2.    Шаблон - это как раз то условие, выполнение которого запускает исполнение правила. Это условие - Шаблон представляет собой perl совместимое регулярное выражение, которое применяется к текущему URL.
3.    Подстановка – это как раз тот алгоритм изменения URL, т.е. правило изменения(преобразования) URL.
4.    [Флаги] подстановки - Третий аргумент директивы RewriteRule. Флаги - это разделённый запятыми, заглавные спец символы, заключенные в квадратные скобки. Флаги дополняют преобразование URL.

Параметры в правиле записываются в одну строку начиная с имени директивы и отделяются друг от друга пробелом.

Теперь давайте разберем пример правила RewriteRule:

RewriteRule ^(.*)$ index.php?/$1 [L,QSA]

1.    ^(.*)$ - это Шаблон, регулярное выражение которое применится к текущему URL. Кто знаком с регулярными выражении, сможет прочитать его так: искать в текущей строке URL от начала строки(знак ^) до конца строки(знак $) любой символ (знак .) в количестве от нуля до бесконечности (знак *). Так как в этом РВ есть скобки(), то та часть URL которая будет соответствовать условию в скобках будет захвачена в переменную подстановки $1, которую мы потом сможем использовать в Подстановке или в СравниваемаяСтрока(это в директиве RewriteCond, о ней ниже).
2.     index.php?/$1 - Подстановка – это собственно и есть правило преобразования URL. Запись index.php?/$1 означает, что строка нового, преобразованного URL должна быть составлена из двух частей, где первая часть строки это постоянное значениеindex.php?/ а вторая часть строки это значение из переменной подстановки $1. Тут мы вспоминаем что в $1 храниться та часть URL которая соответствовала РВ в скобах из параметра Шаблон. В итоге мы получаем преобразованный URL вида index.php?/URL_по которому обратились. По другому сказать так, что для всех запросов выполняется внутренне перенаправление на файл index.php.
3.    [L,QSA] – флаги, где 'last|L' - последнее правило что означает - остановить процесс преобразования на этом месте и не применять больше никаких следующих правил преобразований для URL. 'qsappend|QSA' - добавлять строку запроса - Этот флаг указывает механизму преобразований на добавление, а не замену, строки запроса из URL к существующей, в строке Подстановка. Используйте это когда вы хотите добавлять дополнительные данные в строку запроса с помощью директив преобразований.

Заключение

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

Также не забывайте оборачивать весь блок правил для  mod_rewrite в тег: <IfModule mod_rewrite.c></IfModule>

Не пишите излишне много директив для mod_rewrite, пишите только те правила преобразования, которые вам действительно необходимы. Особенно нужно быть аккуратным с внешними ридиректами - это такие ридиректы, которые выполняются путем отправки клиенту серверного заголовка с кодом НЕ 200 (отдача полноценной страницы), а с другим кодом (чаше всего 301 и 302) и которые приводят к перенаправлению в браузере клиента на другой URL т.е. к совершению нового запроса на клиенте.

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