Попытка номер раз создать почти идеальный htaccess. Что такое.htaccess и как его создать Обратный редирект с домена без www на домен с www

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

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

И почему этот.htaccess такой особенный?

Профессиональные веб-разработчики отдают предпочтение использованию именно этого файла для настройки основных параметров веб-сервисов. Почему? Да потому что это мощный инструмент для установки дополнительной конфигурации на различных серверах (Denwer, Apache и других).

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

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

Пускай это и тривиально, но все-таки для предотвращения возможных вопросов я хочу добавить, что.htaccess отлично функционирует в любой операционной системе. Вы можете создать конфигурационный файл через любой на своем компьютере. Например, в Windows это «Блокнот», в Mac OS это «TextEdit», в Ubuntu – «Gedit» и т.д.

Каким образом можно создать чудо-файл конфигураций

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


Важные команды

Вот мы и подошли к самому интересному! Первоочередным правилом, которое стоит прописать, это кодировка. Для этого существует вот такая строка:

AddDefaultCharset UTF-8

Если необходимо указать другой вариант кодировки, то ее название вставьте вместо UTF-8.

Еще одна супер-команда – это редирект. Благодаря.htaccess можно легко и быстро установить redirect 301, который позволяет перенаправлять пользователей на другие ссылки, склеивать доменные имена независимо от того есть www или нет.

Так следующие строки кода направят юзеров на сайт coolWeb.com вне зависимости от того есть ли www или нет, а также указана ли в ссылке стартовая страница (coolWeb.com/index.html) или нет.

RewriteEngine on RewriteCond %{ HTTP_REFERER}! ^$ RewriteCond %{ HTTP_REFERER}! ^http://(www\.)? coolWeb.com /.*$ RewriteRule \. (gif|jpg|js|css)$ - [F]

После выполнения данных правил вместо изображений на чужих сайтах будет отображаться сообщение об ошибке (403).

Подведение итогов

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

Для упрощения жизни девелоперам были созданы онлайн-генераторы кода для таких конфигурационных документов. В качестве примера можете ознакомиться с сайтом http://htaccess.ru/generator/ . Сгенерированными правилами можно оперировать и для настройки сайтов, написанных на движках. Таким образом, их можно использовать для WordPress, OpenCard, Joomla! и других.

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

С уважением, Роман Чуешов

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

Проблема

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

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

2. Первый случай, но только у вас показываются расширения файлов и вы меняете "Новый текстовый документ.txt" на ".htaccess". Появляется такая ошибка.

Как же все-таки создать этот файл?

Решение

1. Вы можете просто скачать готовый htaccess . Например, для CMS wordpess можно скачать по ссылке . Если у вас система управления контентом другая, то можете просто удалить все содержимое файла и настроить под себя. Также можно скачать пустой htaccess.

134байт Количество загрузок: 266

2. Создать htaccess можно в файловом менеджере , который вы используете для связи с хостингом (сервером), например, WinSCP. New -> File

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

При поддержке .

andew

2015-02-19T11:30:28+00:00

2017-02-16T05:30:00+00:00

12697

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

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

Делается это разрешение при помощи следующего блока кода:

AllowOverride All #Другие директивы...

Здесь в теге указывается физический путь на сервере до корня вашего сайта, и внутри тега указывается директива AllowOverride. Эта директива может быть установлена в None, чтобы сервер не читал файл.htaccess. Если она установлена в All - сервер будет допускать все директивы.htaccess файла. Значение по умолчанию: AllowOverride All.

Теперь пару слов о названии файла.htaccess. Этот файл может называться и по другому, и это тоже устанавливается в глобальном конфиге apache директивой AccessFileName. По умолчанию эта директива установлена в конфиге как AccessFileName .htaccess, и это значение обычно никто не меняет, но вы должны знать, что изменить его на другое возможно.

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

Для чего мы можем использовать.htaccess файл . Вариантов здесь немало, вот самые распространенные из них:
1.Для управления разрешениями на доступы к каталогам сайта (запаролить директорию, запретить доступ к файлам определенного формата, или доступ к сайту в определенный промежуток времени, запретить или открыть доступ с определенных IP адресов, управлять роботами поисковиков)
2.Для перезаписи текущего URL на новый в зависимости от условий ()
3.Для явного указания кодировки сайта.
4.Для разрешения или запрета просмотра файлов сайта
5.Для защиты от хотлинка
6.Для выполнения ридирктов
7.Для задания своих страниц ошибок
8.Для переопределения индексного файла
9…. и многое другое.

Давайте для примера напишем некий обобщенный файл.htaccess .
В него мы соберем наиболее распространенные случаи использования директив и добавим к ним комментарии. И из этого шаблона путем удаления не нужного вы сможете всегда подготовить конкретный.htaccess для ваших задач. Здесь символ # - это символ комментария применяемый в конфигах apache.

# .htaccess начало шаблона # Установка временной зоны SetEnv TZ Europe/Moscow # Установим принудительно кодировку страниц сайта AddDefaultCharset UTF-8 # Зададим index файл который будет # отдаваться если запрошенный не найден DirectoryIndex index.php index.html # Запретим пользователям просматривать файлы директории Options -Indexes # Разрешим следовать за символическими связями в этом каталоге Options +FollowSymLinks # Разрешение доступа только для указанных IP Order Deny,Allow Deny from all Allow from x.x.x.x # Или запрет доступа по IP Order allow,deny deny from x.x.x.x deny from x.x.x.x allow from all # Запретить всем, то только # одну эту строку указать Deny from all # Закрыть доступ к вложенной директории относительно текущего файла # можно так, или положив туда отдельный.htaccess файл Order Deny,Allow Deny from All # Закрыть директорию паролем AuthType Basic AuthName "Enter a password" #путь до файла с паролями и пользователями AuthUserFile /full/path/to/.htpasswd require valid-user # или закрыть вложенную директорию паролем AuthType Basic AuthName "Enter a password" #путь до файла с паролями и пользователями () AuthUserFile /full/path/to/.htpasswd require valid-user # Запрет на доступ для файла.htpasswd # для всех посетителей кроме разрешенных IP Order Deny,Allow Deny from all Allow from x.x.x.x, x.x.x.xx # Блок если нужно отключить обработку PHP # можно и для задать php_value engine off php_value engine off # # Блок изменение настроек PHP # некоторые директивы зависят от версии PHP #php_flag register_globals off #php_value memory_limit 16M #for files uploading - if needed #php_value max_execution_time 500 #php_value max_input_time 500 #php_value upload_max_filesize 30M #php_value post_max_size 30M #php_flag display_errors off #Настройка PHP для загрузки больших файлов до 256M php_value memory_limit 256M php_value upload_max_filesize 256M php_value post_max_size 256M # # Перезапись URL RewriteEngine On # установить корневой URL как / RewriteBase / #Все запросы с HTTP на HTTPS RewriteCond %{HTTPS} =off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} #Только для указанных каталогов все запросы с http на https redirect RewriteCond %{HTTPS} =off RewriteCond %{REQUEST_URI} /(admin|secret)/ RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} # 301 Редирект как принудительная #постановка замыкающего слеша #RewriteCond %{REQUEST_URI} /+[^\.]+$ #RewriteRule ^(.+[^/])$ %{REQUEST_URI}/ # # 301 Редирект c www.site.ru на site.ru # как удаление www RewriteCond %{HTTP_HOST} ^www\.site\.ru RewriteRule ^(.*)$ http://site.ru/$1 # #301 Универсальный редирект с домена www. на без www. RewriteCond %{HTTP_HOST} ^www\.(.*) RewriteRule ^(.*)$ http://%1/$1 #301 Универсальный редирект с домена без www. на www. RewriteCond %{HTTP_HOST} ^(.*)$ RewriteCond %{HTTP_HOST} !^www\. RewriteRule ^(.*)$ http://www.%1/$1 # 301 Редирект с указанных доменов на основной RewriteCond %{HTTP_HOST} ^www.domen.net$ RewriteCond %{HTTP_HOST} ^domain.net$ RewriteCond %{HTTP_HOST} ^www.domain.net$ RewriteRule ^(.*)$ http://domain.net/$1 # #Редирект с преобразованием GET параметров RewriteCond %{QUERY_STRING} do=page RewriteCond %{QUERY_STRING} id=(\d+) RewriteRule .* /page/%1/? # Внутреннее пере направление на index.php для CMS # Если запрошены не существующие файл или директория # То перенаправлять запрос на index.php RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] # # или еще вариант внутреннего пере направления на index.php RewriteCond $1 !^(index\.php|images|robots\.txt|public) RewriteCond %{REQUEST_URI} !\.(cssіjsіjpgіgifіpng)$ RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php?/$1 # или как: RewriteRule ^(.*)$ index.php [L] # #Еще вариант, для тех у кого не WordPress и кто хочет избавиться #от ненужных запросов (боты и т.п.) к темам, к админки и каталогам WordPress вида #где, что не файл и не директория, и не начинается с /wp-, #то делаем внутренний redirect на index.php RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d #если у вас не WordPress добавим это и также блок после этого RewriteCond %{REQUEST_URI} !^/wp- RewriteRule . /index.php [L] #если у вас не WordPress то всем кто ломиться в /wp-... #отдадим 410 Gone status - рекомендация забыть этот URL #RewriteRule "oldproduct" "-" #общий пример RewriteCond %{REQUEST_URI} ^/wp- RewriteRule . - # Зашита от хотлинка RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^http://site\.ru/ RewriteCond %{HTTP_REFERER} !^https://site\.ru/ RewriteCond %{HTTP_REFERER} !^http://www\.site\.ru/ RewriteCond %{HTTP_REFERER} !^https://www\.site\.ru/ RewriteRule \.(jpeg|png|bmp|gif|jpg|js|css)$ - [F] # # Еще вариант антихотлинка ресурсов (картинок) RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^http://(.+\.)?server\.ru/ RewriteCond %{HTTP_REFERER} !^https://(.+\.)?server\.ru/ RewriteCond %{REQUEST_URI} !null\.gif$ # Перенаправим на картинку заглушку dummy.gif RewriteRule \.(jpg|jpeg|gif|bmp|png)$ http://server.ru/dummy.gif [L] # Еще вариант антихотлинка ресурсов (картинок) RewriteCond %{HTTP_REFERER} !^$ #Замените?mysite\.com/ на адрес вашего блога RewriteCond %{HTTP_REFERER} !^http://(.+\.)?mysite\.com/ RewriteCond %{HTTP_REFERER} !^$ #Замените /images/nohotlink.jpg на ваше изображение с запрещением хотлинка RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpg [L] # Еще вариант антихотлинка ресурсов (картинок) RewriteCond %{HTTP_REFERER} !^http://(.+\.)?mysite\.com/ RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !google. RewriteCond %{HTTP_REFERER} !yandex. RewriteCond %{HTTP_REFERER} !search?q=cache RewriteCond %{HTTP_REFERER} !msn. RewriteCond %{HTTP_REFERER} !yahoo. RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpe [L] # # Вывод 404 ошибки если выключен mod_rewrite ErrorDocument 404 /index.php # Зададим свои страницы для ошибок ErrorDocument 404 /err_404.html ErrorDocument 403 /err_403.html # # Блок кода редиректа на мобильную версию сайта # Как вариант привожу здесь, больше для примера RewriteEngine on # Проверить строку UserAgent браузера RewriteCond %{HTTP_USER_AGENT} acs RewriteCond %{HTTP_USER_AGENT} alav RewriteCond %{HTTP_USER_AGENT} alca RewriteCond %{HTTP_USER_AGENT} amoi RewriteCond %{HTTP_USER_AGENT} audi RewriteCond %{HTTP_USER_AGENT} aste RewriteCond %{HTTP_USER_AGENT} avan RewriteCond %{HTTP_USER_AGENT} benq RewriteCond %{HTTP_USER_AGENT} bird RewriteCond %{HTTP_USER_AGENT} blac RewriteCond %{HTTP_USER_AGENT} blaz RewriteCond %{HTTP_USER_AGENT} brew RewriteCond %{HTTP_USER_AGENT} cell RewriteCond %{HTTP_USER_AGENT} cldc RewriteCond %{HTTP_USER_AGENT} cmd- RewriteCond %{HTTP_USER_AGENT} dang RewriteCond %{HTTP_USER_AGENT} doco RewriteCond %{HTTP_USER_AGENT} eric RewriteCond %{HTTP_USER_AGENT} hipt RewriteCond %{HTTP_USER_AGENT} inno RewriteCond %{HTTP_USER_AGENT} ipaq RewriteCond %{HTTP_USER_AGENT} java RewriteCond %{HTTP_USER_AGENT} jigs RewriteCond %{HTTP_USER_AGENT} kddi RewriteCond %{HTTP_USER_AGENT} keji RewriteCond %{HTTP_USER_AGENT} leno RewriteCond %{HTTP_USER_AGENT} lg-c RewriteCond %{HTTP_USER_AGENT} lg-d RewriteCond %{HTTP_USER_AGENT} lg-g RewriteCond %{HTTP_USER_AGENT} lge- RewriteCond %{HTTP_USER_AGENT} maui RewriteCond %{HTTP_USER_AGENT} maxo RewriteCond %{HTTP_USER_AGENT} midp RewriteCond %{HTTP_USER_AGENT} mits RewriteCond %{HTTP_USER_AGENT} mmef RewriteCond %{HTTP_USER_AGENT} mobi RewriteCond %{HTTP_USER_AGENT} mot- RewriteCond %{HTTP_USER_AGENT} moto RewriteCond %{HTTP_USER_AGENT} mwbp RewriteCond %{HTTP_USER_AGENT} nec- RewriteCond %{HTTP_USER_AGENT} newt RewriteCond %{HTTP_USER_AGENT} noki RewriteCond %{HTTP_USER_AGENT} opwv RewriteCond %{HTTP_USER_AGENT} palm RewriteCond %{HTTP_USER_AGENT} pana RewriteCond %{HTTP_USER_AGENT} pant RewriteCond %{HTTP_USER_AGENT} pdxg RewriteCond %{HTTP_USER_AGENT} phil RewriteCond %{HTTP_USER_AGENT} play RewriteCond %{HTTP_USER_AGENT} pluc RewriteCond %{HTTP_USER_AGENT} port RewriteCond %{HTTP_USER_AGENT} prox RewriteCond %{HTTP_USER_AGENT} qtek RewriteCond %{HTTP_USER_AGENT} qwap RewriteCond %{HTTP_USER_AGENT} sage RewriteCond %{HTTP_USER_AGENT} sams RewriteCond %{HTTP_USER_AGENT} sany RewriteCond %{HTTP_USER_AGENT} sch- RewriteCond %{HTTP_USER_AGENT} sec- RewriteCond %{HTTP_USER_AGENT} send RewriteCond %{HTTP_USER_AGENT} seri RewriteCond %{HTTP_USER_AGENT} sgh- RewriteCond %{HTTP_USER_AGENT} shar RewriteCond %{HTTP_USER_AGENT} sie- RewriteCond %{HTTP_USER_AGENT} siem RewriteCond %{HTTP_USER_AGENT} smal RewriteCond %{HTTP_USER_AGENT} smar RewriteCond %{HTTP_USER_AGENT} sony RewriteCond %{HTTP_USER_AGENT} sph- RewriteCond %{HTTP_USER_AGENT} symb RewriteCond %{HTTP_USER_AGENT} t-mo RewriteCond %{HTTP_USER_AGENT} teli RewriteCond %{HTTP_USER_AGENT} tim- RewriteCond %{HTTP_USER_AGENT} tosh RewriteCond %{HTTP_USER_AGENT} tsm- RewriteCond %{HTTP_USER_AGENT} upg1 RewriteCond %{HTTP_USER_AGENT} upsi RewriteCond %{HTTP_USER_AGENT} vk-v RewriteCond %{HTTP_USER_AGENT} voda RewriteCond %{HTTP_USER_AGENT} w3cs RewriteCond %{HTTP_USER_AGENT} wap- RewriteCond %{HTTP_USER_AGENT} wapa RewriteCond %{HTTP_USER_AGENT} wapi RewriteCond %{HTTP_USER_AGENT} wapp RewriteCond %{HTTP_USER_AGENT} wapr RewriteCond %{HTTP_USER_AGENT} webc RewriteCond %{HTTP_USER_AGENT} winw RewriteCond %{HTTP_USER_AGENT} winw RewriteCond %{HTTP_USER_AGENT} xda RewriteCond %{HTTP_USER_AGENT} xda- RewriteCond %{HTTP_USER_AGENT} up.browser RewriteCond %{HTTP_USER_AGENT} up.link RewriteCond %{HTTP_USER_AGENT} windows.ce RewriteCond %{HTTP_USER_AGENT} iemobile RewriteCond %{HTTP_USER_AGENT} mini RewriteCond %{HTTP_USER_AGENT} mmp RewriteCond %{HTTP_USER_AGENT} symbian RewriteCond %{HTTP_USER_AGENT} midp RewriteCond %{HTTP_USER_AGENT} wap RewriteCond %{HTTP_USER_AGENT} phone RewriteCond %{HTTP_USER_AGENT} ipad RewriteCond %{HTTP_USER_AGENT} iphone RewriteCond %{HTTP_USER_AGENT} iPad RewriteCond %{HTTP_USER_AGENT} iPhone RewriteCond %{HTTP_USER_AGENT} ipod RewriteCond %{HTTP_USER_AGENT} iPod RewriteCond %{HTTP_USER_AGENT} pocket RewriteCond %{HTTP_USER_AGENT} mobile RewriteCond %{HTTP_USER_AGENT} android RewriteCond %{HTTP_USER_AGENT} Android RewriteCond %{HTTP_USER_AGENT} pda RewriteCond %{HTTP_USER_AGENT} PPC RewriteCond %{HTTP_USER_AGENT} Series60 RewriteCond %{HTTP_USER_AGENT} Opera.Mini RewriteCond %{HTTP_USER_AGENT} Moby RewriteCond %{HTTP_USER_AGENT} Mobi # Проверить служебные заголовки, отсылаемые браузером RewriteCond %{HTTP_ACCEPT} "text/vnd.wap.wml" RewriteCond %{HTTP_ACCEPT} "application/vnd.wap.xhtml+xml" # Проверить исключения RewriteCond %{HTTP_USER_AGENT} !windows.nt RewriteCond %{HTTP_USER_AGENT} !bsd RewriteCond %{HTTP_USER_AGENT} !x11 RewriteCond %{HTTP_USER_AGENT} !unix RewriteCond %{HTTP_USER_AGENT} !macos RewriteCond %{HTTP_USER_AGENT} !macintosh RewriteCond %{HTTP_USER_AGENT} !playstation RewriteCond %{HTTP_USER_AGENT} !google RewriteCond %{HTTP_USER_AGENT} !yandex RewriteCond %{HTTP_USER_AGENT} !bot RewriteCond %{HTTP_USER_AGENT} !libwww RewriteCond %{HTTP_USER_AGENT} !msn RewriteCond %{HTTP_USER_AGENT} !america RewriteCond %{HTTP_USER_AGENT} !avant RewriteCond %{HTTP_USER_AGENT} !download RewriteCond %{HTTP_USER_AGENT} !fdm RewriteCond %{HTTP_USER_AGENT} !maui RewriteCond %{HTTP_USER_AGENT} !webmoney RewriteCond %{HTTP_USER_AGENT} !windows-media-player # При выполнении условий переадресация на мобильную версию сайта RewriteRule ^(.*)$ http://mobile.version.of.site.ru #Универсальный 302 редирект на мобильную версию сайта RewriteEngine on #Универсальный редирект на мобильную версию сайта RewriteCond %{HTTP_HOST} ^(.*)$ 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) RewriteRule ^$ http://m.%1 # .htaccess конец шаблона

Расшифрую некоторые флаги из директив:

  • RewriteCond ... - NC значит регистр нечувствительное сравнение выполнять
  • RewriteCond ... - NC см. выше, OR - значит объединять RewriteCond через OR, по умолчанию если ничего не указана то RewriteCond объединяются через AND оператор.
  • RewriteRule ... [L] - L значит закончить (остановить обработку) на этом RewriteRule правиле любые дальнейшие преобразования URL , т.е. последующие RewriteRule не выполнять.
  • RewriteRule ... - L см. выше, R=302 значит выполнить редирект с кодом 302 на преобразованный URL
  • RewriteRule ... - L и R см. выше, QSA - при преобразовании URL выполнять при стыковку заданных частей, а не замену.
  • RewriteRule ... [F] - F, значит отказать в выдачи результата по этому URL кодом 403 Forbidden .
  • RewriteRule . - G|Gone - [G] flag значит отдать код 410 Gone status - рекомендация забыть этот URL

AuthUserFile - задает путь к файлу с паролями для http авторизации пользователя. Путь может быть абсолютный от корня файловой системы Linux сервера или относительный от ServerRoot apache. В Ubuntu ServerRoot "/etc/apache2" по умолчанию. При задании относительного пути от ServerRoot apache начальный слеш в пути не указывается, иначе путь будет восприниматься как абсолютный от корня Linux. Также, если путь содержит недопустимые символы и пробелы его нужно заключать в кавычки, это общее правило.

Order, Deny, Allow

Теперь еще раз, но уже более детально, хотелось бы вернуться к директивам управление доступом: Order , Deny , Allow и более детально описать ее синтаксис и логику.

Директивы Allow , Deny , Order модуля mod_access_compat нежелательны к использованию и считаются устаревшими, хотя и поддерживаются еще в версиях Apache 2.3 и 2.4 . В следующих версиях они будут удалены. Вместо них, начиная с версии Apache 2.3 , этот функционал реализуется директивой Require , которая позволяет более гибко настраивать доступы, чем устаревшие директивы. Детали смотрите в статье , которая подробно описывает директивы Require , Allow , Deny , Order с примерами их использования.

Директива Order синтаксис: Order или

По умолчанию директива Order имеет порядок: Deny,Allow . Обратите внимание, что Deny,Allow пишутся без пробела.

В зависимости от того в каком порядке указаны директивы Deny,Allow или Allow,Deny меняется логика работы.

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

Например, что бы запретить (блокировать) доступ с IP x.x.x.x и x.x.x.xx и разрешить доступ всем остальным необходимо добавить в.htaccess следующий код:

# Разрешить ВСЕМ кроме указанных IP
Order Allow,Deny
Allow from all
Deny from x.x.x.x x.x.x.xx

Обратите внимание что IP записаны через пробел. Можно также указать IP как IP/маска.

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

# Запретить ВСЕМ кроме указанных IP
Order Deny,Allow
Deny from all
Allow from x.x.x.x x.x.x.xx

Запрет или разрешение можно указывать и на отдельный файл или группы файлов. Например, что бы запретить доступ всех кроме IP x.x.x.x к файлу passwd.html, который расположен в текущей директории.

# Запретить файл passwd.html ВСЕМ кроме указанных IP

Order Deny,Allow
Deny from all
Allow from x.x.x.x

Аналогично можно запретить или разрешить доступ к определенной группе файлов описав их через регулярное выражение. Например, к файлам с расширением ".key":

#Запретить файлы *.key ВСЕМ кроме указанных IP

Order Deny,Allow
Deny from all
Allow from x.x.x.x

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

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

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

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

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

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

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

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

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

Настройка доступа htaccess

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

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

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

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

Order deny,allow
Deny from all

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

Order deny,allow
Deny from all
Allow 192.168.0.

Если указано 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 % {HTTP_HOST} ^www.site.ru$
RewriteRule ^(.*)\.html$ $1.php

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

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

Настройка редиректов 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

Настройка страниц ошибок в 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. Здесь достаточно просто перечислить mime типы файлов, которые нужно сжать. Например:

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

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


Выводы

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

На завершение предлагаю видео с обзором конфигурационного файла Apache:

Читайте также

Понравилось? Лайкни нас на Facebook