Конфигурационный файл.htaccess. Использование файла.htaccess Временная блокировка индексации

Начнем издалека, чтобы и новичкам был понятен принцип работы описываемого в статье файла. Для функционирования сайта в Интернете нужен не только компьютер и выход к сети, но и установленное на него специальное ПО, которое обеспечивает доступ к данным по протоколам http и https. Таким программным обеспечением и является веб-сервер. Существуют различные типы веб-серверов, но самый распространенный - Apache. Он построен на открытом коде, предоставляется бесплатно, постоянно дорабатывается и улучшается, совместим с многими скриптами и работает почти на всех платформах, включая Windows, Linux, Netware 5.x.

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

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

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

Что такое.htaccess и для чего он нужен

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

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

Имя файла.htaccess - общепринятое, но вовсе не обязательное. В httpd.conf можно задать другое имя с помощью директивы AccessFileName , например, так:

AccessFileName .config

Как создать файл.htaccess

Как уже говорилось, конфигурационные файлы имеют текстовый формат, и создать.htaccess также можно с помощью текстового редактора (например, Блокнота или NotePad++ в Windows).

Имя файла - .htaccess (с точкой в начале);

тип - «Все файлы»;

формат переноса по словам;

режим ASCII (при загрузке.htaccess на хостинг по FTP-протоколу).

Apache - регистрозависимый веб-сервер, поэтому важно написать название маленькими буквами: .HTaccess и.htaccess - это разные файлы.

В Mac ОS файлы, начинающиеся с точки, невидимы. Поэтому вы можете назвать его иначе и после, переместив по FTP на хостинг, переименовать. Обычно размещают файл в корневой директории веб-сервера (/public_html ) либо в корневой директории сайта (/public_html/site.com/ ).

Синтаксис.htaccess

Синтаксис.htaccess аналогичен синтаксису httpd.conf. Для каждой директивы предполагается отдельная строка. Для своего же удобства вы можете вносить в файл комментарии с помощью знака #, и значение после # будет игнорироваться веб-сервером. Этот трюк можно использовать для отключения любой директивы. Ее не нужно удалять полностью из файла – достаточно просто закомментировать.

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

Возможности.htaccess

Контроль доступа

Запрет веб-доступа:

Order Deny,Allow Deny from all

Запрет веб-доступа, кроме IP:

Order deny,allow deny from all allow from xxx.xxx.xxx.xxx

Запрет веб-доступа для IP:

Order allow,deny Allow from all Deny from xxx.xxx.xxx.xxx

Запрет доступа к файлу:

Order allow,deny Deny from all

Защита директории с помощью пароля:

AuthType Basic AuthName "Directory Name" AuthUserFile /home/cpanel_user/.htpasswds/public_html/smth/passwd require valid-user # где "Directory Name" - имя директории,которую нужно защитить, а # /home/cpanel_user/.htpasswds/public_html/smth/passwd - путь к файлу passwd с логинами и паролями разрешенных пользователей. # В файле должны быть записи вида пользователь:пароль

Работа с ошибками веб-сервера

Иногда вместо ожидаемой страницы посетитель может натолкнуться на ответ веб-сервера в виде ошибки с лаконичным, но не всегда понятным для простого пользователя объяснением причины. Полный список кодов состояния можно найти в Википедии . Для самых распространенных (например, 404 или 500 ошибки) желательно создать свою страницу, которая лучше смотрится и представляет посетителю пути выхода. Задается она следующим образом:

ErrorDocument 404 http://yourdomain.com/error/404.html # где http://yourdomain.com/error/404.html - путь к созданной странице.

P.S. Пользователи услуги от сайт могут воспользоваться для создания своей страницы функционалом контрольной панели cPanel (в разделе «Расширенный » пункт «Страницы ошибок »).

Настройка 301 редиректа в htaccess

Для создания постоянного перенаправления используется директива 301 редиректа, которая передает весь вес страницы на новый URL (поэтому оно предпочтительней, чем 302 редирект - в целях SEO).

Перенаправление всего сайта на новый домен:

Redirect 301 / http://www.newdomain.com/

Перенаправление страницы на новую:

Redirect 301 /page1.html http://mydomain.com/page2.html

Модуль перенаправления mod_rewrite

Незаменимым механизмом для изменения URL-ссылок “на лету” является модуль mod_rewrite . Его полезность, а вместе с тем, сложность заключается в том, что можно использовать несметное количество правил, включающих еще больше переменных.

Для работы модуля, прежде всего, нужны директивы:

RewriteEngine On (включает работу механизма преобразования)

Options FollowSymLinks (условие для работы mod_rewrite).

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

RewriteRule

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

Перенаправление страницы на новый домен:

RewriteRule ^page1\.html$ http://newdomain.com/

Перенаправление сайта с домена без www на домен с www:

RewriteEngine On RewriteCond %{HTTP_HOST} !^www\..* RewriteRule ^(.*) http://www.%{HTTP_HOST}/$1

И наоборот:

RewriteCond %{HTTP_HOST} ^www\.(.*)$ RewriteRule ^(.*)$ http://%1/$1

Перенаправление по протоколу HTTPS (предварительно нужно установить ):

RewriteEngine On RewriteCond %{HTTPS} !on RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Эти строки необходимо разместить в самом верху.htaccess.

Определение кодировки

Таблицу символов, в которой следует открыть сайт, определяет браузер. Однако, можно задать кодировку по умолчанию:

AddDefaultCharset UTF-8

Такое изменение распространяется в пределах действия.htaccess и на все страницы сайта. Можно задать кодировку для определенного типа файла, например windows-1251 для html:

AddType "application/x-httpd-php3; charset=windows-1251" .html

Часто сама страница несет в себе (а именно в заголовке) информацию об используемой кодировке. Нужно проверить, чтобы указанная кодировка в документе и в конфигурационном файле совпадали. Приведенная здесь utf-8 практически всегда требуется при работе популярных cms, так как они рассчитаны на большой круг пользователей по всему миру. Кстати, по умолчанию эта же кодировка настроена и на наших серверах виртуального хостинга.

Другие возможности

– Определить индексный файл сайта:

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

DirectoryIndex index.php

– Полезной директивой является FilesMatch, которая оговаривает пределы действия правила по названию файла, используя регулярные выражения. С ее помощью, например, можно запретить доступ к определенным файлам:

Order Allow,Deny Deny from all

Есть некоторые директивы, которые не поддерживаются на наших серверах с виртуальным хостингом, но вы можете их разрешить на своем ВПС.

Причина в том, что работающий как suPHP веб-сервер не поддерживает php_flag и php_value . Поэтому мы предлагаем использовать сPanel (крайне полезен подраздел “Выбор версии РНР ”, для работы с error_log – “Журнал ошибок ”) или создать локальный файл php.ini для этой цели. Пару директив мы все-таки привели ниже:

– Для того, чтобы избежать зависания веб-сервера при обработке некорректно написанных скриптов, существует max_execution_time . С ее помощью указывается время в секундах, отведенное на обработку РНР-скрипта. Можно увеличить время ожидания веб-сервера при выполнении скрипта:

Php_value max_execution_time 60

– Определить максимальный размер загружаемого файла:

Php_value upload_max_filesize 128M (здесь вместо 128 поставьте нужное значение).

– Вывести ошибки РНР в отдельный файл:

Php_flag log_errors on php_value error_log /home/path/to/public_html/domain/PHP_errors.log # PHP_errors.log - название файла, а # /home/path/to/public_html/domain - путь к нему).

P.S. На виртуальном хостинге трудно с точностью определить, какие директивы будут работать в.htaccess, потому что многие из тех, которые ведут к изменению конфигурации веб-сервера, запрещены по понятным причинам - эти изменения затронут всех пользователей на носителе.

Если.htaccess не работает

Проверить работу файла можно, прописав несложные директивы, которые при правильном синтаксисе и верных настройках httpd.conf (как описывалось в начале статьи) должны сработать:

– например, запретив доступ к сайту извне с помощью директивы

Order deny,allow Deny from all

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

Если проблема действительно существует, нужно в первую очередь искать причину в главном конфигурационном файле:

– убедиться, что сервер разрешает использование файла.htaccess: есть запись AllowOverride All (и она не закомментирована с помощью #);

– проверить, что создана запись VirtualHost для домена. В качестве примера:

DocumentRoot /www/example1 ServerName www.example.com # Другие директивы

– название файла дополнительной конфигурации указано как вам нужно. Если это.htaccess, то:

AccessFileName .htaccess

– присутствует хостнейм сервера (указывается при создании URL-перенаправлений) в виде IP-адреса сервера или домена:

ServerName www.example.com

Если же причина не в httpd.conf, нужно проверить сам.htaccess на наличие синтаксических ошибок. Можно воспользоваться онлайн-сервисами (например, http://www.htaccesscheck.com/ , http://htaccess.madewithlove.be/), или - , где есть полный перечень директив вместе с синтаксисом.

Крайне желательно перед любым редактированием делать резервную копию файла – чтобы при худшем исходе можно было «откатить» изменения обратно.

Хотя изменения и сразу вступают в силу, кэш браузера никто не отменял. Для проверки работы сайта после редактирования.htaccess регулярно пользуйтесь его очисткой или загружайте страницу в обход кэша - через комбинацию клавиш Ctrl + F5 (в Safari: Ctrl + R , в Mac OS: Cmd + R ).

Самая распространенная ошибка веб-сервера при работе с.htaccess - 500. Она указывает на проблему в синтаксисе (опечатка в директиве, например), либо же в главном конфигурационном файле не разрешен такой тип директивы.

Полезные ссылки

Лучший источник вдохновения для работы с.htaccess:

Многие инструкции по работе с.htacess, на русском.

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

Файл.htaccess использует такой же формат, как и основной конфигурационный файл для Apache: httpd.conf . Большинство установок можно использовать и в том и в другом файлах.

Установки, заданные в файле.htaccess в каталоге, будут иметь более высокий приоритет перед установками, заданными в httpd.conf , для данного каталога и его подкаталогов.

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

Перенаправления и изменение URL

Популярное использование файла.htaccess - задание перенаправлений или изменений URL. Данный метод помогает в целях SEO изменять имя домена, или перестраивать файловую структуру проекта, или делать длинные трудно запоминаемые адреса URL простыми и понятными.

Перенаправления

Перенаправления могут быть очень простыми, например:

Redirect 301 ^old\.html$ http://localhost/new.html

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

Изменения

Правило изменения также может быть очень простым:

RewriteEngine on RewriteRule ^old\.html$ new.html

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

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

RewriteRule ^old\.html$ http://hostname/new.html

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

Одно возможное использование перенаправлений - изменение адресов URL к более простой форме для посетителей и поисковых роботов. Рассмотрим пример:

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

Данное правило позволяет использовать посетителю адрес URL наподобие products/turntables/technics/sl1210 , который будет трансформироваться в product.php?cat=turntables&brand=technics&prod=sl1210. Круглые скобки между слешами в регулярном выражении примера выполняют объединение в группы - мы можем использовать каждую из них как $1 , $2 и $3 соответственно. Комбинация [^/]+ в скобках соответствует любому символу, кроме слеша, в любых количествах.

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

Пользовательская страница ошибок

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

Правило для изменения странницы 404 очень похоже на правило перенаправления:

ErrorDocument 404 "/404.html"

Если происходит ошибка 404, будет выводиться указанная страница. Также можно сделать страницы для отображения других серверных ошибок.

Ограничения доступа к определённым ресурсам

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

AuthName "Введите имя пользователя и пароль" AuthUserFile /path/to/.htpasswd Require valid-user AuthType Basic

Нужно разместить в каталоге, который требуется защитить от свободного доступа. Директива AuthName определяет сообщение, которое будет выводиться в диалоговом окне для ввода пароля, а в правиле AuthUserFile определяется путь к файлу.htpasswd . Директива Require определяет, что только зарегистрированные пользователи могут получить доступ к файлу.

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

AuthName "Введите имя пользователя и пароль" AuthUserFile /path/to/.htpasswd Require valid-user AuthType Basic

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

Блокируем доступ для определенных посетителей

Еще одним использованием файла.htaccess является быстрое и простое блокирование всех запросов с определенного IP адреса или агентов. Нужно просто добавить в файл.htaccess правила:

Order allow,deny deny from 192.168.0.1 allow from all

Директива order указывает серверу Apache в каком порядке рассматривать директивы allow/ deny . В примере директива allow оценивается первой, а затем следует работа с deny . Правило allow from all рассматривается первым (несмотря на то, что в файле оно определено после правила deny) и все IP адреса разрешаются. Затем, если IP адрес клиента соответствует указанному в директиве deny , то доступ ему блокируется. Можно блокировать доступ диапазону IP адресов, указав, например, 192.168 .

Для блокирования доступа определенным агентам, можно использовать другие правила:

RewriteCond %{HTTP_USER_AGENT} ^OrangeSpider RewriteRule ^(.*)$ http://%{REMOTE_ADDR}/$

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

Указываем для IE режим вывода

Кроме управления ответами сервера на определенные запросы, мы можем влиять на браузеры пользователей, например, указывать IE определенный механизм вывода. Можно использовать модуль mod_headers, если он присутствует для установки заголовка X-UA-Compatible:

Header set X-UA-Compatible "IE=Edge"

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

Header unset X-UA-Compatible

Включаем кеширование

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

Например:

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 просто включает генерацию заголовка устарения ресурса. Данная директива зависит от наличия модуля mod_expires на сервере Apache.

Разрешаем сжатие

Еще одним способом влияния на производительность ресурса является использование сжатия:

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 для сжатия содержания. В примере мы указываем text/html , text/css и text/javascript в качестве типов ресурсов, которые будут сжиматься.

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

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

SetOutputFilter DEFLATE AddOutputFilterByType DEFLATE text/html text/css text/javascript

В примере устанавливается алгоритм компрессии с помощью правила SetOutputFilter и определяются типы файлов содержания для фильтра с помощью правила AddOutputFilterByType .

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

Заключение

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

Решение

• Синтаксис файла htaccess
• Настройка доступа htaccess
• Модификация URL в htaccess
• Настройка редиректов в htaccess
• Настройка страниц ошибок в htaccess
• Кэширование в htaccess
• Сжатие файлов в htaccess
• Закрытие каталогов паролем
• Кодировка
• Версия PHP в нужной папке и изменение обработчика по типу файла

СИНТАКСИС ФАЙЛА HTACCESS

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

Общий синтаксис директив очень прост, это пары команд и их опций, разделенных пробелом, например:

Команда параметр1 параметр2 флаги

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

Зайдите на рабочий стол cPanel и зайдите в раздел "Диспетчер файлов "

Перейдите в папку public_html и создайте фаил с именем ".htaccess "

Создайте нужную папку и фаил.htaccess в папке public_html или выше.

Включите отображение скрытых файлов, в разделе "Настройки " справа, сверху.

И отредактируйте файл.htaccess правой клавишей мыши нажав на файл и выбрав Edit

НАСТРОЙКА ДОСТУПА HTACCESS

Довольно часто htaccess используется для управления доступом к папке. Для управления доступом используются три команды:

• order - порядок;
• deny - запретить;
• allow - разрешить.

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

Затем с помощью директивы allow или deny мы разрешаем или запрещаем доступ к папке с определенных адресов. Например, чтобы запретить все необходимо добавить в htaccess:

Order deny,allow
Deny from all

Но мы также можем разрешить доступ только с нужной подсети или IP адреса:

Order deny,allow
Deny from all
Allow 192.168.0.

Для блокировок IP адресов вы можете использовать возможности cPanel

Если указано deny,allow, то проверка будет выполняться в таком порядке. Сначала все директивы deny, затем все директивы allow, и если ни одно из условий не подошло, то запрос пропускается.При allow,deny такой запрос будет по умолчанию отклонен. Например, предыдущий пример можно написать так:

Order allow,deny
Allow 192.168.0.

МОДИФИКАЦИЯ URL В HTACCESS

Наиболее часто htaccess используется для модификации URL во время выполнения или редиректов. За эту функциональность отвечает модуль mod_rewrite и обычно он активирован в большинстве конфигураций Apache.

Модификация URL в htacces выполняется с помощью трех директив, это RewriteBase , которая указывает префикс адреса, RewriteCond проверяет соответствие, и RewriteRule - изменяет URL в соответствии с регулярным выражением если все правила соответствия подходят.

Сначала нужно включить Mod_Rewrite, на случай если модуль еще не активен:

RewriteEngine on

Укажем, что в качестве префикса для URL нужно использовать корень:

И будем автоматически заменять URL адреса с index.html на index.php, обратите внимание, что исходный URL - это путь к запрашиваемому файлу относительно расположения файла htaccess:

RewriteRule index.html /index.php

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

• ^ - начало строки;
• $ - конец строки;
• . - любой символ;
• * - любое количество любых символов;
• ? - один определенный символ;
• - последовательность символов, например, от 0 до 9;
• | - символ или, выбирается или одна группа, или другая;
• () - иcпользуется для выбора групп символов.

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

• %{HTTP_USER_AGENT} - поле User-Agent, которое передает браузер пользователя;
• %{REMOTE_ADDR} - IP адрес пользователя;
• %{REQUEST_URI} - запрашиваемый URI;
• %{QUERY_STRING} - параметры запроса после знака?.

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

RewriteEngine On;
RewriteBase /;

Директива RewriteCond дает еще больше гибкости, вы можете выбрать к каким адресам стоит применять модификацию, например, будем переопределять данные только для версии с www:

RewriteBase /;
RewriteCond % {REMOTE_HOST} ^www.site.ru$
RewriteRule ^(.*)\.html$ $1.php

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

НАСТРОЙКА РЕДИРЕКТОВ В HTACCESS

Более подробно про редирект для SSL с http на https .

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

Самый простой редирект можно выполнить без mod_rewrite, с помощью такой строки:

Redirect 301 /index.html http://www.site.ru/index.php

Но обычно нужны перенаправления с более широким действием. Все выглядит очень похоже, только теперь мы используем флаг чтобы не учитывать регистр, [L] для прекращения обработки и [R] - для редиректа. Например, перенаправление htaccess с версии без www на домен с www:

RewriteCond %{HTTP_HOST} ^site\.ru$
RewriteRule ^(.*)$ http://www.site.ru/$1

Значение R=301 означает код редиректа, который будет возвращен клиенту, можно использовать 301, 302 и т д. Редирект htaccess с домена www на домен без префикса будет выглядеть так:

RewriteCond %{HTTP_HOST} ^www.site\.ru$
RewriteRule ^(.*)$ http://site.ru/$1

Таким же образом можно сделать переадресацию:

RewriteRule ^старый_адрес /новый_адрес/$1

Редирект с http версии на https:

RewriteCond %{SERVER_PORT} ^80$
RewriteCond %{HTTP} =on
RewriteRule ^(.*)$ https://site.ru/$1

RewriteEngine On RewriteCond %{SERVER_PORT} !^443$ RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI}

НАСТРОЙКА СТРАНИЦ ОШИБОК В HTACCESS

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

Настройка htaccess для этого пункта будет очень полезной. Вы можете использовать директиву ErrorDocument. С помощью нее можно задать html страницы для ошибок 4хх и 5хх. Например, для 404:

ErrorDocument 404 http://site.ru/error/404.shtml
ErrorDocument 403 http://site.ru/error/403.shtml
ErrorDocument 401 http://site.ru/error/401.shtml
ErrorDocument 500 http://site.ru/error/500.shtml

Если страницы ошибок не срабатывают, смотрите .

КЭШИРОВАНИЕ В HTACCESS

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

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

Сначала активируем модуль и устанавливаем период кэширования по умолчанию:

ExpiresActive On
ExpiresDefault "access plus 1 month"

Теперь мы можем настроить кэширование для каждого mime типа файлов:

ExpiresByType text/html "access plus 1 month 15 days 2 hours"
ExpiresByType image/gif "access plus 5 hours 3 minutes"
ExpiresByType image/x-icon "access plus 2592000 seconds"

В первой строке мы указываем, что страницы html нужно считать годными на один месяц 15 дней и два часа с момента загрузки. Доступны такие типы файлов:

• image/x-icon;
• image/jpeg;
• image/png;
• image/gif;
• application/x-shockwave-flash;
• text/css;
• text/javascript;
• application/javascript;
• application/x-javascript;
• text/html;
• application/xhtml+xml;

Чтобы быть уверенным что эта конструкция не вызовет ошибок заключите ее в if:

СЖАТИЕ ФАЙЛОВ В HTACCESS

Для сжатия в Apache можно использовать модуль deflate. Так же вы можете использовать возможности Cpanel, .

Здесь достаточно просто перечислить mime типы файлов, которые нужно сжать. Например:

AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/css text/javascript application/javascript application/x-javascript

Вы также можете заключить конструкцию if, чтобы проверить поддерживается ли этот модуль:

Закрытие каталогов паролем

Используйте раздел cPanel

Мы используем Apache httpd в качестве основного веб-сервера. Apache используется для организации большинства веб-серверов в мире и является самым массовым продуктом своего класса. Этот сервер обладает обширными возможностями конфигурации, является очень производительным и поддерживает все известные протоколы для работы веб-серверов. Специально для Apache созданы версии таких популярных языков программирования как Perl и PHP, а также этот сервер легко интегрируется с широко применяемыми СУБД (например, MySQL).

Главный сайт проекта находится по адресу httpd.apache.org , а основная документация по версии 1.3.хх доступна на странице httpd.apache.org/docs/ .

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

Индексный файл

Индексный файл или файл-индекс — это тот файл, который открывается по умолчанию при обращении пользователя через веб к каталогу, а не к конкретному файлу. Например, ваш посетитель запросит адрес http://ваш_домен/price/ , где price — название каталога. Индексный файл это тот файл, который будет показан пользователю при обращении к каталогу без указании имени конкретного файла в нем.

По умолчанию индексными файлами являются следующие: index.html, index.htm, index.php, index.php3, index.phtml, index.shtml, default.htm или default.html. Если вы хотите чтобы первым открывался какой-то иной файл, нужно переопределить текущие значения. Как это сделать читайте .

Назначение и использование файла .htaccess

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

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

В .htaccess может быть помещено большинство из доступных директив для веб-сервера. Следует заметить, что директивы, в описании которых в поле Context отсутствует упоминание .htaccess недоступны для использования в этом файле конфигурации. На примере директивы AddType видим, что поле Context содержит упоминание о .htaccess , соответственно вы можете ее использовать:

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

Web Application Firewall

Web Application Firewall (ModSecurity) необходим для обнаружения и предотвращения атак на веб-сайты. Проверка осуществляется определенным набором правил и, если она не пройдена, запрос к сайту отклоняется с ошибкой (403 forbidden).

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

• SecRuleRemoveById - удалить правило по id
• SecRuleRemoveByTag - удалить правило по тегу.

Определить, какое именно правило необходимо отключить, можно в журнале ошибок error.log

Пример отключения по ID :

SecRuleRemoveById 933100 933150

Примеры отключения по Tag :

SecRuleRemoveByTag "attack-injection-php" SecRuleRemoveByTag "CWAF"

Переопределение кодировки:

По умолчанию веб-сервер «отдает» все html-документы, которые размещены на сервере в кодировке windows-1251. Изменить тип кодировки, в которой веб-сервер будет «отдавать» информацию, можно в личном кабинете .

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

Изменить кодировку можно также с помощью файла .htaccess . Для этого добавьте в него строку

AddType "text/html; charset=koi8-r" .html .htm .shtml

Получив такой .htaccess , веб-сервер Apache станет выдавать клиентскому браузеру заголовок, в котором будет указано, что документ имеет кодировку koi8-r.

Если на вашем ресурсе существуют html-документы в разных кодировках, (ISO-8859-1, Windows-1250, Windows-1252, UTF-8), то вам, возможно, будет необходимо отключить принудительную выдачу заголовка с кодировкой windows-1251. Для этого в .htaccess добавляется строка:

AddDefaultCharset Off

При этом соответствующая кодировка должна быть прописана на каждой html-странице в виде тега

Пример: как закрыть директорию паролем

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

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

AuthType Basic AuthName "Some Name" AuthUserFile /home/uXXXXX /.htpasswd require valid-user

Путь /home/uXXXXX/.htpasswd обозначает полный путь к файлу паролей на диске нашего сервера. Если, например, вы поместите файл .htpasswd (в нем будут пароли) в домашний каталог, куда вы попадаете зайдя на сервер по FTP, то путь к этому файлу будет иметь вид /home/uXXXXX/.htpasswd , где uXXXXX — наименование вашей виртуальной площадки (например, u12345).

В директиве AuthUserFile указываем абсолютный путь к файлу с логинами/паролями, который мы создадим чуть позже. Если вы создаете файл .htaccess на своем компьютере, а не сразу на сервере при помощи текстового редактора, обратите внимание на то, что .htaccess должен передаваться по FTP строго в текстовом (ASCII) режиме .

Создаем файл паролей. Файл с паролями должен содержать строки вида login:password . Пароль должен быть зашифрован с использованием алгоритма MD5. Один из способов создать такой файл — воспользоваться программой, входящей в поставку Apache — htpasswd (на нашем сервере она находится в каталоге /usr/local/bin/ , полный путь — /usr/local/bin/htpasswd ).

Рассмотрим как создать файл паролей в unix shell прямо на сервере. Зайдем в shell, и будем выполнять следующие команды:

• htpasswd -mbc .htpasswd user1 sNQ7j9oR2w создаем новый файл .htpasswd, в который добавляем запись для пользователя user1 с паролем, указанным в командной строке. Просьба обязательно заменить sNQ7j9oR2w на любой собственный пароль — здесь этот пароль указан только для примера
• htpasswd .htpasswd user2 добавляем в уже существующий файл .htpasswd пользователя user2, а пароль вводим вручную в ответ на соответствующий запрос программы

Если вы используете Windows и не хотите пользоваться unix shell для генерации паролей, можно загрузить Windows-версию программы htpasswd и создать файл с паролями на своем компьютере, после чего загрузить его на сервер. Если у вас уже установлена Windows-версия Apache, файл htpasswd.exe можно найти в каталоге Program Files\Apache Group\Apache\bin\ .

Итак, получите htpasswd.exe и используйте его для генерации паролей таким образом:

• htpasswd.exe -mc .htpasswd user1 создаем новый файл паролей htpasswd.exe , пароль и его подтверждение будут запрошены интерактивно
• htpasswd.exe -m .htpasswd user2 добавляем пользователя user2 в существующий файл паролей htpasswd.exe , запросив пароль интерактивно

После окончания заведения всех логинов файл нужно загрузить на сервер.

Пример: переопределение индексного файла

Ситуация: пользователь обратился к каталогу http://www.ваш_домен.ru/price/. При таком запросе первым откроется и будет показан . Если вы хотите переопределить индексный файл и сделать так, чтобы первым открывался не index.htm, а, например, файл myindex.php , то сделать это можно поместив в файл.htaccess в соответствующем каталоге следующую инструкцию:

DirectoryIndex myindex.php

Получив .htaccess с таким содержимым, веб-сервер Apache откроет по умолчанию именно файл myindex.php.

Пример: запрет и разрешение выдачи листинга

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

Options +Indexes

Файл .htaccess необходимо создавать именно в том каталоге, в котором планируется разрешить листинг. Данная директива будет действовать также и на все подкаталоги (это достигается включенной по умолчанию в настройках виртуального хоста директивой AllowOverride All ).

По умолчанию включена директива Options -Indexes , и в случае вы получите HTTP ошибку 403.

Если кодировка в именах файлов отображается не корректно, воспользуйтесь свойством Charset, чтобы указать нужную кодировку. Например для отображения кириллических символов в кодировке UTF-8 добавьте в файл.htaccess следующую инструкцию:

IndexOptions Charset=UTF-8

Пример: собственные страницы ошибок

Пример: запрет доступа с некоторых IP-адресов

Иногда возникает необходимость запретить доступ к сайту или его части с некоторых IP-адресов.

В таком случае необходимо создать в нужной директории файл .htaccess с директивами. Например, чтобы запретить доступ с IP-адреса 172.16.16.16:

Order Allow,Deny Allow from All Deny from 172.16.16.16

Теперь при попытке обратиться к сайту с IP-адреса 172.16.16.16 посетитель получит ошибку 403 или вашу страницу для этой ошибки .

Указание части адреса в виде 172.16.16 ограничит доступ из подсети 172.16.16/24.

Иногда требуется выполнить обратное действие и заблокировать доступ к сайту для всех IP кроме вашего (). Например, чтобы открыть доступ только для IP-адреса 172.16.16.16, добавьте следующую инструкцию в файл.htaccess:

Order Allow,Deny Allow from 172.16.16.16

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

Пример: запрет доступа к некоторым файлам

Иногда возникает необходимость запретить доступ к определенным файлам. Например, к конфигурационным файлам, содержащим реквизиты доступа к базам данных, интерфейсам и т.п. Допустим, в файле config.cfg вы храните логин/пароль доступа к базе данных. Создаем в этой директории файл .htaccess с директивами:

Order allow,deny Deny from all

Теперь, если посетитель наберет в браузере нечто вида http://www.ваш_домен.ru//config.cfg , он получит ошибку 403 или вашу страницу для этой ошибки.

Пример: заголовок last-modified

В ряде случаев требуется, чтобы web-сервер выдавал HTTP-заголовок Last-Modified . К примеру, при регистрации вашего ресурса на Яндексе , возникает ошибка «Неправильные даты ». Для статических документов cервер будет выдавать значение last-modified всегда. Это действительно для html-файлов. Для SSI cервер будет выдавать значение last-modified в том случае, если прописана директива «XBitHack full» (просто пропишите эту строку в .htaccess ), и для файла, к которому происходит обращение, выставлен атрибут «исполняемый» для группы. В скриптах last-modified выдается иными средствами. Например, если учесть то, что php-скрипт генерирует код динамически, то самым логичным будет в качестве last-modified отдавать текущую дату и время./>

Реализуется это следующим образом:

Внимание: команда header должна выполняться в php-скрипте до того, как скрипт начнет выдавать html-текст в браузер пользователя.