Что такое .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

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

<Files private.html >
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 — путь к созданной странице.

Настройка 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/ [R=301]

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

RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\..* [NC]
RewriteRule ^(.*) http://www.%{HTTP_HOST}/$1 [R=301]

И наоборот:

RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]

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

RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Эти строки необходимо разместить в самом верху .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, которая оговаривает пределы действия правила по названию файла, используя регулярные выражения. С ее помощью, например, можно запретить доступ к определенным файлам:

<FilesMatch
"\.(htaccess|htpasswd|ini|phps|fla|psd|log|sh)$">
Order Allow,Deny
Deny from all
</FilesMatch>

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

Причина в том, что работающий как 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 для домена. В качестве примера:

<VirtualHost *:80>
DocumentRoot /www/example1
ServerName www.example.com
# Другие директивы
</VirtualHost>

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

AccessFileName .htaccess

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

ServerName www.example.com

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

И еще несколько советов по работе с .htaccess

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

Рекомендуем вносить изменения пошагово, используя минимум директив – и в случае неудачи будет легче вычислить, какое именно правило вызвало ошибку.

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

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

Создание сайта