Примеры htaccess – Файл .htaccess — настройка перенаправлений и управление конфигурацией веб-сервера

Содержание

8 изумительных примеров .htaccess файлов

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

Файлы .htaccess – это простые текстовые файлы, которые могут редактироваться в любом текстовом редакторе. В этой статье мы рассмотрим изумительные примеры применения .htaccess файлов для ваших проектов.

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

В дальнейшем, для работы с htaccess файлами локально, вы можете установить локальный сервер (Denwer). При этом htaccess файлы должны быть в корневой директории проекта (сайта). Для редактирования, мы можем использовать любой из текстовых редакторов (Notepad++ вполне подойдет).

Файлы .htaccess поддерживают такой же формат, что и другие основные конфигурационные файлы (httpd.conf). Множество настроек, которые могут быть установлены с помощью конфигурационных файлов, также могут быть установлены с помощью .htaccess файлов, и наоборот.

Настройки установлены в файле .htaccess, отменяют подобные в конфигурационных файлах директории в которых они находятся, а также для всех подпапок.

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

А теперь подробнее и с примерами использования этих загадочных .htaccess файлов.

Пример .htaccess редиректа

Редирект на .htaccess, один из наиболее популярных способов использования этих файлов. Это помогает в реорганизации файловой структуры сайта. Увидеть редирект на примере, можете ниже:

Redirect 301 ^old\.html$  <a href="http://localhost/new.html" target="_blank">http://localhost/new.html</a>

Это изменяет HTTP заголовок ответа на 301 (перемещено навсегда) и перенаправляет все запросы из old.html, соответственно на new.html. Мы используем регулярные выражения для определения URL для редиректа, которые дают возможность выбирать только нужные URL для перенаправления. Также можно вставлять полный URL адрес, но это ручная работа.

Пример .htaccess rewrite

В переводе, rewrite означает – переписать. Мы можем переписывать текущий URL страниц для более простого восприятия, или как говорят в народе: «для создания ЧПУ» (человекопонятных УРЛ). Что сейчас очень распространено. Пример простого использования htaccess rewrite можете посмотреть ниже:

RewriteEngine on

RewriteRule ^old\.html $ new.html

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

В дальнейшем, для отображения обновленной информации в адресной строке посетителя, мы можем использовать модификатор R, в конце правила. Смотрите пример:

RewriteRule ^old\.html$  <a href="http://hostname/new.html" target="_blank">http://hostname/new.html</a> [r=301]

Модификатор r, способствует внешней переадресации, которая возвращает новую страницу. Таким образом, мы можем определить код статута (HTTP ответ). Этот пример кода обновляет информацию в адресной строке браузера.

Еще одно полезное применение для htaccess rewrite, которое упоминалось ранее, это создание ЧПУ. Давайте посмотрим на примере:

RewriteRule ^products/([^/]+)/([^/]+)/([^/<WBR>]+) product.php?cat=$1&brand=$2&<WBR>prod=$3

Это правило позволит пользователям увидеть URL подобным образом: products/turntables/technics/sl1210, а перенаправить на product.php?cat=turntables&<WBR>brand=technics&prod=sl1210, без изменения данных в адресной строке. Это очень удобно как для SEO, так и для пользователей. Текст между слешами, это регулярные выражения, которые позволяют отобразить только значения $1,$2,$3, между которыми слеши. Выражение [^/]+ означает, что может встречаться любой из символов 1 или больше раз, за исключением слеша (/).

На практике, url rewrite используют более сложным образом. Этой теме посвящено множество статей и уроков, мы не будем на этом останавливаться.

Создание собственной 404 страницы

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

Очень просто, использовать .htaccess, для указания страницы 404 ошибки. Смотрите на примере:

ErrorDocument 404 ";/404.html";

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

Запрещение доступа к определенным ресурсам

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

AuthName ";Username and password required";

AuthUserFile /path/to/.htpasswd

Require valid-user

AuthType Basic

Этот файл нужно сохранить и поместить в директорию, которую мы хотим защитить. Указание AuthName, выводит сообщение с блоков ввода логина и пароля. AuthUserFile это указание пути к файлу .htpasswd. Указание Require, определяет, что только авторизованные пользователи имеют доступ к защищенным файлам, в то время как AuthType установлено на Basic.

Для защиты конкретного файла, мы можем поместить следующий код в директиву <files>, в которой определяются файлы для защиты доступа.

Files ";protectedfile.html";>

AuthName ";Username and password required";

AuthUserFile /path/to/.htpasswd

Require valid-user

AuthType Basic

</Files>

Мы также ссылаемся на файл .htpasswd, который содержит имена пользователей и зашифрованные пароли доступа к защищенным ресурсам. Этот файл должен быть сохранен в директории, к которой невозможно добраться через web (то есть, этот файл не должен находится в директориях сайта). Существует множество сервисов, которые могут быть использованы для генерации этих файлов автоматическим образом, так как пароль должен быть закодирован.

Блокирование доступа отдельных IP, user-agent

Еще одно использование файла .htaccess, это быстрое и простое блокирование всех запросов от отдельных IP адресов или user-agent. Для блокирования отдельных IP адресов необходимо лишь указать несколько директив, как показано в примере:

order allow,deny

deny from 192.168.0.1

allow from all

Директива order, сообщает серверу, в какой последовательности выполнять директивы allow/deny. В этом случае, директива allow будет выполнятся первой, потом deny. Указание allow from all выполняется первым (хотя и стоит в коде после deny), оно позволяет всем IP адресам иметь доступ к содержимому. После этого вступает в силу директива deny, которая запрещает доступ определенным IP. Таким образом имеют доступ все, кроме указанных IP адресов. Следует отметить, что мы можем запрещать доступ используя короткие IP адреса, например 192.168.

Для запрещения запросов отдельных user-agent, нам следует сделать следующее:

RewriteCond %{HTTP_USER_AGENT} ^OrangeSpider

RewriteRule ^(.*)$ http://%{REMOTE_ADDR}/$ [r=301,l]

В этом примере, все клиенты со строкой HTTP_USER_AGENT начинающейся на OrangeSpider (плохой бот) будут направлены по обратному адресу. Регулярное выражение предрасполагает, что может быть любой символ (.) ноль или больше раз (*), и перенаправляет на %{REMOTE_ADDR}. Флаг L, мы используем как инструкцию для сервера, выполнять это указание первым. Никакой процесс не будет выполняться перед выполнением этого правила.

Пример .htaccess кэширования

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

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

Если вы проверите свой сайт через Google PageSpeed, то получите сообщение об установках сроков кэширования (far-future expiry headers). Это делается следующим образом:

ExpiresActive on

ExpiresByType image/gif                 ";access plus 1 month";

ExpiresByType image/png                 ";access plus 1 month";

ExpiresByType image/jpg                 ";access plus 1 month";

ExpiresByType image/jpeg                ";access plus 1 month";

ExpiresByType video/ogg                 ";access plus 1 month";

ExpiresByType audio/ogg                 ";access plus 1 month";

ExpiresByType video/mp4                 ";access plus 1 month";

ExpiresByType video/webm                ";access plus 1 month";

Вы можете применять ExpiresByType, для определения различных типов контента, для которых вы хотите применить кэширование. Указание ExpiresActive on, просто убеждается в том, что генерация Expires headers доступна. Доступность определяется наличием установленного модуля mod_expires на сервер Apache.

Пример сжатия на .htaccess

Еще одно полезное применение, это возможность сжатия некоторых типов, и то также доступно с помощью .htaccess. Смотрим на примере:

FilterDeclare   COMPRESS

FilterProvider  COMPRESS  DEFLATE resp=Content-Type $text/html

FilterProvider  COMPRESS  DEFLATE resp=Content-Type $text/css

FilterProvider  COMPRESS  DEFLATE resp=Content-Type $text/javascript

FilterChain     COMPRESS

FilterProtocol  COMPRESS  DEFLATE change=yes;byteranges=no

Эти сжатия работают на серверах Apache 2.1 и выше, которые используют модуль mod_filter. Этот модуль использует алгоритм сжатия DEFLATE, который основан на указании content-type. В этом случае мы определяем text/html, text/css и text/javascript.

В примере выше, мы начинаем с декларации фильтра COMPRESS, используя директиву FilterDeclare. Далее мы перечисляем типы файлов, которые будут проходить через фильтр. Директива FilterChain, дает указание серверу строить звено фильтра, основанное на директивах FilterProvider. Директива FilterProtocol позволяет нам определить опции, применяемые для звена фильтра, когда он будет запущен. В примере мы используем change=yes (контент должен быть изменен с помощью фильтра (в этом случае сжат)), и byteranges=no (фильтр должен быть применен для определенных файлов).

В более старых версиях Apache, модуль mod_deflate также использовался для настройки DEFLATE сжатия. Мы имели меньше возможностей в настройках, но они были проще:

SetOutputFilter DEFLATE

AddOutputFilterByType DEFLATE text/html text/css text/javascript

В этом случае мы устанавливаем алгоритм сжатия с помощью директивы SetOutputFilter, и определяем типы контента, которые мы хотим сжать используя директиву AddOutputFilterByType

Как правило, ваш веб сервер использует один из этих модулей, в зависимости от версии Apache. В основном, если вы разрабатываете свой проект, вы знаете, какой код следует использовать. Но если вы разрабатываете продукт, и не знаете, на каком сервере он будет использован, вам следует использовать оба кода сразу. Для этого оба кода необходимо взять в директиву <IfModule module_name>, это определит, какой из этих модулей используется, и сервер не возвратит 500 ошибок о попытке настройки модуля, которого не существует.

Заключение

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

Дальше: MiraLinks - как зарабатывать, отзывы о миралинкс, цены в miralinks


.htaccess примеры

Для чего служит .htaccess?

Набирая адрес в строке браузера, вы получаете на свой компьютер файлы, которые отображает браузер. Управление тем, какие файлы и как вам показывать (пересылать) осуществляет веб-сервер. Наиболее популярных серверов два: IIS и Apache.
Как и любая программа, веб-сервер имеет определенные настройки. Но, у вас, как пользователя Апача может (и скорее всего не будет, если говорить о виртуальном хостинге) прав менять конфигурацию Апача через его главные файлы, действие которых распространяется на всех пользователей этого сервера. Но, вы можете менять некоторые конфигурационные файлы, который распространяют свое действие только на ваш сайт. Один из таких файлов - .htaccess
Это файл гибкой настройки веб-сервера Апач. "Гибкий" обозначает, что как только вы поменяли что-то в этом файле, изменения тут же вступают в силу. С помощью него можно переопределить многие директивы из файла httpd.conf (этот файл является главным конфигурационным файлом сервера Апач и его действия распространяются полностью на всех пользователей данной копии Апача). В случаях, когда у вас нет доступа в файлу настройки Апача (тот же виртуальный хостинг), вам поможет именно этот файл.

Этот файл не доступен веб-пользователю из браузера. Если файл .htaccess расположен в корневой директории сервера, то его действия распространяется на весь сервер, кроме тех папок, где находится другой файл .htaccess (и кроме всех папок "ниже" этой папки со вторым .htaccess).
Пример:
Структура ваших директорий на сервере такая:

|-user
| |
|  -user1
|        |
|         -user2
|
|-data
| |
|  -data1
|      |
|       -data2
|

Директории user1 и user2 будут вложенными по отношению к директории user. Если мы поместим в директорию www файл .htaccess, то его действие будет автоматически распространяться и на директории user1 и user2.
В директорию data помещаем другой файл .htaccess, по-сравнению, с тем, что находится в директории user. И для директорий data1 и data2 будет действовать файл .htacсess, находящийся в data.

Теперь, в директорию user2 мы помещаем еще один файл .htaccess, который отличен от того, что находится в директории 2мя уровнями выше (это директория user). В итоге, настройки для директории user2 будут определяться только тем файлом .htaccess, который находится в этой директории.
Так как чаще всего Апач настроен так, что всегда ищет этот файл в директории, то .htaccess поможет вам быстро и без останова сервера произвести его перенастройку.


Синтаксис .htaccess

Вот обязательной синтаксис, несоблюдение которого приводит к ошибкам сервера:
- пути к файлам (директориям) указываются от корня сервера. Пример: /opt/home/www.astanafoto.com/htdocs/config/.htpasswords
- домены с указанием протокола
Пример: Redirect / http://www.site.ru

Файл имеет название именно "точка" htaccess
Должен быть записан в UNIX-формате. Для оболочки FAR, достигается F4 (редактирование файла), Shift+F2 (выбрать "сохранить как UNIX-текст").


Как запретить веб-посетителям читать файлы в директории?

Запрет на все файлы:deny from all
Где all обозначает "все".


Разрешить доступ с определенного ip:order allow deny
deny from all
allow from <ваш ip>
В данном случае, <ваш ip> обозначает конкретный адрес.
Например:order allow deny
deny from all
allow from 192.126.12.199


Запретить доступ с определенного ip:order allow deny
deny from all
deny from <ваш ip>
Использование <ваш ip> аналогично для примера выше.

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

Например мы хотим запретить (блокировать) доступ с IP 81.222.144.12 и 81.222.144.20 и разрешить всем остальным нам необходимо добавить в

.htaccess следующий код:

Order Allow,Deny
Allow from all
Deny from 81.222.144.12, 81.222.144.20

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

Order Deny,Allow
Deny from all
Allow from 81.222.144.12, 81.222.144.20

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

  • для доменного имени (или его части):
    Allow from apache.org
    Allow from .net example.edu
  • для ip адреса:
    Allow from 10.1.2.3
    Allow from 192.168.1.104 192.168.1.205
  • для части ip адреса:
    Allow from 10.1
    Allow from 10 172.20 192.168.2
  • для пары сеть/маска:
    Allow from 10.1.0.0/255.255.0.0
  • для сети/nnn CIDR спецификации:
    Allow from 10.1.0.0/16 

Запрет на группу файлов по маске:<Files "\.(inc|sql|...другие расширения...)$">
order allow,deny
deny from all
</Files>
Определяет доступ к файлу по его расширению.
Например запрет на доступ к файлам с расширениям "inc" для веб-посетителей:
<Files "\.(inc)$">
order allow,deny
deny from all
</Files>

В данном примере сам веб-сервер Апач может обращаться к файлам с таким расширениям.


Запрет на конкретный файл:
Можно поставить запрет на конкретный файл по его названию и расширению.<Files config.inc.php>
order allow,deny
deny from all
</Files>
В данном примере стоит запрет на обращения к файлу config.inc.php.


Пароль на директорию:AuthName "Private zone"
AuthType Basic
AuthUserFile /pub/home/твой_логин/.htpasswd
require valid-user
</Files>
Значение AuthName будет выводиться для посетителя и может использоваться для пояснения запроса авторизации. Значение AuthUserFile указывает на место, где хранится файл с паролями для доступа к данной директории. Этот файл создается специальной утилитой htpasswd.exe.

Например в директории, которую защищаем паролем создаем такой .htaccess:AuthName "For Registered Users Only"
AuthType Basic
AuthUserFile /pub/site.ru/.htpasswd
require valid-user
</Files>
В этом примере, посетитель при запросе директории, будет читать фразу "For Registered Users Only", файл с паролями для доступа должен лежать в директории /pub/site.ru/ и называться .htapasswd . Директория указывается от корня сервера, если вы неправильно зададите директорию, то Апач не сможет прочитать файл .htpasswd и никто не получит доступа к данной директории.


Пароль только на 1 файл:сайт источник http://yapro.ru Tue Feb 09 2010 15:44:59 GMT+0300
Аналогично паролированию директории полностью, можно ставить пароль только на 1 файл.
Пример установки пароля на файл private.zip:<Files private.zip>
AuthName "Users zone"
AuthType Basic
AuthUserFile /pub/home/твой_логин/.htpasswd
</Files>


Пароль на группу файлов:
Аналогично, используя <Files "\.(inc|sql|...другие расширения...)$">, можно ставить пароли по маске файлов.

Пример установки пароля на доступ ко всем файла с расширением "sql":
<Files "\.(sql)$">
AuthName "Users zone"
AuthType Basic
AuthUserFile /pub/home/твой_логин/.htpasswd
</Files>


Проверка прав доступа

Задача: есть каталог a1 и в нем два вложенных каталога a2, a3, введено 2 уровня пользователей. 1 группа имеет доступ только к a1 и a2, 2-я ко всем трем каталогам. Необходимо проводить аутентификацию только 1 раз - при доступе к a1, но при этом соблюдать права на доступ к а2 и а3.
Ник и пароль запрашиваются только при входе на а1 - если у юзвера есть доступ на а2 пароль уже не запрашивается. Если на а3 доступа нет, вылетит табличка "введите пароль".
www.site.ru/a1
www.site.ru/a1/а2
www.site.ru/a1/a3
a1 - общий и вместе с тем закрытый. а2 и а3 только для отдельных личностей.


файл .htaccess для каталога а1:AuthName "Input password"
AuthType Basic
AuthUserFile "/pub/home/login/htdocs/clousearea/.htpasswd"
<Files *.*>
require valid-user
</Files>
файл .htaccess для каталога а2: AuthName "Input password"
AuthType Basic
AuthUserFile "/pub/home/login/htdocs/clousearea/.htpasswd"
<Files *.*>
require user юзвер1 юзвер2 юзвер3
</Files *.*>
файл .htaccess для каталога а3: AuthName "Input password"
AuthType Basic
AuthUserFile "/pub/home/абв/htdocs/clousearea/.htpasswd"
<Files *.*>
require user юзвер1 юзвер4 юзвер5
</Files *.*>


Как сделать перенаправление (редирект) посетителя?

Редирект на другой url:
Что бы сделать перенаправления посетителя на сайт http://site.ru в .htaccess Redirect / http://www.site.ru


Показ разных страниц, в зависимости от IP адреса посетителя:SetEnvIf REMOTE_ADDR <нужный ip адрес> REDIR="redir"
RewriteCond %{REDIR} redir
RewriteRule ^/$ /another_page.html
Например, перенаправление посетителей с ip адресом 192.12.131.1 на страницу about_my_sity.html:SetEnvIf REMOTE_ADDR 192.12.131.1 REDIR="redir"
RewriteCond %{REDIR} redir
RewriteRule ^/$ /about_my_sity.html


Перенаправление посетителя при запросе определенных страниц:
Это уже для всех сетевых вирусов и сканеров. Теперь любой запрос с адресом /_vti_bin будет автоматически перенаправляться на Microsoft: redirect /_vti_bin http://www.microsoft.com
redirect /scripts http://www.microsoft.com
redirect /MSADC http://www.microsoft.com
redirect /c http://www.microsoft.com
redirect /d http://www.microsoft.com
redirect /_mem_bin http://www.microsoft.com
redirect /msadc http://www.microsoft.com
RedirectMatch (.*)\cmd.exe$ http://www.microsoft.com$1


Как сделать стартовой другую страницу?

Что бы поменять страницу, которая будет показываться при обращении к директории, пишем:DirectoryIndex <нужная страница>Можно указывать несколько страниц.DirectoryIndex index.shtml index.php index.php3 index.html index.htm


Как заставить Апач обрабатывать SSI директивы?

SSI позволяют "собирать" страницу из кусочков. В одном кусочке у вас код меню, в другом код верхней части страницы, в третьем - нижней. А посетитель видет обычную страницу, которая состоит из того кода, который входит в ваши кусочки.
Необходимы обязательные установки в httpd.conf:
В блоке, начинающемся с <Directory/> и заканчивающийся </Directory> в строку Options Indexes добавьте Includes.

После, в файле .htaccess пишем:
AddHandler server-parsed .shtml .shtm .html .htm


Как заставить Апач выполнять в html документах php код?

Иногда бывает полезно "обмануть" посетителя, выдавая ему свои php-скрипты или иные файлы, как html файлы. Реально используется для индексации поисковой системой Rambler php-скриптов. Некоторые делаю мелкие фишки, вроде того, что дают фалам расширения совпадающие с какими-либо "знаковыми" именами. Например, на сайте www.osg.ru используются файлы с расширением osg: index.osg, script.osg и т.п.
RemoveHandler .html .htm
AddType application/x-httpd-php .php .htm .html .phtml
При большой посещаемости сервера может вызвать тормоза. Спрашивайте у админа.


Как самому обрабатывать ошибки Апача?

Наиболее интересные и полезные ошибки Апача это: 403-404, 500.
403 - пользователь не прошел аутентификацию, запрет на доступ (Forbided).
404 - запрашиваемый документ (файл, директория) не найден.
500 - внутренняя ошибка сервера (к примеру, ошибка в синтаксисе файла .htaccess).
Для того, что бы пользователю при этих ошибках были показаны ваши собственные сообщения об ошибках, в .htaccess пишем:
ErrorDocument 403 /errors/403.html
ErrorDocument 404 /errors/404.html
ErrorDocument 500 /errors/500.html
При этом при возникновении 404 ошибки пользователю загрузится файл errors/403.html.


Удобно делать собственный обработчик на некоторые ошибки. В .htaccess пишем:ErrorDocument 403 /errors/error.php?403
ErrorDocument 404 /errors/error.php?404
ErrorDocument 500 /errors/error.php?500
В error.php через $HTTP_SERVER_VARS['REQUEST_URI'] определяем какой документ вызвал ошибку и дальше обрабатываем. Если в .htaccess на ErrorDocument стоит указание файла с полным путем (http://site.ru/error.php), то $HTTP_SERVER_VARS['REQUEST_URI'] будет содержать этот файл, а не вызвавший ошибку.
В Internet Explorer 5.0 неправильно обрабатывается файл, вызывающийся при ошибке, если его размер меньше 1 килобайта. Будет вызвана стандартная страница IE 404.

Как поставить запрет на отображение содержимого директории при отсутствии индексного файла?

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

Options -Indexes


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

На заре интернета и зарождения браузеров, часто была ситуация, что браузер не мог автоматически определить, в какой из русских кодировок написан документ и в браузер выдавалась какая-то каша. Для избежания этого указываем, что все отдаваемые страницы будут иметь кодировку windows-1251:
AddDefaultCharset windows-1251


Можно ли указать кодировку на загружаемые файлы?

При загрузке посетителем файла на сервер, возможна перекодировка его - указываем, что все получаемые файлы будут иметь кодировку windows-1251:
CharsetSourceEnc windows-1251


Создал файл .htaccess, но сервер выдает 500 ошибку - Internal Erorr

Ошибка синтаксиса или файл записан не в том формате.
Смотрите вопрос #2.

Идеальный .htaccess (htaccess rewriterule примеры)

Мы уже писали о файле .HTACCESS, в статье «Настройка .htaccess. Полное руководство«, но тема болезненная для многих оказалась и непонятная.

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

Итак: htaccess rewriterule примеры, описания.

htaccess как создать? — читаем, копируем код, правим под себя.

htaccess где находится? — в идеале — в каждой папке на сайте (сервере) свой. Но в большинстве случаев — это не нужно, достаточно одного в корневой директории.

htaccess кодировка — в идеале — UTF-8 (все-таки это служебный файл сервера) htaccess utf 8 — верное решение.

htaccess rewriterule примеры:

# REWRITE
 <IfModule mod_rewrite.c>
 RewriteEngine on
 RewriteBase /
 RewriteCond %{HTTP_HOST} ^serg-casper
 RewriteRule (.*) http://www.info-business.pro/$1 [R=301,L]
 RewriteCond %{THE_REQUEST} ^[A-Z]{3,9} /index.php HTTP/
 RewriteRule ^index.php$ http://www.info-business.pro/ [R=301,L]
 RewriteCond %{REQUEST_FILENAME} !-f
 RewriteCond %{REQUEST_FILENAME} !-d
 RewriteRule ^(.*)$ index.php [L,QSA]
 </IfModule>

301 редирект htaccess или  htaccess редирект на другой домен (htaccess redirect):

# REDIRICT __________________
 # 301 простой редерикт
 # Redirect 301 /index.html /index.php
 # http://www.info-business.pro - URL На который мы перенаправляем запросы
 # Полезно в случаях когда надо полностью перенаправлять людей с одного сайта на другой.
 # Redirect / http://www.info-business.pro

htaccess запретить доступ к папке: 

нам поможет все тот-же «htaccess deny from all»

<Directory /home/папка>
 Options -Indexes
 order deny,allow
 deny from all
 </Directory>

htaccess доступ по ip:

Если необходимо запретить доступ с определенного IP-адреса — это будет выглядеть так:

Order allow,deny
 allow from all
 Deny from 198.69.132.24

Закрыть доступ ВСЕМ, кроме определенных IP:

Order deny,allow
 deny from all
 # Список IP через пробел, с которых доступ разрешен
 Allow from 194.111.70.48 194.78.47.128

Все правила с комментариями, так что сложностей и трудностей возникнуть не должно. htaccess пример:

# Этот .htaccess поможет сделать ваш сайт быстрей.
# Пользуйтесь на здоровье себе и вашему сайту.
# Сайт: http://www.info-business.pro

# !!!!!!!! При использовании фрагментов кода меняем http://www.info-business.pro на свой адрес сайта, 
# !!!!!!!! а ^serg-casper аналогично на свой домен.

Options All -ExecCGI -Indexes -Includes +FollowSymLinks
#Options -MultiViews

# REWRITE ___________________
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /
RewriteCond %{HTTP_HOST} ^serg-casper
RewriteRule (.*) http://www.info-business.pro/$1 [R=301,L]
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9} /index.php HTTP/
RewriteRule ^index.php$ http://www.info-business.pro/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php [L,QSA]
</IfModule>

# REDIRICT __________________
# 301 простой редерикт
# Redirect 301 /index.html /index.php
# http://www.info-business.pro - URL На который мы перенаправляем запросы
# Полезно в случаях когда надо полностью перенаправлять людей с одного сайта на другой.
# Redirect / http://www.info-business.pro

<IfModule mod_rewrite.c>
# RewriteRule ^news/([^/.]+)/?$ news.php?news=$1 [L]
# RewriteRule ^(.*.((js)|(css)))$ plugin/GzipFile.php?file=$1 [QSA,NE,L]
# RewriteRule .css$ plugin/GzipFile.php?file=$1
# RewriteRule .js$ plugin/GzipFile.php?file=$1
# Круглые скобки () используются для выделения групп символов. В дальнейшем к ним можно обращаться по номеру.
# Символ ^ обозначает начало строки.
# Символ $ обозначает конец строки.
# Символ . обозначает любой символ.
# Символ | обозначает альтернативу. Например, выражения "A|B" означают "A или B".
# Символ ? ставится после символа (группы), который может как присутствовать, так и отсутствовать.
# Символ * ставится после символа (группы), который может отсутствовать или присутствовать неограниченное число раз подряд.
# Символ + действует аналогично символу * с той лишь разницей, что предшествующий ему символ обязательно должен присутствовать хотя бы один раз.
# Квадратные скобки [] используются для перечисления допустимых символов.
# Квадратные скобки [^] используются для перечисления недоступных символов.
# Символ  ставится перед спецсимволами, если они нужны в своем первозданном виде.
# Все, что расположено после символа '#', считается комментарием.
</IfModule>

# RedirectMatch 301 /blog(.*) http://www.info-business.pro/blog$1
# SECURE ____________________
<IfModule mod_ssl.c>
# SSLOptions +StrictRequire
# SSLRequireSSL
# SSLRequire %{HTTP_HOST} eq "iblog.su"
</IfModule>

<IfModule mod_rewrite.c>
# RewriteCond %{HTTPS} !on
# RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
# RewriteCond %{SERVER_PORT} !^443
# RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
# $n - (0 <= n <= 9) предоставляющие доступ к сгруппированным частям (в круглых скобках!) шаблона из соответствующей директивы RewriteRule (единственной, следующей сразу за текущим набором директив RewriteCond).
# %n - (1 <= n <= 9) предоставляющие доступ к сгруппированным частям (в круглых скобках!) шаблона из соответствующей директивы RewriteCond в текущем наборе условий.
# %{NAME_OF_VARIABLE} - где NAME_OF_VARIABLE может быть одной из ниже приведенных переменных
# HTTP_USER_AGENT Содержит информацию о типе и версии браузера и операционной системы посетителя.
# HTTP_REFERER Приводится адрес страницы, с которой посетитель пришёл на данную страницу.
# HTTP_COOKIE Список COOKIE, передаваемых браузером
# HTTP_FORWARDED Страница непосредственно, с которой перешел пользователь
# HTTP_HOST Адрес сервера, например, roocms.com
# HTTP_ACCEPT Описываются предпочтения клиента относительно типа документа.
# REMOTE_ADDR IP-адрес посетителя.
# REMOTE_HOST адрес посетителя в нормальной форме — например, 23.beeline.ru
# REMOTE_IDENT Имя удаленного пользователя. Имеет формат имя.хост, например, starter.www.rutt.net.ru
# REMOTE_USER Тоже, что и REMOTE_IDENT, но содержит только имя. Пример: starter
# REQUEST_METHOD Позволяет определить тип запроса (GET или POST). Должен обязательно анализироваться, т.к. определяет дальнейший способ обработки информации
# SCRIPT_FILENAME Полный путь к веб-странице на сервере.
# PATH_INFO Содержит в себе все, что передавалось в скрипт.
# QUERY_STRING Содержит строчку, переданную в качестве запроса при вызове CGI скрипта.
# AUTH_TYPE Используется для идентификации пользователя
# DOCUMENT_ROOT Cодержит путь к корневой директории сервера.
# SERVER_ADMIN Почтовый адрес владельца сервера, указанный при установке.
# SERVER_NAME Адрес сервера, типа idea.roocms.com
# SERVER_ADDR IP-адрес вашего сайта.
# SERVER_PORT Порт, на котором работает Apache.
# SERVER_PROTOCOL Версия HTTP протокола.
# SERVER_SOFTWARE Название сервера, например, Apache/1.3.2 (Unix)
# TIME_YEAR TIME_MON TIME_DAY TIME_HOUR TIME_MIN TIME_SEC TIME_WDAY TIME
# Переменные предназначены для работы со временем в разных форматах.
# API_VERSION Это версия API модуля Apache (внутренний интерфейс между сервером и модулем) в текущей сборке сервера, что определено в include/ap_mmn.h.
# THE_REQUEST Полная строка HTTP запроса отправленная браузером серверу (т.е., «GET /index.html HTTP/1.1»). Она не включает какие-либо дополнительные заголовки отправляемые браузером.
# REQUEST_URI Ресурс, запрошенный в строке HTTP запроса.
# REQUEST_FILENAME Полный путь в файловой системе сервера к файлу или скрипту соответствующим этому запросу.
# IS_SUBREQ Будет содержать текст «true» если запрос выполняется в текущий момент как подзапрос, «false» в другом случае. Подзапросы могут быть сгенерированы модулями которым нужно иметь дело с дополнительными файлами или URI для того чтобы выполнить собственные задачи.
# Внимание!
# Данная конфигурация файла может порождать побочные запросы к индексному файлу вашего сайта
# в случаях когда в вашей верстке или скриптах содержаться ошибки или ссылки на несуществующие файлы или папки.
# Подобные обращения в большом числе могут вызвать нагрузку на ваш веб сервер. 1 ошибка = 1 лишнему обращению.
# Будьте внимательны. Перед использованием данного файла проверьте файлы access.log и error.log сгенерированные вашим Apache сервером.
# Если вы обнуружите ошибки в ваших скриптах, исправьте их перед использованием на "боевом сервере"
# Блокировать любой запрос, пытающийся испортить base64_encode через URL
RewriteCond %{QUERY_STRING} base64_encode[^(]*([^)]*) [OR]
# Блокировать любой запрос, содержащий тег <script> в URL
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
# Блокировать любой запрос, пытающийся установить значение глобальных переменных PHP через URL
RewriteCond %{QUERY_STRING} GLOBALS(=|[|%[0-9A-Z]{0,2}) [OR]
# Блокировать любой запрос, пытающийся изменить _REQUEST переменную через URL
RewriteCond %{QUERY_STRING} _REQUEST(=|[|%[0-9A-Z]{0,2})
# Перенаправлять заблокированные запросы
RewriteRule .* index.php [F]
# и запрошенный путь не соответствует пути к физическому файлу
RewriteCond %{REQUEST_FILENAME} !-f
# и запрошенный путь не соответствует пути к физической папке
RewriteCond %{REQUEST_FILENAME} !-d
# то перенаправить запрос на скрипт index.php
RewriteRule .* index.php [L]
RedirectMatch 301 regexp /error410.html
</IfModule>

# HOTLINKING ________________
<IfModule mod_rewrite.c>
# RewriteCond %{HTTP_REFERER} !^$
# RewriteCond %{HTTP_REFERER} !^http://([ -a-z0-9] .)?ibog.su [NC]
# RewriteRule .(gif|jpe?g|png)$ - [F,NC,L]
</IfModule>

# HANDLER ___________________
AddHandler application/x-httpd-php .html
AddHandler cgi-script .pl .py .jsp .asp .htm .shtml .sh .cgi
AddType application/x-javascript .js
AddType application/json .json
AddType text/css .css
AddType text/xml .xml
# Audio
AddType audio/ogg .oga .ogg
AddType audio/mp4 .m4a .f4a .f4b
# Video
AddType video/ogg .ogv
AddType video/mp4 .mp4 .m4v .f4v .f4p
AddType video/webm .webm
AddType video/x-flv .flv
# SVG
AddType image/svg+xml .svg .svgz
AddEncoding gzip .svgz
# Webfonts
AddType application/vnd.ms-fontobject .eot
AddType application/x-font-ttf .ttf .ttc
AddType font/opentype .otf
AddType application/x-font-woff .woff
# Assorted types
AddType image/x-icon .ico
AddType image/webp .webp
AddType text/cache-manifest .appcache .manifest
AddType text/x-component .htc
AddType application/xml .rss .atom .xml .rdf
AddType application/x-chrome-extension .crx
AddType application/x-opera-extension .oex
AddType application/x-xpinstall .xpi
AddType application/octet-stream .safariextz
AddType application/x-web-app-manifest+json .webapp
AddType text/x-vcard .vcf
AddType application/x-shockwave-flash .swf
AddType text/vtt .vtt
AddType application/octet-stream .doc .mov .avi .pdf .xls .rar .zip .mp3 .wmv .ppt .tar .gz .docx .xlsx
# ForceType application/x-httpd-php
# INDEX FILE ________________
DirectoryIndex index.php
# GZIP ______________________
<IfModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
mod_gzip_item_include mime ^text.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_include mime ^application/x-font-woff.*
mod_gzip_item_exclude mime ^image.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</IfModule>
<ifModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/css text/javascript application/javascript application/x-javascript application/x-font-woff image/jpg image/jpeg
</ifModule>
# PHP _______________________
php_value	upload_max_filesize 32M
php_value	post_max_size 10M
php_value	default_charset utf-8
php_flag	magic_quotes_gpc Off
php_flag	register_globals Off
php_flag	short_open_tag On
# php_value max_input_time 200
# php_value session.name sid
php_value	error_reporting 0
php_flag	display_startup_errors off
php_flag	display_errors off
php_flag	html_errors off
php_flag	log_errors off
php_flag	ignore_repeated_errors on
php_flag	ignore_repeated_source on
# php_value log_errors_max_len 1024
php_flag	report_memleaks off
php_flag	track_errors off
php_value	docref_root 0
php_value	docref_ext 0
# php_value error_log /tmp/php_error.log
# php_value error_prepend_string " "
# php_value error_append_string " "
<Files php_error.log>
Order allow,deny
Deny from all
Satisfy All
</Files>
<IfModule php5_module>
# php_value session.cookie_httponly true
</IfModule>
# XDEBUG ___________________
# Настройки для расширения XDebug
#php_flag xdebug.profiler_enable On
#php_flag xdebug.extended_info On
#php_flag xdebug.remote_enable off
#php_flag xdebug.auto_trace off
# OTHER SETTINGS ____________
<IfModule mod_setenvif.c>
SetEnv TZ Europe/Moscow
</IfModule>
ServerSignature Off
# AddDefaultCharset UTF-8
# AddCharset utf-8 .atom .css .js .json .rss .vtt .xml
# CACHE AND Headers _________
<ifModule mod_headers.c>
<FilesMatch ".(html|htm)$">
Header set Cache-Control "max-age=43200"
</FilesMatch>
<FilesMatch ".(js|css|txt)$">
Header set Cache-Control "max-age=604800"
</FilesMatch>
<FilesMatch ".(flv|swf|ico|gif|jpg|jpeg|png|jpe?g)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>
<FilesMatch ".(pl|php|cgi|spl|scgi|fcgi)$">
Header unset Cache-Control
</FilesMatch>
<FilesMatch ".(ttf|ttc|otf|eot|woff|font.css)$">
Header set Access-Control-Allow-Origin "*"
</FilesMatch>
<FilesMatch ".(js|css|gif|png|jpe?g|pdf|xml|oga|ogg|m4a|ogv|mp4|m4v|webm|svg|svgz|eot|ttf|otf|woff|ico|webp|appcache|manifest|htc|crx|oex|xpi|safariextz|vcf)$" >
Header unset X-UA-Compatible
</FilesMatch>
</IfModule>
<ifModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 5 seconds"
ExpiresByType image/x-icon "access plus 2592000 seconds"
ExpiresByType image/jpeg "access plus 2592000 seconds"
ExpiresByType image/png "access plus 2592000 seconds"
ExpiresByType image/gif "access plus 2592000 seconds"
ExpiresByType video/ogg "access plus 1 month"
ExpiresByType audio/ogg "access plus 1 month"
ExpiresByType video/mp4 "access plus 1 month"
ExpiresByType video/webm "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
ExpiresByType text/css "access plus 604800 seconds"
ExpiresByType text/javascript "access plus 604800 seconds"
ExpiresByType application/javascript "access plus 604800 seconds"
ExpiresByType application/x-javascript "access plus 604800 seconds"
ExpiresByType text/html "access plus 43200 seconds"
ExpiresByType application/xhtml+xml "access plus 600 seconds"
ExpiresByType text/xml "access plus 600 seconds"
ExpiresByType application/xml "access plus 600 seconds"
ExpiresByType application/json "access plus 600 seconds"
ExpiresByType application/rss+xml "access plus 1 hour"
ExpiresByType application/atom+xml "access plus 1 hour"
ExpiresByType text/x-component "access plus 1 week"
ExpiresByType application/x-font-ttf "access plus 1 month"
ExpiresByType font/opentype "access plus 1 month"
ExpiresByType application/x-font-woff "access plus 1 month"
ExpiresByType image/svg+xml "access plus 1 month"
ExpiresByType application/vnd.ms-fontobject "access plus 1 month"
</ifModule>
# Bad Rquest
ErrorDocument 400 /index.php?page=e400
# Authorization Required
ErrorDocument 401 /index.php?page=e401
# Forbidden
ErrorDocument 403 /index.php?page=e403
# Not found
ErrorDocument 404 /index.php?page=e404
# Method Not Allowed
ErrorDocument 405 /index.php?page=e405
# Request Timed Out
ErrorDocument 408 /index.php?page=e408
# Request URI Too Long
ErrorDocument 414 /index.php?page=notfound
# Internal Server Erro
ErrorDocument 500 /index.php?page=notfound
# Not Implemented
ErrorDocument 501 /index.php?page=notfound
# Bad Gateway
ErrorDocument 502 /index.php?page=notfound
# Service Unavailable
ErrorDocument 503 /index.php?page=notfound
# Gateway Timeout
ErrorDocument 504 /index.php?page=notfound

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

P.S. Автор кода: alex Roosso, спасибо ему. >> http://habrahabr.ru/post/154643/

Настройка .htaccess [АйТи бубен]

.htaccess (с точкой в начале имени) – файл, который дает возможность конфигурировать работу сервера, не предоставляя доступа к главному конфигурационному файлу, в отдельных директориях . Например, установить права доступа к файлам в директории, изменять названия индексных файлов, обрабатывать самостоятельно ошибки Apache, перенаправляя посетителей на специальные страницы ошибок. Конфигурационные директивы сервера Apache размещены в файлe httpd.conf. Но у Вас не всегда будут права доступа к этому файлу. Если вы используете для хостинга виртуальный сервер, когда один сервер Apache обслуживает множество сайтов, то вам не позволят менять его конфигурацию. Тем не менее, вы можете конфигурировать работу сервера в своих директориях. Делать это можно с помощью файлов .htaccess. Файл .htaccess может размещаться в любом каталоге. Директивы его действуют на все файлы в текущем каталоге и во всех его подкаталогах (если эти директивы не переопределены директивами нижележащих файлов .htaccess). Изменения, в файле .htaccess, вступают в силу сразу и не требуют перезагрузки сервера, как от изменений, вносимых в главный конфигурационный файл httpd.conf.

Для того, что бы файлы .htaccess можно было использовать — необходимо настроить директиву Как включить AllowOverride в конфигурации Apache. Чтобы дать директивам файлов .htaccess максимальные права нужно прописать в httpd.conf: AllowOverride All.

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

  • Запретить доступ для всех ко всем файлам и директориям. Правила распространяются как на текущую так и на вложенные папки
    Order Deny,Allow
    Deny from all

    Разрешить доступ с определенного IP-адреса

    Order Deny,Allow
    Deny from all
    Allow from 195.135.232.70
    Allow from .example.com

    Строка order deny,allow определяет, порядок выполнения директивы. Вначале выполняется директива запрета доступа, затем разрешается доступ для IP- адреса 195.135.232.70. Если в первой строке поменять порядок следования директив на order Allow,Deny, то доступ для данного IP-адреса не будет открыть, так как директива deny, выполняемая последней перекроет действия директивы allow.

  • Изменение названия индексной страницы:
    DirectoryIndex index.html index.php index.shtml

    Указать можно несколько индексных страниц. При запросе каталога они будут искаться в том порядке, в котором перечислены в директиве DirectoryIndex. Если не будет найден файл index.html, будет произведен поиск файла index.php и т.д.

  • Выполнять код PHP в файлах HTML
    RemoveHandler .html .htm
    AddType application/x-httpd-php .php .htm .html .phtml
    AddHandler application/x-httpd-php .css

    Добавив эти строки в .htaccess вы дадите директиву серверу выполнять инструкции PHP не только в файлах с расширением *.php и *.phtml, но и в файлах с расширением *.htm и *.html.

  • Переопределение обработчиков для PHP и Perl. То есть в директории с этими настройкам все файлы будут восприниматься как текстовые.
    RemoveHandler .php .phtml .pl
    AddType text/plain .php .phtml .pl
  • Обработка ошибок Apache
    ErrorDocument 401 /401.html
    ErrorDocument 403 /403.html
    ErrorDocument 404 /404.html
    ErrorDocument 500 /500.html

    При возникновении этих ошибок посетитель будет перенаправлен на специально созданные страницы.

         401 ошибка — Требуется авторизация (Authorization Required).
         403 ошибка — пользователь не прошел аутентификацию, доступ запрещен (Forbided).
         404 ошибка — Документ не найден (Not Found).
         500 ошибка — Внутренняя ошибка сервера (Internal Server Error).
  • Запрет на отображение содержимого каталога при отсутствии индексного файла(например, index.html)
    Options -Indexes - запрещает отображение.
    Options Indexes или Options +Indexes - разрешает.
  • Определение кодировки (utf-8, windows-1251), в которой сервер "отдает" файлы
    AddDefaultCharset utf-8
    
  • Определение кодировки на загружаемые файлы
    CharsetSourceEnc windows-1251

HOWTO: .htaccess + mod_rewrite

Оригинал: HOWTO: .htaccess + mod_rewrite + RewriteCond + RewriteRule + regex

Поясню пример:

RewriteRule [^/.]/feed urllist.txt

мы имеем регулярное выражение в левой части: [^/.]/feed и выражение замены url в правой: urllist.txt В квадратных скобках стоит character set, т.е. набор символов. Набор (сам по себе) обозначает один единственный символ. Символы внутри набора задают правило, которому должен соответствовать символ. Крышка, поставленная вначале набора означает, что набор соответствует любому символу, кроме перечисленных в наборе после крышки. Т.е., в данном примере, это любой символ кроме слэша или точки. Следовательно перенаправление на urllist.txt будет всякий раз когда на конце встречается /feed, за исключением двух случаев: когда на конце

//feed (например http://feed)

и когда на конце

./feed (например ../feed)

Drupal RewriteRule

Рассмотрим стандартное RewriteRule СМС Drupal.

<IfModule mod_rewrite.c># если включен mod_rewrite
  RewriteEngine on      # включить движок Rewrite
  RewriteCond %{REQUEST_FILENAME} !-f # применять RewriteRule, только если
  #запрашиваемое имя файла не совпадает с именем какого-нибудь реального файла на сервере
  RewriteCond %{REQUEST_FILENAME} !-d # и не совпадает с именем какой-нибудь реальной директории
  RewriteRule ^(.*)$ index.php?q=$1 [L,QSA] # это правило рассмотрим подробнее ниже
</IfModule>

Левая часть: ^(.*)$ Крышка вначале означает начало строки. Бакс в конце означает конец строки. Точка в скобочках означает любой символ. Звездочка после точки означает, что любых символов может быть от нуля до бесконечности. Скобочки означают группу. Т.к. она первая (и единственная), то эта группа идет под номером 1. Правая часть: index.php?q=$1 означает, что мы перезаписываем url на index.php?q= и к этому добавляем первую группу $1, т.е. имя запрашиваемого файла. Немного о точках и крышках. В первом примере точка обозначала точку, потому что она была внутри набора символов. Во втором примере точка обозначала любой символ, потому что она была вне набора символов. В первом примере крышка играла роль оператора исключения. Во втором примере крышка обозначала начало строки.

Флаги [L,QSA] http://www.egoroff.spb.ru/portfolio/apache/mod_rewrite.html:

  • 'last|L' (последнее правило). Остановить процесс преобразования на этом месте и не применять больше никаких правил преобразований. Это соответствует оператору last в Perl или оператору break в языке C. Используйте этот флаг для того, чтобы не преобразовывать текущий URL другими, следующими за этим, правилами преобразований.

Шаблон проектирования MVC (Model-View-Controller)(Model-View-Controller) требует единой точки входа для всех запросов, т. е. все запросы должны начинать обрабатываться одним файлом, например index.php.

# Кодировка сайта:
AddDefaultCharset UTF-8

# Запрет на отображение содержимого каталога при отсутствии индексного файла(например, index.html)
#Options -Indexes

# Правило для url
# Включаем модуль RewriteEngine для создания единой точки входа
RewriteEngine On

# Правила для шаблон MVC
# Чтобы не обрабатывать файлом index.php графические файлы, css. 
# js файлы, а позволять их скачивать браузеру на прямую
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

# Перенаправлять все запросы на index.php
RewriteRule $ index.php [nocase,last]
> man htpasswd
NAME
       htpasswd - Manage user files for basic authentication
SYNOPSIS
       htpasswd [ -c ] [ -m ] [ -D ] passwdfile username
       htpasswd  -b  [  -c  ] [ -m | -d | -p | -s ] [ -D ] passwdfile username
       password
       htpasswd -n [ -m | -d | -s | -p ] username
       htpasswd -nb [ -m | -d | -s | -p ] username password

...

Настройка .htaccess можно использовать и для установки пароля на доступ к определенным страницам или разделам вашего сайта. Делается это путем создания в нужном подкаталоге файла .htaccess, в который пишется следующее:

AuthType Basic
AuthName "this is a test of protected realm"
AuthUserFile /path/to/file/with/passwords
<Limit GET POST>
require valid-user
</Limit>

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

Итак, изначально у нас еще нет файла с паролями и нам нужно его создать :

> htpasswd -c passwords test1
New password:
Re-type new password:
Adding password for user test1
>

После выполнения данной операции htpasswd создаст файл passwords, в котором окажется пользователь test1 и его пароль в зашифрованном виде:

> cat passwords
test1:zgco1KREjBY8M
>

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

> htpasswd passwords test2
New password:
Re-type new password:
Adding password for user test2

> cat passwords
test1:zgco1KREjBY8M
test2:eN3uA6t0kzV1c
>

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

В качестве параметра к директиве require мы указали valid-user. Это означает, что любой пользователь, который есть в используемом файле с паролями, может иметь доступ к защищенному ресурсу. Однако, согласитесь, удобно иметь все пароли в одном файле, а права на конкретные ресурсы давать только определенным пользователям. Это тоже реализуемо. Например, мы хотим дать доступ только пользователю test2. Делаем так : require user test2 Еще можно объединить пользователей в группы и давать доступ не конкретным логинам, а группам. Это можно сделать с помощью директивы AuthGroupFile: AuthGroupFile /path/to/file/with/groups В файле /path/to/file/with/groups создаем группы примерно так :

group1: test1 test5
group2: test2 test4
group3: test1 test3

Соответственно, директиву require будем использовать так: require group group3 Механизмы ограничения доступа, которые реализованы в Apache, позволяют очень гибко управлять правами для пользователей и групп, что является очень важной возможностью. Если углубиться в изучение предмета, Вы сможете узнать и то, что логины и пароли, используемые для авторизации, можно хранить не только в файлах, но и в простейших базах данных формата BerkeleyDB - почитайте документацию по директиве AuthDBGroupFile. Также для хранения данных авторизации можно использовать практически любую СУБД (MySQL или PostgreSQL).


htaccess.txt · Последние изменения: 2018/11/20 13:30 (внешнее изменение)

10 отличных приемов с .htaccess для WordPress / Habr

Внимание!
Перед изменением файла .htaccess не забудьте сделать его резервную копию.

1 — Перенаправляем WordPress RSS поток на feedburner с использованием .htaccess
Почему некоторые вебмастера не используют feedburner? Ведь это такой замечательный инструмент для контроля за подписками на RSS. Проблема в том, что приходится руками исправлять файлы шаблонов. Этот прием поможет сохранить Ваше время.
И не забудьте исправить в строке 6 на Ваш код

<IfModule mod_rewrite.c>
 RewriteEngine on
 RewriteCond %{HTTP_USER_AGENT} !FeedBurner    [NC]
 RewriteCond %{HTTP_USER_AGENT} !FeedValidator [NC]
 RewriteRule ^feed/?([_0-9a-z-]+)?/?$ httр://feeds2.feedburner.com/wordpress[R=302,NC,L]
</IfModule>

2 — Удалить /category/ из пути в адресе WordPress
По умолчанию категории в WordPress отображаются так: httр://www.wordpress.com/blog/category/wordpress
А это не очень красиво, да и адрес выглядит длинновато.
Сейчас Вы узнаете как исправить это с помощью .htaccess

RewriteRule ^category/(.+)$ httр://www.yourblog.com/$1 [R=301,L]

Теперь категории будут выглядеть как:
httр://www.wordpress.com/blog/wordpress

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

FileETag MTime Size
<ifmodule mod_expires.c>
  <filesmatch "\.(jpg|gif|png|css|js)$">
       ExpiresActive on
       ExpiresDefault "access plus 1 year"
   </filesmatch>
</ifmodule>

4 — Сжатие статических данных
Этот код уменьшит объём данных передаваемых между сервером и пользователем за счет их сжатия.

AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch bMSIE !no-gzip !gzip-only-text/html

5 — Перенаправление постоянных ссылок на основе Дня и имени на /%postname%/
Сначала зайдите в админку WordPress, зайдите в Settings → Permalinks и выберите custom.
Заполните поле с /%postname%/.
Теперь постоянные ссылки будут выглядеть так: httр://www.yourblog.com/name-of-the-post

Теперь нам нужно перенаправить все старые ссылки на новые постоянные.
Внесите в .htaccess следующие строки:

RedirectMatch 301 /([0-9]+)/([0-9]+)/([0-9]+)/(.*)$ httр://www.domain.com/$4

6 — Запретить комментирование если отсутствует referrer
Метод построен на том, что многие спам-боты не передают referer когда постят данные.
Этот код проверяет поле referrerи блокирует отправку комментария если отсутствует referer при обращении к файлу wp-comments-post.php.
Не забудьте в строке 4 вписать домен своего блога

RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post\.php*
RewriteCond %{HTTP_REFERER} !.*yourblog.com.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) ^http://%{REMOTE_ADDR}/$ [R=301,L]

7 — Перенаправить пользователя на страницу-заглушку
на время работ на сайте желательно перенаправлять пользователей на временную страницу-заглушку
Замените в строке 2 maintenance.html на название вашего файла.
И в строке 3 впишите свой IP, чтобы вас не перенаправляло на эту заглушку.

302-редирек используется чтобы поисковые системы не проиндексировали содержимое временной страницы.

RewriteEngine on
RewriteCond %{REQUEST_URI} !/maintenance.html$
RewriteCond %{REMOTE_ADDR} !^123\.123\.123\.123
RewriteRule $ /maintenance.html [R=302,L]

8 — Защита блога от хотлинков
Хотлик — это использование файлов размещенных на вашем сайте на страницах других сайтов с целью сэкономить свой серверный трафик.
Для борьбы с этой напастью помогут следующие строки в .htaccess

RewriteEngine On
#Replace ?mysite\.com/ with your blog url
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?mysite\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
#Replace /images/nohotlink.jpg with your "don't hotlink" image url
RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpg [L]

9 — Разрешить доступ к wp-admin только с Вашего IP
Дополнительной защитой Вашего блога от взлома может служить ограничение списка адресов, с которых разрешено заходить в админку блога.
Не забудьте вставить свой IP в строке 8.
Если Вы захотите использовать дополнительные адреса для доступа добавьте строки allow from xx.xx.xxx.xx

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName "Example Access Control"
AuthType Basic
<LIMIT GET>
order deny,allow
deny from all
allow from xx.xx.xx.xx
</LIMIT>

10 — Блокирование спамеров в WordPress через .htaccess
Часто спам-боты ходят с одних и техже IP. Следующий прием поможет блокировать доступ с этих адресов.
Внеси адрес спамера в строке 3.
Можно расширить список заблокированных адресов добавив строки deny from xxx.xx.xxx.xxx.

<Limit GET POST>
order allow,deny
deny from 200.49.176.139
allow from all
</Limit>

UPD: Оригинал статьи можно найти здесь. Наткнулся случайно, но не смог проигнорировать такие полезности, вот и вышло то, что вышло — эта статья.

Шпаргалка по модулю mod_rewrite сервера Apache

Шпаргалка по модулю mod_rewrite сервера Apache

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

Модуль mod_rewrite - это модуль сервера Apache, предоставляющий мощный функционал для выполнения различных преобразований над URL, которые Apache выполняет на лету. Этот модуль содержит синтаксический анализатор URL с возможностью применения регулярных выражений. Также модуль позволяет использовать при анализе URL не только сам URL, но и разные другие источники данных, как например переменные сервера, переменные окружения, HTTP заголовки, время и даже(!) запросы к внешним базам данных в разных форматах. Практически это значит, что получив URL Вы сможете синтаксически разобрать его на любые части как вы этого захотите. Затем вы сможете выполнить сравнения, с применением множества условий, любых частей вашего URL с большим количеством доступных параметров как из окружения сервера Apache так и ваших собственных, подставленных напрямую, так и полученных из баз данных. Затем, в зависимости от результатов сравнения, вы сможете выполнить различные преобразования над текущей строкой URL (с которой модуль в текущий момент работает) и даже сгенерировать части строки URL. Как следствие, на выходе вы можете получить новую строку URL, и теперь сервер Apache уже будет искать запрошенную страницу не по первоначальному URL, а уже по новому измененному вами URL. В добавок к этому вы можете определить или переопределить поведение apache при обработки вашего нового URL.  При помощи специальных флагов вы можете задать для apache как ему следует обрабатывать этот новый URL. Все эти действия в результате приведут или к внутренней обработке нового URL, или к внешнему перенаправлению запроса, или даже к прохождению его через внутренний прокси модуль –то все определите вы. Далее приведены некоторые из возможных поведений при обработке нового URL. Так как новый URL может быть любым - как внутренним, так и внешним, то произойдет внутренне или внешнее перенаправление с первоначального URL на ваш конечный преобразованный URL. При внутреннем перенаправлении, когда ваш новый URL ссылается на тот же сайт, что и в первоначальном URL, вы можете выполнить внутреннее перенаправление не изменяя строку адреса в браузере клиента, т.е. клиент даже не заметит, что на сервере произошло внутреннее перенаправление (обработка) его запроса, и он обратился по одному URL, а в действительности ответ он получил от другого URL. Для клиента будет виден, в этом случае, только URL по которому он обратился, о наличии внутреннего перенаправления он сможет только догадываться. Такое внутреннее перенаправление достаточно распространенный подход для систем управления контентом, когда все запросы к файлам PHP сайта перенаправляются на главный index.php системы управления контентом. Также внутренние перенаправление можно выполнить сделав изменение URL в браузере клиента с отправкой ему кода заголовка перенаправления (redirect), например, кода 301 Moved Permanently - постоянное перенаправление. Когда же новый, преобразованный вами URL будет уже ссылаться на другой сайт, то произойдет внешнее перенаправление. Также вы можете направить запрос на внутренний прокси сервер. Вы также можете определить и другие варианты поведения для нового 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)

Шпаргалка по модулю mod_rewrite сервера Apache


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


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

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

Пример:

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

Где:

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

[Флаги] RewriteRule Flags - это разделённый запятыми, заглавные спец символы, заключенные в квадратные скобки. Флаги дополняют преобразование URL.

В параметрах Подстановка из RewriteRule и СравниваемаяСтрока из RewriteCond доступны для использования подвыражения (то что заключено в скобки в РВ) - части регулярного выражения. Обращаться к подвыражениям в условиях RewriteCond нужкно как %N и в подвыражений в правилах RewriteRule как $N. Здесь N - это номер подвыражения по порядку в строке с регулярным выражением.

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

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

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

1.    ^(.*)$ - это Шаблон, регулярное выражение которое применится к текущему URI (без query string с GET параметрами). Кто знаком с регулярными выражении, сможет прочитать его так: искать в текущей строке URI от начала строки(знак ^) до конца строки(знак $) любой символ (знак .) в количестве от нуля до бесконечности (знак *). Так как в этом РВ есть скобки(), то та часть URI которая будет соответствовать условию в скобках будет захвачена в переменную подстановки $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' - значит добавить в конец нового URI исходную строку GET параметров запроса QUERY_STRING, которая содержится в серверной переменной %{QUERY_STRING}. Этот флаг указывает механизму преобразований на добавление, а не замену, строки параметров GET запроса из URI к строке Подстановка. Дело в том, что если ваш начальный URI содержит query string с GET параметрами, например: /pages/123?one=two, то по умолчанию RewriteRule преобразование отбрасывает эту query string с GET параметрами от URI. Если же добавить к RewriteRule флаг [QSA], то тогда первоначальная query string с GET параметрами будет добавлена в конец нового URI, преобразованного в RewriteRule.

Пример:

RewriteRule "/pages/(.+)" "/page.php?page=$1" [QSA]

В примере, при наличии [QSA] флага, запрошенный URI вида /pages/123?one=two будет преобразован в /page.php?page=123&one=two. Однако, без использования [QSA] флага, он уже будет преобразован в /page.php?page=123, где уже будет отсутствовать оригинальная первичная query string с GET параметрами.

 

Ну вот мы разобрали синтаксис простого примера директивы RewriteRule, теперь дело за синтаксисом директивы RewriteCond

Синтаксис RewriteCond:

RewriteCond СравниваемаяСтрока Условие [flags]

Где:
1.    СравниваемаяСтрока это строка которая будет проверятся на соответствие выражению, указанному в параметре Условие. СравниваемаяСтрока может, к примеру, содержать часть или весь URL. Подставить в параметр СравниваемаяСтрока часть URL можно при помощи переменных подстановки, которые были созданы в соответствующем RewriteRule. Также параметр СравниваемаяСтрока может содержать различные переменные (Server-Variables) из окружения web сервера Apache, например:

  • %{REQUEST_URI} - Строка URI запроса - это часть от полного URL без доменного имени и GET параметров вида "/pages/page/1/";
  • %{HTTP_HOST} - Строка с доменным именем, например: "andew.ru" или "www.andew.ru";
  • %{QUERY_STRING}    Строка GET параметров ,например, "?page=123&one=two".

Но в конечном итоге, после всех манипуляций, параметр СравниваемаяСтрока это всегда строка, которая передается в выражение из параметра Условие для проверки на истинность.

2.    Условие – это логическое выражение по которому проверяется параметр СравниваемаяСтрока. Часто в Условие применяют РВ.

3.    [flags] - третьим аргументом в директиве RewriteCond. Флаг позволяет задать дополнительные опиции, например, можно установить логику объединения правил RewriteCond через логическое И [AND] (по умолчанию) или через логическое ИЛИ [OR], или/и можно задать, будет ли сравнение в условии RewriteCond выполнятся с учетом регистра или без учета регистра, и много другое. Некоторые наиболее часто используемые флаги в условиях RewriteCond описаны мною ниже.

Пример1 - пример правила с набором условий:

RewriteCond $1 !^(index\.php|images|robots\.txt|public) [NC]

RewriteCond %{REQUEST_URI} !\.(css|js|jpg|gif|png)$

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

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

В примере1 мы видим, что директиве RewriteRule соответствует 4-е дополнительных условия (RewriteCond). Если правило начнет исполняться (об этом см. синтаксис правила), то механизм преобразований начнет по очереди обходить каждое из этих дополнительных условий, начиная с первого. Помним, что дополнительные условия стоят перед правилом. Если все дополнительные условия выполняться, произойдет преобразование URL. Если хотя бы одно дополнительное условие не выполниться, исполнение правила будет остановлено и преобразования URL не произойдет. Тут нужно заметить, что дополнительные условия объединены по умолчанию через оператор AND, хотя он явно не указан. Поэтому то и необходимо исполнение всех дополнительных условий.


Теперь разберем первое дополнительное условие из примера1:

RewriteCond $1 !^(index\.php|images|robots\.txt|public) [NC]


Где:
1.    параметр СравниваемаяСтрока содержит выражение $1 – это переменная подстановки, в которой находится значение из круглых скобок из параметра Шаблон директивы RewriteRule. Если мы посмотрим в параметр Шаблон то там содержится: ^(.*)$. Все это означает в данном случае, что в параметр СравниваемаяСтрока подставиться весь URL.
2.    Параметр Условие здесь содержит оператор инверсии (!)условия и регулярное выражение, которое вернет нам результат применения его к параметру СравниваемаяСтрока. В данном случае параметр Условие звучит как: не начинается с символов index.php или images или robots.txt или public.
3.    Флаг [NC] - 'nocase|NC' выполнять сравнение регистр независимо
В общем, это дополнительное условие будет звучать как: если без учета регистра URL не начинается с символов index.php или images или robots.txt или public то условие истинно.

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

Этот блок директив содержит одно правило преобразования URL и дополнительные условия для этого правила. Смысл этого блока – выполнить заданную проверку и преобразование URL. На словах это будет звучать так. Для любого URL запустить выполнение правила перезаписи URL. По ходу выполнение правила проверить что URL:
•    НЕ начинается как index.php или images или robots.txt или public – т.е. не начинается на открытые нами к прямому обращению файл и каталоги. Сравнение символов URL на соответствие в этом условии проводить без учета регистра.
•    НЕ заканчивается на .css или .js или … т.е. не является файлом к которым мы позволяем обращаться напрямую
•    НЕ является реальным файлом на диске
•    НЕ является реальной директорией на диске
Если все условия выполнились то сделать следующие преобразование URL – собрать итоговую строку URL из двух строк, где первая строка это “ index.php?/”, вторя строка это первоначальный URL. Флаг L – значит закончить на этом правиле все дальнейшие преобразования URL. Флаг QSA значит добавить значение из $1 к результирующей строке URL, а не заменить ее.
Вот такой получился блок обработки URL.

 

Пример2:

RewriteCond %{REMOTE_HOST} ^host1.* [OR]

RewriteCond %{REMOTE_HOST} ^host2.* [OR]

RewriteCond %{REMOTE_HOST} ^host3.*

RewriteRule ...

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

 

Пример корневого файла .htaccess для сайта:

#пример файла .htacces

AddDefaultCharset UTF-8
Options -Indexes +FollowSymLinks
DirectoryIndex index.php index.html

#Блок если нужно ограничить доступ по IP
# смотри статью "Контроль доступа клиента в Apache "
#Order Deny,Allow
#Deny from all
#Allow from 127.0.0.1 192.168.1 ...

#Блок правил для модуля mod_rewrite
<IfModule mod_rewrite.c>
  RewriteEngine On

  #переопределить корень сайта, станет как "/"
  RewriteBase /

  #Все с HTTP на HTTPS
  RewriteCond %{HTTPS} =off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,QSA,L]
#или как: RewriteRule ^(.*)$ https://%{HTTP_HOST}%/$1 [R=301,QSA,L]

  #Все что не файл, не директория, не картинка и т.п. - то на index.php
  RewriteCond %{REQUEST_URI} !^/(index\.php|images|robots\.txt|public) [NC]
  RewriteCond %{REQUEST_URI} !\.(cssіjsіjpgіgifіpng)$
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule ^(.*)$ /index.php?$1 [L,QSA]
#или как: RewriteRule . /index.php [L] 

#hotlink защита НЕ забывайте про экранирование в РВ
RewriteCond %{HTTP_REFERER} !^$
    RewriteCond %{HTTP_REFERER} !^http://site\.ru/ [NC]
    RewriteCond %{HTTP_REFERER} !^https://site \.ru/ [NC]
    RewriteCond %{HTTP_REFERER} !^http://www\.site\.ru/ [NC]
    RewriteCond %{HTTP_REFERER} !^https://www\.site\.ru/ [NC]
    RewriteRule \.(jpeg|png|bmp|gif|jpg|js|css)$ - [F]
</IfModule>

*Распространенные форматы файлов: jpeg|png|bmp|gif|jpg|js|css|mp4|mp3|webm|m4a|ogg|ogv|swf|webp|avi|mov|mpeg|mpc|mpg|tif|tiff|vtt|flv|gz

 

RewriteRule \.(jpeg|png|bmp|gif|jpg|js|css)$ - [F]—это значит что для URI заканчивающиеся на .расширение из скобок - ничего не изменять (тире после РВ как параметр Подстановка значит НЕ изменять URL), не перезаписывать URL и [F] значит отказать в выдаче файла.

Примеры:

#редирект с www.site.ru на site.ru без www
RewriteCond %{HTTP_HOST} ^www\.(.*) [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,QSA,L]

Выполняется проверка доменного имени, и если домен начинается с www, то работает правило: все, на http://%1/$1. Где %1 это домен без www из условия в RewriteCond, а $1 это URI  из самого RewriteRule правила.

#редирект с site.ru на www.site.ru
RewriteCond %{HTTP_HOST} ^(.*)$ [NC]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ http://www.%1/$1 [R=301,QSA,L]
Простые редиректы
#Простой внешний редирект, можно применять
#без RewriteCond, только с RewriteRule
RewriteRule ^pages/page.* /about.html [R=301,QSA,L]
Внутренний реврайт
#Внутренний реврайт, т.е. просто перезапись URI
RewriteRule ^pages/page.* /about.html [L]
#еще
RewriteRule ^index.php$  /about-us/ [L]
Редирект на основе GET параметров
#Пример редиректа со страницы
#/?do=page&id=15 был редирект на /page/15/
RewriteCond %{QUERY_STRING} do=page [NC]
RewriteCond %{QUERY_STRING} id=(\d+) [NC]
RewriteRule .* /page/%1/? [R=301,L]
Редирект с обычной на мобильную версию сайта
RewriteCond %{HTTP_HOST} ^(.*)$ [NC]
RewriteCond %{HTTP_USER_AGENT} (?i:midp|samsung|nokia|j2me|avant|docomo|novarra|palmos|palmsource|opwv|chtml|pda|mmp|blackberry|mib|symbian|wireless|nokia|hand|mobi|phone|cdm|upb|audio|SIE|SEC|samsung|HTC|mot-|mitsu|sagem|sony|alcatel|lg|eric|vx|NEC|philips|mmm|xx|panasonic|sharp|wap|sch|rover|pocket|benq|java|pt|pg|vox|amoi|bird|compal|kg|voda|sany|kdd|dbt|sendo|sgh|gradi|jb|dddi|moto|iphone|android) [NC]
RewriteRule ^$  http://m.%1 [R=302,L]

Еще примеры правил можно посмотреть в статье Как написать .htaccess файл для сайта

 

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

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

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

Учитывайте, что браузеры могут кешировать редиректы, при этом Ctrl+F5 или Ctrl+R не снимает проблему. Поэтому отключайте кеширование в браузере при тестировании ваших правил rewrite модуля web сервера Apache.

Для поиска ошибок работы ваших правил читайте логи Apache.

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

В этой статье я описал только две директивы и главные на мой взгляд понятия. Однако, как сами понимаете, mod_rewrite предоставляет много других директив и функционала.

Андрей Болдырев

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *