Файл .htaccess

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

Синтаксис .htaccess
Вот обязательной синтаксис, несоблюдение которого приводит к ошибкам сервера:
- пути к файлам (директориям) указываются от корня сервера. Пример: /opt/home/www.astanafoto.com/htdocs/config/.htpasswords
- домены с указанием протокола
Пример: Redirect / http://www.site.ru
Файл имеет название именно "точка" htaccess
Должен быть записан в UNIX-формате. Для оболочки FAR, достигается F4 (редактирование файла), Shift+F2 (выбрать "сохранить как UNIX-текст").

400 Bad File Request / Неправильный запрос файла - bad_request.html
401 Unauthorized / Несанкционированный - unauthorized.html
403 Forbidden/Access denied (Доступ запрещен) - forbidden.html
404 Not Found / Не найден - not_found.html
500 Internal Server Error / Внутренняя ошибка сервера - internal_server_error.html

Ошибки и причины их возникновения
Ошибками в протоколе HTTP называется такое поведение веб-сервера, когда он по какой-то причине не может успешно отправить клиенту запрашиваемый документ. Сервер сообщает клиенту в HTTP-заголовке код ошибки, который на стороне клиента так или иначе интерпретируется браузером.
Каждая ошибка, выдаваемая веб-сервером, имеет код соответствующий классу возникшей ошибки. Коды ошибок (например 403 или 404) стандартизованы и подробно описаны в интернет-стандарте RFC2616 (Hypertext Transfer Protocol -- HTTP/1.1). Вы можете обращаться к этому документу за подробным описанием конкретной ошибки как в первоисточнику.
Коды ошибок бывают положительными и отрицательными или успешными и неуспешными. Есть четыре типа кодов:
2xx - запрос выполнен успешно - сервер успешно отправил клиенту запрашиваемый документ
3xx - запрос успешно перенаправлен - тоже положительный код. Он говорит о том, что запрос клиента был перенаправлен. Используется при работе с кэширующими серверами, а также в алгоритме, когда браузер клиента проверяет актуальность документа на сервере (дату создания, размер и так далее)
4xx - ошибка - документ не был отправлен клиенту, так как произошла критическая ошибка. Например, запрошенный документ не найден на сервере, доступ к документу запрещен и так далее
5xx - ошибка сервера - критическая ошибка на сервере. Например, на сервере не смог нормально отработать скрипт пользователя

ошибка 403 "Доступ запрещен" - как устранить причины
Данная ошибка возникает когда сервер не смог обработать запрос по причине того, что доступ к файлу был запрещен. Наиболее часто это возникает в трех случаях:
в каталоге нет индексного файла (index.html, например) и при этом запрещен просмотр списка файлов в данном каталоге* или на всем виртуальном сервере. Можно попробовать создать файл с именем index.html и посмотреть не исчезнет ли ошибка.
выставлены такие "права" доступа на файл, что веб-сервер Apache не смог прочитать файл на диске сервера. Попробуйте изменить права доступа на 640, например.
пользователь попытался обратиться к скрипту (в каталоге cgi-bin), на который выставлены неправильные права - нет права на чтение+исполнение (r+x) конкретного скрипта. Измените права на 755.
*) По умолчанию просмотр списка файлов в каталоге запрещен. Для того, чтобы разрешить вывод списка файлов необходимо создать файл .htaccess, в котором прописать директиву Options +Indexes в виде отдельной строки.

обработка ошибки 404 "Файл не найден"
Ошибка 404 (Файл не найден) возникает когда пользователь запрашивает у веб-сервера документ, которого нет на диске. То есть, когда пользователь запрашивает несуществующий файл. Это наиболее "популярная" из всех ошибок. Вы можете наблюдать возникновение таких ошибок в файле error_log и учитывать это - отслеживать какие документы на сервере "не найдены" и корректировать неправильные ссылки из своих html-документов. Также ссылки на несуществующие документы могут вести с других сайтов.
Для удобства посетителей сайта можно обрабатывать ошибки 404 заменяя стандартные ответы веб-сервера на свои страницы с "человеческим" описанием причины возникновения ошибки и советами что делать в этом случае. Также полезно разместить на такой странице карту вашего сайта или ссылку на поисковую систему.
Как обрабатывать ошибку 404. Создайте в каталоге public_html файл .htaccess и поместите в него следующую инструкцию для веб-сервера Apache:
ErrorDocument 404 /404.html
Затем создайте файл 404.html, в который поместите описание возникшей ошибки и советы о том что "что делать" в этом случае посетителю вашего сайта. Теперь пользователь, который наберет в своем браузере адрес несуществующей страницы, будет автоматически перенаправлен сервером на файл 404.html.
С помощью директивы ErrorDocument можно обрабатывать не только ошибку 404, но и практически все другие ошибки. Например, можно обработать так и ошибку 403, которая упоминается в этом документе выше.

ошибка 500 "Internal Server Error"
Ошибка 500 "Internal Server Error" возникает в случае невозможности запуска скрипта, который вы разместили на сервере, в случае ошибок в скрипте, а также в случае когда вы поместили неправильную инструкцию в файл .htaccess. Этот список причин возникновения ошибки 500 не конечный, есть еще масса причин, по которым может возникнуть ошибка 500. Однако, упомянутые три случая встречаются наиболее часто.
Веб-сервер укажет вам какую конкретно директиву он посчитал ошибочной - ее нужно будет исправить. В данном случае веб-сервер сообщил что директивы DrectoryIndex он не знает. И действительно - нет директивы DrectoryIndex, есть DirectoryIndex. Имеет место опечатка.
Если ошибка 500 возникает при обращении к скрипту на языке Perl, размещенному в каталоге cgi-bin, нужно проверить права доступа на этот скрипт. Права должны быть 755 (rwxrx-rx). Если это не так, нужно изменить права на 755 командой chmod 755 script.pl в unix shell или воспользоваться для этого FTP. Нужно отдельно отметить - права на скрипты должны быть установлены строго в 755.
Пожалуйста, проверьте правильный ли режим передачи файлов по FTP вы использовали при загрузке скрипта на наш сервер. Все скрипты, равно как и любые другие текстовые файлы, должны передаваться по FTP в текстовом (ASCII) режиме. Если же был использован двоичный (Binary) режим передачи файлов, скрипты наверняка работать не будут.
Если после проверки корректности установленных прав на файл скрипта ошибка не исчезла, нужно изучить последние записи в файле error.log - в него веб-сервер помещает все сообщения об ошибках. Так вы найдете строчку вида
[Fri Apr 9 15:05:31 2004] [error] [client 217.16.16.16] Premature end of script headers: /home/uXXXX/aaa.ru/cgi-bin/script.pl
Первое, что нужно сделать если вы получили такую ошибку, это проверить правильно ли скрипт выдает HTTP-заголовки. Каждый скрипт должен сначала печатать строку с указанием соответствующего Content-type и только потом непосредственно то, что увидит пользователь (например, HTML-код). Пример строки для выдачи заголовка обычного HTML-документа:
print "Content-type: text/html; charset=windows-1251\n\n";
Если и после выдачи правильных заголовков ошибка 500 не исчезла, нужно проверить корректность работы скрипта в целом. Для этого нужно получить доступ в unix shell и далее выполнить команду проверки синтаксиса:
> perl -cw script.pl script.pl syntax OK
Если скрипт написан с ошибками, нужно будет исправить ошибки, руководствуясь соответствующей диагностикой, а также проверить синтаксис скрипта снова.
---------------------------------------------

в случае ошибки "SERVER ERROR" показывается страница с другого ресурса: ErrorDocument 500 http://htaccess.net.ru/cgi-bin/500.pl

в случае ошибки "NOT FOUND" показывается страница с того же веб-сайта:
ErrorDocument 404 /cgi-bin/error404.pl

в случае ошибки "FORBIDDEN" показывается текстовое сообщение, которое
обязательно должно начинаться с кавычки, кавычка в сообщении не выводится:
ErrorDocument 403 "веб-сервер не смог прочитать файл на диске сервера
---------------------------------------------------

Глобальное перенаправление (редирект) на другой адрес:
Redirect / http://www.newsite.ru

Перенаправление (редирект) только при запросе определенных страниц:
redirect /company http://www.newsite.com/newcompany
redirect /forum http://www.newsite.com/newforum

Перенаправление (редирект) только посетителей с определенным IP-адресом:
SetEnvIf REMOTE_ADDR 192.145.121.1 REDIR="redir"
RewriteCond %{REDIR} redir
RewriteRule ^/$ /only_for_you.html

Варианты реализации Редиректа с помощью файла .htaccess
Простой редирект:
Redirect 301 / http://www.domainname.ru/
или
redirect /secret http://www.site.ru/nosecret

Редирект на любую страницу по ip пользователя или при запросе конкретной страницы (а также по маске имени).
Если у пользователя ip 192.152.37.125, то он будет перенаправлен на страницу user.php:
SetEnvIf REMOTE_ADDR 192.152.37.125 REDIR="redir"
RewriteCond %{REDIR} redir
RewriteRule ^/$ /user.php

Редирект при запросе определённых файлов. Если запрашиваются файлы, расширение которых не указано в файле .htaccess (gif и jpg), то следует перенаправление:
RewriteEngine On
RewriteRule !.(gif|jpg)$ index.php

Редирект всех файлов в папке на один файл.
Например вы больше не нуждаетесь в разделе сайта Super discount и хотите перенаправить все запросы к папке /superdiscount на один файл /hot-offers.php. Для этого добавляем в .htaccess следующий код.
RewriteRule ^superdiscount(.*)$ /hot-offers.php [L,R=301]

Редирект всей папки кроме одного файла
В следующем примере все файлы из папки /superdiscount будут редиректится на на файл /hot-offers.php, КРОМЕ файла /superdiscount/my-ebook.html котоый должен редиректится на /hot-to-make-million.html
RewriteRule ^superdiscount/my-ebook.html /hot-to-make-million.html [L,R=301]
RewriteRule ^superdiscount(.*)$ /hot-offers.php [L,R=301]

Редирект динамического URL на новый файл.
Данный вариант пригодится если вы хотите редиректить динамический URL с параметрами на новый статический файл.
(То есть теперь, запрос к файлу вида http://www.kass.ws/article.jsp?id=8632 и/или http://www.kass.ws/article.jsp?id=1245 будет отправлен на файл http://www.kass.ws/latestnews.htm.)
RewriteRule ^article.jsp?id=(.*)$ /latestnews.htm [L,R=301]

Массовый редирект новых файлов.
Тепепь перейдем к самому сложному моменту, когда вам надо редиректить массу URL-ов, например после смены вашей CMS. Тут сразу возникает ряд проблем. Во-первых, внесение всех изменившихся адресов в .htaccess файл займет очень много времени, да и само по себе занятие малоприятное. Во-вторых, слишком много записей в .htaccess файле будут тормозить Apache сервера. И в третьих, при внесении такого количества информации высока вероятность, что вы где то ошибетесь. По этому, самый лучший выход, это нанять програмиста который вам напишет динамический редирект.
Нижеприведенный пример написан на PHP, но так же может быть выполнен на любом языке. Предположим вы перешли на новую систему ссылок на вашем сайте и все файлы оканчивающиеся на старый id должны быть средирекчены. Сначала создаем в базе таблицу, которая содержит старый id и новый URL для редиректа. old_id INT new_url VARCHAR (255) Далее пишем код который свяжет ваши старые id с новыми URL-ами
После этого, добавляем следующую строчку в .htaccess:
RewriteRule ^/product-(.*)_([0-9]+).php /redirectold.php?productid=$2
затем создаем PHP файл redirectold.php, который будет поддерживать 301 редирект:

<?php
function getRedirectUrl($productid) {
// Connect to the database
$dServer = "localhost";
$dDb = "mydbname";
$dUser = "mydb_user";
$dPass = "password"; $s = @mysql_connect($dServer, $dUser, $dPass)
or die("Couldn't connect to database server");
@mysql_select_db($dDb, $s)
or die("Couldn't connect to database");
$query = "SELECT new_url FROM redirects WHERE old_id = ". $productid;
mysql_query($query);
$result = mysql_query($query);
$hasRecords = mysql_num_rows($result) == 0 ? false : true;
if (!$hasRecords) {
$ret = 'http://www.yoursite.com/';
} else {
while($row = mysql_fetch_array($result))
{
$ret = 'http://www.yoursite.com/'. $row["new_url"];
}
}
mysql_close($s);
return $ret;
}
$productid = $_GET["productid"];
$url = getRedirectUrl($productid);
header("HTTP/1.1 301 Moved Permanently");
header("Location: $url");
exit();
?>

Теперь все запросы к вашим старым URL-ам будут вызывать redirectold.php, который найдет новый URL и вернет 301 ответ с вашей новой ссылкой.
Редиректы в зависимости от времени
Когда нужно применять уловки типа содержания зависящего от времени масса вебмастеров все ещё используют CGI скрипты которые производят редиректы на специальные страницы. Как это может быть сделано через mod_rewrite?
Есть много переменных названных TIME_xxx для условий редиректа. В связке со специальными лексикографическими образцами для сравнения <STRING, >STRING и =STRING мы можем производить редиректы зависящие от времени:
(Это выдает содержимое foo.day.html при запросе URL foo.html с 07:00 до 19:00 а в оставшееся время содержимое foo.night.html.)
RewriteEngine on
RewriteCond %{TIME_HOUR}%{TIME_MIN} >0700
RewriteCond %{TIME_HOUR}%{TIME_MIN} <1900
RewriteRule ^foo\.html$ foo.day.html
RewriteRule ^foo\.html$ foo.night.html

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

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

Обработка ошибок Apache
/////
401 ошибка — Требуется авторизация (Authorization Required).
403 ошибка — пользователь не прошел аутентификацию, доступ запрещен (Forbided).
404 ошибка — Документ не найден (Not Found).
500 ошибка — Внутренняя ошибка сервера (Internal Server Error).
/////
ErrorDocument 401 /401.html
ErrorDocument 403 /403.html
ErrorDocument 404 /404.html
ErrorDocument 500 /500.html

Запрет на отображение содержимого каталога при отсутствии индексного файла
Options –Indexes

Определение кодировки, в которой сервер "отдает" файлы
AddDefaultCharset windows-1251

Определение кодировки на загружаемые файлы
CharsetSourceEnc windows-1251

Запрет доступа ко всем файлам
deny from all
////////////////////
Запрещен доступ ко всем файлам и каталогам в текущей директории.
///////////////////

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

Запретить доступ с определенного IP-адреса
deny from 195.135.232.70

Запретить доступ к определенному файлу
<Files config.php>
deny from all
</Files>
////////////////////
Запрещен доступ посетителей к файлам config.php. Этот запрет не действует на скрипты web-сервера. Они по прежнему будут иметь доступ к этому файлу.
///////////////////

Запретить доступ к файлам с определенным расширением
<Files "*.conf">
deny from all
</Files>
///////////////////
? - любой одиночный символ
* - любая последовательность символов, исключая символ / (слеш)
//////////////////

Запретить доступа к файлам с несколькими типа расширений
<Files ~ "\.(inc|conf|cfg)$">
deny from all
</Files>
/////////////////////
Запрещен доступ к файлам с расширением *.inc, *.conf и *.cfg. Хотя директива , по умолчанию, не работает с регулярными выражениями, но их можно включить поставив символ тильды(~) в опциях директивы. Синтаксис следующий:
[тильда] [пробел] [далее_все_без_пробелов]
////////////////////

Установка пароля на директорию
AuthName "Admin page"
AuthType Basic
AuthUserFile /pub/home/server/.pass
require valid-user
</Files>
////////////////////
Как сделать-см. http://www.softtime.ru/article/index.php?id_article=27
/////////////////////

Пароль только на 1 файл:
Аналогично паролированию директории полностью, можно ставить пароль только на 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>

Показ разных страниц, в зависимости от 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

Как заставить Апач обрабатывать 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

Как заставить Апач выполнять в html документах файл с расширением .vera?
AddType "text/html" .vera

Вставка кода php в html-файлы
AddHandler application/x-httpd-php .php .htm .html .phtml

Запрет скачивания картинок и (или) архивов с чужих сайтов
Для каталога
RewriteEngine on
RewriteBase /img/
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://www\.your-sites\.ru.* [NC]
RewriteRule .* - [F]

для определенных типов файлов
RewriteEngine on
RewriteBase /
RewriteCond %{HTTP_REFERER} !^http://www\.your-sites\.ru.* [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule \.(jpe?g|gif|png|css|swf)$ - [F]

Создание удобо читаемых URL
Чтобы преобразовать, например, www.site.ru/product.php?id=123 в www.site.ru/product/123 следующим образом:
RewriteEngine on
RewriteRule ^product/([^/\.]+)/?$ product.php?id=$1 [L]

В следующем примере преобразуем www.site.ru/script.php?product=123 в www.site.ru/cat/product/123/:
RewriteRule cat/(.*)/(.*)/$ /script.php?$1=$2

Убираем у всех запросов вначале "WWW."
RewriteEngine on # оглашаем, что хотим использовать mod_rewrite
RewriteCond %{HTTP_HOST} ^www\.(.*) [NC]
RewriteRule ^/?(.*) http://%1/$1 [L,R=permanent]

Меняем расширение .html на .php
Иногда бывает так, что у Вас статичный веб-сайт, а Вам необходимо, чтобы на нем срабатывал какой-нибудь php-скрипт. Для этого Вам необходимо сказать серверу, чтобы он обрабатывал эту страницу как php-файл.
AddHandler application/x-httpd-php .html
или для других расширений
AddHandler application/x-httpd-php .xml
AddHandler application/x-httpd-php .asp
AddHandler application/x-httpd-php .vera

Защита изображений от скачивания
(Очень часто бывает, что веб-мастера нагло копируют контент с Вашего сайта вместе с рисунками, причем рисунки подгружаются с Вашего же сервера. Это создает лишний трафик, что, зачастую, приводит к ряду проблем. Как же защититься от таких веб-мастеров и не помешать поисковым роботам индексировать изображения? Все просто:)
RewriteEngine on
RewriteCond %{HTTP_REFERER} .
RewriteCond %{HTTP_REFERER} !^http://([^.]+\.)?site\. [NC]
RewriteCond %{HTTP_REFERER} !google\. [NC]
RewriteCond %{HTTP_REFERER} !search\?q=cache [NC]
RewriteCond %{HTTP_REFERER} !msn\. [NC]
RewriteCond %{HTTP_REFERER} !yahoo\. [NC]
RewriteCond %{REQUEST_URI} !^/hotlinker\.gif$
RewriteRule \.(gif|jpg|png)$ /hotlinker.gif [NC,L]

hotlinker.gif - изображение, которое будет отображаться, вместо истинных изображений. Рекомендую в этом изображении отобразить Ваш логотип и ссылку на Ваш сайт.

Еще один варинат запрета доступа к картинкам с неразрешенных сайтов:
SetEnvIfNoCase Referer "^$" local_ref=1
SetEnvIfNoCase Referer "^http://(www\.)?htmlweb\.ru" local_ref=1
SetEnvIfNoCase Referer "^http://(www\.)?images\.yandex\.ru" local_ref=1
SetEnvIfNoCase Referer "^http://(www\.)?hghltd\.yandex\.com" local_ref=1
<FilesMatch ".(jpg|gif|png)">
Order Allow,Deny
Allow from env=local_ref
</FilesMatch>

Поисковые машини и разного рода сканеры создают коллосальный трафик на вашем сайте. Нижеприведенный блок кода позволит запретить доступ ботам на сайт.
RewriteCond %{HTTP_USER_AGENT} (Googlebot|Slurp|spider|Twiceler|heritrix|
Combine|appie|boitho|e-SocietyRobot|Exabot|Nutch|OmniExplorer|
MJ12bot|ZyBorg/1|Ask\ Jeeves|AskJeeves|ActiveTouristBot|
JemmaTheTourist| agadine3|BecomeBot|Clustered-Search-Bot|
MSIECrawler|freefind|galaxy|genieknows|INGRID|grub-client|
MojeekBot|NaverBot|NetNose-Crawler|OnetSzukaj|PrassoSunner|
Asterias\ Crawler|T-H-U-N-D-E-R-S-T-O-N-E|GeorgeTheTouristBot|
VoilaBot|Vagabondo|fantomBro wser|stealthBrowser|cloakBrowser|
fantomCrew\ Browser|Girafabot|Indy\ Library|Intelliseek|Zealbot|
Windows\ 95|^Mozilla/4\.05\ \[en\]$|^Mozilla/4\.0$) [NC]
RewriteRule ^(.*)$ - [F]
#
RewriteCond %{HTTP_USER_AGENT} ^Mozilla.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Opera.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Firefox.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Netscape.* [NC]
RewriteRule ^(.*)$ - [L]
RewriteRule ^(.*)$ - [F]

Отслеживание обращений к файлу robots.txt
Чтобы иметь больше информации о посещении поисковиков, полезно иметь подробную информацио об обращении к файлу robots.txt Для того, чтобы оганизовать это, в '.htaccess' должны быть следующие записи:
(Теперь при запросе файла 'robots.txt' наш RewriteRule переадресует посетителя (робота) к обрабатывающему запросы скрипту robot.php. Кроме того, переменная передается скрипту, которая будет обработана в соответствии с вашими нуждами. 'REQUEST_URI' определяет имя запрашиваемого файла. В данном примере это - 'robots.txt'. Скрипт прочтет содержание 'robots.txt' и отправит его web-браузеру или роботу поискового сервера. Таким образом, мы можем считать хиты посетителей и вести лог-файлы.)
RewriteEngine on
Options +FollowSymlinks
RewriteBase /
RewriteRule ^robots.txt$ /robot.php?%{REQUEST_URI}

Директивы кеширования
Кэширование для всех типов файлов по времени доступа
ExpiresActive on
ExpiresDefault "access plus 600 seconds"

Кэширование для всех типов файлов по времени изменения
ExpiresActive on
ExpiresDefault "modification plus 600 seconds"
Кэширование для определённых типов файлов
ExpiresByType text/css "modification plus 600 seconds"
ExpiresByType image/jpeg "modification plus 600 seconds"
ExpiresByType image/gif "modification plus 600 seconds"
ExpiresByType image/x-ico "modification plus 600 seconds"
ExpiresByType image/png "modification plus 600 seconds"

Запрет кеширования с помощью сервера Apache
Откройте файл конфигурации сервера Apache httpd.conf и раскомментируйте следующие строчки:
LoadModule expires_module modules/mod_expires.so
LoadModule headers_module modules/mod_headers.so
...
AddModule mod_expires.c
AddModule mod_headers.c
Впишите в .htaccess следующее:
# Запрещение кеширования в этой папке
# Необходимо включение модулей
# mod_headers.c и mod_expires.c
#
# Заголовок Cache-Control
<IfModule mod_headers.c>
Header append Cache-Control "no-store, no-cache, must-revalidate"
</IfModule>
# Заголовок Expires
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "now"
</IfModule>

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

Кеширование с помощью файла .htaccess
# Разрешение кеширования в этой папке
# Необходимо включение модулей
# mod_headers.c и mod_expires.c
#
# Заголовок Cache-Control
<IfModule mod_headers.c>
Header append Cache-Control "public"
</IfModule>
# Заголовок Expires
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 hours"
#ExpiresDefault "access plus 10 years"
</IfModule>

Кеширование javascript файлов с помощью файла .htaccess
<FilesMatch .*\.js$>
ExpiresDefault "access plus 3 days"
</FilesMatch>
Будьте осторожны при кешировании, т.к. при изменении файла, пользователь может получить новый вариант только через 3 дня!

Как разместить несколько сайтов на одном виртуальном хостинге?
Чтобы разместить два или более сайтов на одном виртуальном хостинге, вопреки отведенному вам тарифным планом количеству доменов необходимо в файле ".htaccess" прописать следующие строки:

RewriteEngine On
RewriteRule ^newdirectory/ - [L]
RewriteCond %{HTTP_HOST} (www.)?newdomain.ru [NC]
RewriteRule (.*) newdirectory/$1 [L]
Где:
newdirectory/ - папка, в которой будет лежать второй сайт
newdomain.ru - домен, для которого мы делаем перенаправление
Обратите внимание, что при этом у Вас будет единый почтовый аккаунт. Т.е. если, у Вас существует ящик admin@domain.ru, то после подключения домена newdomain.ru у ящика admin@domain.ru появляется второе имя - admin@newdomain.ru. А при создании любого нового ящика (например info), ему автоматически присваиваются два имени - info@domain.ru и info@newdomain.ru.

Действующий пример:
Options +Includes +FollowSymLinks -Indexes
AddHandler server-parsed .shtml
DirectoryIndex index.shtml index.htm index.php index.html
AddDefaultCharset windows-1251
CookieTracking on
CookieExpires "1 years"
# default php version is 4.3.9
# uncomment next line to use latest 4.4.x
#AddType application/x-httpd-php44 php
# uncomment next line to use latest 5.x
#AddType application/x-httpd-php5 php

RewriteEngine On

# показываем директорию domen1
RewriteRule ^domen1/ - [last]
RewriteCond %{HTTP_HOST} (www.)?domen1.su [nocase]
RewriteRule (.*) domen1/$1 [last]

RewriteRule ^domen2/ - [last]
RewriteCond %{HTTP_HOST} (www.)?domen2.su [nocase]
RewriteRule (.*) domen2/$1 [last]

RewriteRule ^domen3/ - [last]
RewriteCond %{HTTP_HOST} (www.)?domen3.su [nocase]
RewriteRule (.*) domen3/$1 [last]

RewriteEngine On
RewriteBase /

# для показа без www. поддиректории dopdomen вместе с доменом domen4
RewriteCond %{HTTP_HOST} ^(www.)?dopdomen.domen4.su/$
RewriteCond %{REQUEST_URI} !^/dopdomen(/.*)?$
RewriteCond %{REQUEST_URI} !^/cgi-bin(/.*)?$
RewriteRule ^(.*) /dopdomen/$1 [L]

Поиск страниц больше чем в одном каталоге
Иногда необходимо позволить веб-серверу искать страницы больше чем в одном каталоге.
RewriteEngine on
# во-первых попытаемся найти это в указанном месте/...
# ...и если нашли то заканчиваем поиск:
RewriteCond /your/docroot/dir1/%{REQUEST_FILENAME} -f
RewriteRule ^(.+) /your/docroot/dir1/$1 [L]
# во-вторых - попытаемся найти это в pub/...
# ...и если нашли то заканчиваем поиск:
RewriteCond /your/docroot/dir2/%{REQUEST_FILENAME} -f
RewriteRule ^(.+) /your/docroot/dir2/$1 [L]
# иначе продолжаем для других директив
RewriteRule ^(.+) - [PT]

Виртуальные хосты пользователей
Если Вы хотите предоставлять адреса www.subdomain.domain.ru для страниц пользователей, Вы можете использовать следующий набор правил для преобразования http://www.subdomain.domain.ru/path во внутренний путь /home/subdomain/path:
RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.[^.]+\.ru$
RewriteRule ^(.+) %{HTTP_HOST}$1 [C]
RewriteRule ^www\.([^.]+)\.ru(.*) /home/$1$2

Переадресация поддоменов с помощью .htaccess

Однажды сталкиваешься с проблемой - необходимо иметь неограниченное количество поддоменов, а они как раз кончились. Приходится заниматься изучением mod_rewrite, с помощью которого возможно сделать почти все что угодно.
Потратив достаточно долгое время на поиски готового скрипта, пришлось констатировать тот факт, что либо все это работает не совсем правильно, либо вообще не работает.
Теперь я знаю как это сделать и сейчас покажу на примерах. Для начала сделаем поддомены на свежем сайте, т.е. готовой структуры пока нет и можно делать все что угодно.
Создайте файл .htaccess в корне сайта и впишите в него следующий код:
RewriteEngine on
RewriteBase /
RewriteCond %{HTTP_HOST} !^www\.domain\.(com|ru)$
RewriteCond %{HTTP_HOST} (www\.)?(.*)\.domain\.(com|ru)$
RewriteCond %{REQUEST_URI} !sub/
RewriteRule ^(.*)$ sub/%2/$1
Теперь подробно остановимся на каждом пункте.
Для запуска mod_rewrite используется команда RewriteEngine on, если ее закомментировать, то весь код перестанет работать, часто это бывает очень полезно.
RewriteBase указывает на использование текущей папки.
RewriteCond устанавливает правила, в зависимости от которых будет или не будет произведена замена адреса. В первом случае проверяется является ли поддомен с названием www, естественно его перенаправлять не нужно, поэтому перед строкой стоит восклицательный знак, обозначая отрицание. В скобках указано com|ru, используется только если вы имеете два одинаковых домена в разных зонах и они являются псевдонимами (алиасам) другу друга. Если вы используете один сайт, то запись будет такой:
RewriteCond %{HTTP_HOST} !^www\.domain\.com$
Во втором RewriteCond проверяется наличие в имени адреса поддомена, причем работать будет одинаково с www и без него, т.е. сайты www.forum.domain.com и forum.domain.com будут обрабатываться одинаково.
Третье условие используется для проверки уже исправленного адреса, т.к. mod_rewrite выполняется пока условия перестанут подходить. Итак мы проверяем в строке запроса (URI, то что идет после имени домена, например /info.html) наличие папки куда мы перенаправили запрос, в данном случае это sub, перед ним стоит восклицательный знак, который сообщает, что условие не должно выполняться при наличии такой подстроки.
И наконец само правило преобразования адреса RewriteRule. В нем мы заменяем строку запроса на новый адрес:
sub + второй найденный элемент (условие RewriteCond %{HTTP_HOST} (www\.)?(.*)\.domain\.(com|ru)$, то что находится во вторых скобках) + адрес, который был изначально ( описанный в том же RewriteRule: ^(.*)$)
Перед запуском этого скрипта вам необходимо создать в папке sub необходимые вам папки поддоменов.
Лучше воздержаться от использования в качестве метки и основной папки простое слово типа sub, т.к. оно может оказаться в адресе страницы, лучше использовать произвольный набор символов.
Бывают ситуации, когда необходимо использовать два разных адреса для одной и той же папки, например:
domain.com/forum/
и
forum.domain.com
В данном случае у нас на сервере уже есть папка forum, и полностью копировать ее еще и в папку sub не очень удобно и не совсем правильно. Найденный вариант использования mod_rewrite не совсем универсальный, но все позволяет обслужить конечное число поддоменов:
RewriteEngine on
RewriteBase /
RewriteCond %{HTTP_HOST} ^forum\.domain\.(com|ru)$
RewriteCond %{REQUEST_URI} !/forum/
RewriteRule ^(.*)$ /forum/$1 [L]
Сначала проверяем нужный нам поддомен forum.domain.com (или forum.domain.ru). Потом ищем строку /forum/ в самом запросе, проверяя не изменили ли мы уже этот адрес. И наконец делаем преобразование. Знак [L] обозначает окончание преобразования, если это правило выполнилось, то дальнейшая обработка прекращается.
Таких правил может быть сколько угодно, главное не забывайте о наличии нужных папок на сервере.
В некоторых случаях в панели хостинга нужно прописать алиас для вашего домена. Обычно там описаны два варианта:
domain.com
и
www.domain.com
Вам нужно добавить строку:
*.domain.com
Теперь, когда все настроено и работает, возникает проблема со ссылками Sape. Они не будут нормально отображаться, потому что фактически адрес ссылки изменился, был http://forum.domain.com, а стал, например, http://domain.com/sub/forum/, поэтому в коде Sape нужно прописать новый хост и путь к папке с базой. Выглядит это примерно так:
if (!defined('_SAPE_USER'))define('_SAPE_USER', 'xxxxxxxxxxxxxxxxxxxxxxxxxxxx');
require_once($_SERVER['DOCUMENT_ROOT'].'/sub/forum/'._SAPE_USER.'/sape.php');
$o['host']='forum.domain.com';
$sape = new SAPE_client($o);
echo $sape->return_links();
Обратите внимание на путь к файлу sape.php в require_once и новое имя домена в $o['host']

архив javascript + CSS :: • до 2005 • 2006 • 2007 • 2008 • 2009 • 2010 • 2011

Библиотека JAVASCRIPT 1997- Дизайн и сопровождение © SE@RCHER