Ваше полное руководство по .htaccess: включая основы .htaccess и многое другое

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

Почему он называется .htaccess? Этот тип файлов изначально использовался для ограничения доступа пользователей к определенным каталогам, и это название просто прижилось. Он использует подмножество директив настроек Apache http.conf, которые дают системному администратору контроль над тем, кто имеет доступ к каждому каталогу.

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

Где я могу найти файл .htaccess?

Учебник по .htaccess расскажет вам, что вы можете найти его в каждой папке (каталоге) на вашем сервере. Но, как правило, корневая веб-папка (та, которая содержит все содержимое вашего веб-сайта) будет иметь один файл. Обычно он имеет имя вроде public_html или www. Если у вас есть каталог с многочисленными подкаталогами веб-сайтов, вы обычно найдете файл .htaccess в основном корневом каталоге (public_html). И по одному во всех подкаталогах (/sitename).

Почему я не могу найти файл .htaccess?

Большинство файловых систем — имена файлов, начинающиеся с точки ( . ), будут скрыты. Так что по умолчанию вы не сможете их увидеть. Однако добраться до них все же можно. Если вы посмотрите на свой FTP-клиент или файловый менеджер, вы, скорее всего, найдете параметр «показывать скрытые файлы». Он может находиться в другом месте, в зависимости от того, какую программу вы используете. Но обычно вы найдете его, если заглянете в «Настройки», «Настройки», «Параметры папки» или «Вид».

Что делать, если у меня нет файла .htaccess?

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

Если вы искали везде и все еще не можете найти его, не бойтесь, потому что основы .htaccess несложно понять. И у нас есть для вас руководство по .htaccess. Вы можете создать его, открыв текстовый редактор и создав новый документ. Он не должен иметь расширения .txt или любого другого файла. Просто .htaccess и убедитесь, что он сохранен в формате ASCII (он не должен быть в UTF-8 или что-то в этом роде) как .htaccess. Перенесите его в нужный каталог с помощью FTP или файлового менеджера в веб-браузере.

Обработка кода ошибки

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

Если этот процесс срабатывает, то сервер сообщает об ошибке и соответствующем коде. Различные типы ошибок имеют разные коды ошибок. И вы, вероятно, видели ошибку 404 «Не найдено» довольно много раз. Однако это не единственный случай.

Ошибки запроса клиента

• ошибка 400, неверный запрос
• 401 — Требуется авторизация
• 402 — Требуется оплата (еще не используется)
• 403 — Запрещено
• 404 Не Найдено
• 405 — Метод не разрешен
• 406 — Недопустимо (кодировка)
• 407 — Требуется аутентификация прокси
• 408 — Время запроса истекло
• 409 — Конфликтующий запрос
• 410 — Ушел
• 411 — требуется длина содержимого
• 412 — Предварительное условие не выполнено
• 413 — Слишком длинный запрос сущности
• 414 — слишком длинный URI запроса
• 415 — Неподдерживаемый тип носителя.

Ошибки сервера

• 500 – внутренняя ошибка сервера
• 501 — Не реализовано
• 502 Неверный шлюз
• 503 Сервис недоступен
• Ошибка 504 Время ответа сервера истекло
• 505 — версия HTTP не поддерживается

Что происходит по умолчанию?

Когда нет спецификации того, как подходить к обработке ошибок, сервер просто отправляет сообщение в браузер. Что, в свою очередь, дает пользователю общее сообщение об ошибке, но это не особенно полезно.

Создание документов об ошибках

На этом этапе руководства по .htaccess вам понадобится HTML-документ для каждого кода ошибки. Вы можете называть их как угодно, но вы можете подумать о подходящем имени. Например, not-found.html или просто 404.html.

Затем в файле .htaccess определите, какой документ относится к какому типу ошибки.

ErrorDocument 400 /errors/bad-request.html
ErrorDocument 401 /errors/auth-reqd.html
ErrorDocument 403 /errors/forbid.html
ErrorDocument 404 /errors/not-found.html
ErrorDocument 500 /errors/server-err.html

Только учтите, что у каждого своя строка — и готово.

Альтернативы .htaccess — руководство по обработке ошибок .htaccess

Большинство CMS, таких как WordPress и Drupal, а также веб-приложения будут обрабатывать эти коды ошибок по-своему.

Защита паролем с помощью .htaccess

Как мы уже говорили, файлы .htaccess изначально использовались для ограничения доступа пользователей к определенным каталогам. Итак, давайте сначала рассмотрим это в нашем руководстве по .htaccess.

.htpasswd — этот файл содержит имена пользователей и пароли для системы .htaccess.

Каждый сидит на своей строке вот так:

имя пользователя: зашифрованный пароль

например:

ДжеймсБраун: 523xT67mD1

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

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

Вы можете выбрать один из нескольких различных алгоритмов хеширования:

• bcrypt — самый безопасный, но в результате процесс шифрования замедляется. Apache и NGINX совместимы.
• md5 — последние версии Apache используют этот алгоритм хэширования по умолчанию, но NGINX его не поддерживает.

Небезопасные алгоритмы. Их лучше избегать.

• crypt() — ранее была функцией хэширования по умолчанию, но не является безопасным вариантом.
• SHA и Соленый SHA.

.htaccess Руководство по добавлению имен пользователей и паролей с помощью CLI

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

.htpasswd — это команда для работы с файлом .htpasswd.

Просто используйте команду с параметром -c, чтобы создать новый файл .htpasswd. Затем введите путь к каталогу (фактический путь на сервере, а не URL-адрес). Вы также можете добавить пользователя, если хотите.

> htpasswd -c /usr/local/blah/.htpasswd jamesbrown

Это создает новый файл .htpasswd в каталоге /blah/ вместе с записью для пользователя с именем jamesbrown. Затем он запросит у вас пароль — также зашифрованный и сохраненный с использованием шифрования md5.

Если файл .htpasswd уже существует в этом месте, новый пользователь просто становится частью существующего файла. Так что новый не создаст. В противном случае, если вы предпочитаете использовать алгоритм хеширования bcrypt, используйте параметр -b.

Хеширование пароля без командной строки

Если вы знакомы только с основами .htaccess, вы можете не использовать командную строку или SSH-терминал. В этом случае вы можете просто создать файл .htpasswd. Затем просто используйте текстовый редактор, чтобы заполнить все перед загрузкой с помощью FTP или файлового менеджера.

Конечно, это оставляет вам задачу шифрования паролей. Но это не должно быть проблемой, потому что в Интернете есть множество программ для шифрования паролей. Многие другие руководства по .htaccess, вероятно, одобрят генератор htpasswd на Aspirine.org. Потому что он предлагает несколько вариантов алгоритмов, которые позволяют определить, насколько надежный пароль. После запуска скопируйте хешированный пароль в файл .htpasswd.

Вам понадобится только один файл .htpasswd для всех ваших файлов .htaccess. Так что нет необходимости иметь по одному для каждого. Один будет выполнять работу для всего основного каталога сервера или учетной записи веб-хостинга. Но не помещайте файл .htpasswd в каталог, к которому может получить доступ любой. Итак, не в public_html или www или любом подкаталоге. С точки зрения безопасности безопаснее разместить его где-нибудь, доступном только изнутри самого сервера.

Краткое руководство по .htaccess: как использовать .htpasswd с .htaccess

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

AuthUserFile /usr/local/etc/.htpasswd
AuthName "Name of Secure Area"
AuthType Basic
<Limit GET POST>
require valid-user
</Limit>

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

Тег <Limit> определяет, что ограничивается. В этом случае возможность GET или POST для любого файла в каталоге. Внутри пары тегов <Limit> находится список тех, кому разрешен доступ к файлам.

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

AuthUserFile /usr/local/etc/.htpasswd
AuthName "Name of Secure Area"
AuthType Basic
<Limit GET POST>
require user janebrown
require user jamesbrown
</Limit>

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

admin: janebrown jamesbrown
staff: zappafrank agrenmorgen

Теперь это стало чем-то, на что вы можете ссылаться в своем файле .htaccess:

AuthGroupFile /usr/local/etc/.htpeople
AuthName "Admin Area"
AuthType Basic
<Limit GET POST>
require group admin
</Limit>

Руководство по .htaccess для альтернатив .htpasswd

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

Включение включений на стороне сервера (SSI) — руководство по .htaccess

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

<!-- include virtual="header.shtml" -->

Он также имеет условные директивы (if, else и т. д.) и переменные, что делает его полноценным языком сценариев. Хотя его сложно использовать, если в вашем проекте есть что-то более сложное, чем один или два включения. Если дело дойдет до этого момента, разработчик, как правило, будет использовать вместо этого PHP или Perl.

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

AddType text/html .shtml
AddHandler server-parsed .shtml
Options Indexes FollowSymLinks Includes

Это должно включить SSI для всех файлов с расширением .shtml. Вы можете указать SSI анализировать файлы .html с помощью такой директивы:

AddHandler server-parsed .html

Зачем беспокоиться?

Ну, этот способ позволяет вам использовать SSI, не предупреждая никого о том, что вы это делаете. Кроме того, если вы позже измените реализации, вы можете сохранить расширения файлов .html. Единственная ложка дегтя здесь заключается в том, что каждый файл .html будет затем анализироваться с помощью SSI. И если у вас есть много файлов .html, которые не нуждаются в анализе SSI, это излишне усложняет работу сервера. Таким образом, увязнуть его без дополнительной выгоды.

SSI на странице индекса

Чтобы избежать синтаксического анализа каждого отдельного файла .html без использования SSI в вашем домашнем индексе, вы должны указать это в своем файле .htaccess. Потому что, когда веб-сервер ищет индексную страницу каталога, он будет искать index.html по умолчанию. Если вы не анализируете файлы .html, вы должны назвать свою индексную страницу «named index.shtml», если хотите, чтобы SSI работал. Потому что тогда ваш сервер не будет искать его автоматически. Для этого просто добавьте:

DirectoryIndex index.shtml index.html

Это позволяет веб-серверу узнать, что файл index.shtml является основным для каталога. Второй параметр, index.html, является отказоустойчивым. На это ссылаются, когда не удается найти index.shtml.

Черный список IP-адресов и белый список IP-адресов с .htaccess

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

Черный список по IP

Это позволит вам занести адреса в черный список (числа являются примерами):

order allow,deny
deny from 444.33.55.6
deny from 735.34.6.
allow from all

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

Обратите внимание на третью строку, в которой написано «отказаться от 735.34.6». Это не полный IP-адрес, но это нормально, потому что он запрещает каждый IP-адрес в этом блоке. Следовательно, все, что начинается с 735.34.6. Вы можете указать сколько угодно IP-адресов, по одному в каждой строке, с директивой deny from.

Белый список по IP

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

order deny,allow
deny from all
allow from 111.22.3.4
allow from 789.56.4.

Доменные имена вместо IP-адресов

Вы также можете заблокировать или разрешить пользователям доменного имени. Это полезно, если люди перемещаются между IP-адресами. Но это не сработает против тех, кто контролирует их обратное сопоставление IP-адресов DNS.

order allow,deny
deny from forinstance.com
allow from all

Это работает и для субдоменов. В приведенном выше примере вы также заблокируете посетителей с abc forinstance.com.

Блокировка пользователей по рефереру — руководство по .htaccess

Если веб-сайт содержит ссылку на ваш сайт и кто-то переходит по ней, мы называем это «реферером». Но это работает не только для интерактивных гиперссылок на ваш сайт. Любая страница в Интернете может напрямую ссылаться на ваши изображения. Это называется хотлинкинг. Он часто крадет вашу пропускную способность, может нарушать ваши авторские права — и вы даже не получаете от него дополнительный трафик. И это не только изображения. Незнакомец также может ссылаться на другие ваши ресурсы, такие как файлы CSS и сценарии JS.

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

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

Основы .htaccess. Директивы, блокирующие реферер, зависят от движка mod_rewrite.

Код для блокировки по рефереру выглядит так:

RewriteEngine on
RewriteCond % ^http://.*forinstance.com [NC,OR]
RewriteCond % ^http://.* forinstance2.com [NC,OR]
RewriteCond % ^http://.* forinstance3.com [NC]
RewriteRule .* - [F]

Это немного неудобно, так что давайте пройдемся по нему.

RewriteEngine on в первой строке сообщает синтаксическому анализатору, что некоторые директивы перезаписи находятся в пути. Каждая из строк 2, 3 и 4 блокирует один ссылающийся домен. Чтобы изменить это в своих целях, вы должны изменить часть доменного имени (например) и расширение (.com). Т

обратная косая черта перед .com является escape-символом. Сопоставление с образцом, используемое в имени домена, является стандартным выражением. И точка имеет значение в RegEx. Поэтому его необходимо «экранировать» с помощью «/».

NC в скобках указывает, что совпадение не должно быть чувствительным к регистру. OR буквально означает «или» и указывает на то, что новые правила находятся в разработке. Пока URL-адрес этот, этот или этот, следуйте этому правилу перезаписи.

Последняя строка — это само правило перезаписи. [F] означает «Запрещено». Если запрос поступает от реферера, подобного указанным в списке, то он будет заблокирован. И придет ошибка 403 Forbidden.

Руководство .htaccess по блокировке ботов и веб-скрейперов

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

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

Указание файла по умолчанию для каталога

Когда сервер получает запрос URL-адреса, но без указанного имени файла, он предполагает, что URL-адрес относится к каталогу. Итак, вот руководство .htaccess о том, что делать. Если вы запросите http: forinstance.com, Apache (и большинство серверов) будет искать домен в корневом каталоге. Обычно /public_html или что-то подобное, например, /forinstance-com — чтобы найти файл по умолчанию. Файл по умолчанию будет называться index.html по умолчанию. Потому что, когда Интернет был молод, веб-сайты часто были просто набором документов, связанных вместе. А «домашние» страницы часто были не более чем указателем, чтобы вы знали, где что находится.

Конечно, в настоящее время вы можете не захотеть, чтобы index.html был страницей по умолчанию. Возможно, потому что вам может понадобиться другой тип файла. Поэтому index.shtml, index.xml или index.php могут быть более подходящими. Или, может быть, вы не считаете свою домашнюю страницу «индексом» и хотите назвать ее как-то иначе. Например, home.html или primary.html.

Установите страницу каталога по умолчанию

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

DirectoryIndex [имя файла идет сюда]

Если вы хотите, чтобы ваш файл по умолчанию был home.html, это так же просто, как использовать:

DirectoryIndex home.html

.htaccess Руководство по настройке нескольких страниц по умолчанию

Вы также можете установить более одного DirectoryIndex:

DirectoryIndex index.php index.shtml index.html

Это работает следующим образом: веб-сервер сначала ищет первый. Если он не может найти его, он ищет второй и идет дальше. Но зачем вам это нужно? Разве вы не знаете, какой файл вы хотите использовать в качестве страницы по умолчанию? Имейте в виду, что одна из основ .htaccess заключается в том, что он влияет на свой собственный каталог. И каждый подкаталог тоже, пока он не будет отменен более локальным файлом.

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

.htaccess Руководство по перезаписи URL-адресов и переадресации URL-адресов

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

301 или 302

Существует два типа кодов ошибок перенаправления, которые генерирует сервер, а именно 301 и 302.

301 говорит вам, что что-то «перемещено безвозвратно». Между тем, 302 означает, что он «Временно перемещен». В большинстве случаев 301 отлично справляется со своей задачей. И, возможно, что еще более важно, он получает SEO-очки, поскольку исходный URL-адрес может быть взят с новой страницы.

Это также заставит большинство браузеров обновить свои закладки и кэшировать сопоставление старого и нового. Следовательно, это позволяет им запрашивать новый URL-адрес при поиске оригинала. Для постоянно измененного URL-адреса это все ответы, которые вам нужны.

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

Redirect or Rewrite

Вы можете изменить URL-адрес с помощью директив .htaccess несколькими способами — командой Redirect и механизмом mod_rewrite. Команда Redirect сообщает браузеру, какой другой URL-адрес следует искать. Инструмент mod_rewrite обычно «переводит» URL-адрес в запросе. Превращает его во что-то, что может понять файловая система или CMS. Затем он обрабатывает запрос так, как если бы переведенный URL-адрес был запрошенным.

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

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

Базовая переадресация страницы — руководство по .htaccess

Для перенаправления одной страницы на другой URL-адрес код выглядит следующим образом:

Redirect 301 /relative-url.html http://forinstance.com/full-url.html

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

1. сама команда перенаправления
2. его тип ( 301 — Перемещено навсегда )
3. относительный URL исходной страницы
4. полный URL новой страницы.

Относительный URL-адрес относится к каталогу, содержащему файл .htaccess. Обычно это корневой веб-сайт или корень домена.

Таким образом, если бы http://forinstance.com/blog.php был перемещен на http://blog.forinstance.com, код был бы таким:

Redirect 301 /blog.php http://blog.forinstance.com

Перенаправление большого раздела — руководство по .htaccess

Вы уже внесли изменения в структуру каталогов? Если вы не изменили имена своих страниц, перенаправьте все запросы к определенному каталогу на новый.

Redirect 301 /old-directory http://forinstance.com/new-directory

Перенаправление всего сайта – руководство по .htaccess

Но как быть, если весь ваш сайт перешел на новый URL-адрес? Без проблем.

Redirect 301 / http://thenewurl.com

Перенаправление с www на без www — руководство по .htaccess

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

Некоторые все еще используют его по сей день, но многие пошли дальше. У пользователей стало такой привычкой набирать «www». перед каждым URL. Поэтому вам будет сложно, если у вас не хватает этих букв. Однако модуль mod_rewrite может вам в этом помочь. И у вас, вероятно, уже есть один на панели инструментов вашего веб-хостинга.

Options +FollowSymlinks
RewriteEngine on
RewriteCond % ^www.forinstance.com [NC]
RewriteRule ^(.*)$ http://forinstance.org/$1 [R=301,NC]

Но будь осторожен! Многие другие руководства по .htaccess и mod_rewrite дадут вам некоторую версию этого кода для достижения этой цели:

Options +FollowSymlinks
RewriteEngine on
RewriteCond % !^forinstance.com [NC]
RewriteRule ^(.*)$ http://forinstcance.org/$1 [R=301,NC]

Вы видите, что с ним не так?

Все поддомены перенаправляются на основной домен! Это означает не только www.forinstance.com, но и другие, такие как blog.forinstance.com и admin.forinstance.com. Не идеальное поведение!

Перенаправление на www — руководство по .htaccess

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

RewriteEngine On
RewriteCond % ^forinstance.com [NC
RewriteRule ^(.*) http://www.website.com/$1 [R=301,NC]

Одного делать нельзя:

Ряд руководств по .htaccess рекомендуют перенаправлять ошибки 404 на домашнюю страницу. Хотя это возможно, мы пишем в нашем руководстве по .htaccess, что на самом деле это ужасная идея. Потому что это сбивает посетителей с толку. Они будут ожидать другую страницу, а вместо этого получат вашу домашнюю страницу. Страница с ошибкой 404 сообщила бы им именно то, что им нужно было знать, а это нет. И вообще, в чем проблема признать, что страница не найдена? В этом нет ничего постыдного.

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

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

Основы .htaccess — скрытие файла .htaccess

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

<Files .htaccess>
order allow,deny
deny from all
</Files>

.htaccess руководство по типам MIME

Типы MIME — это типы файлов, изначально предназначенные для электронной почты («Многоцелевые расширения почты Интернета»). Но не думайте о них только как о «типах файлов», потому что MIME предлагает определенный формат для их указания. Если вы когда-либо писали HTML-документ, вы, вероятно, указали тип MIME. Наверное, даже не осознавая этого:

<style type=”text/css” src=”/style.css” />

Атрибут type относится к конкретному типу MIME.

Типы MIME на вашем сервере

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

AddType text/richtext rtx

Эта директива состоит из трех частей, разделенных пробелами:

• Команда «AddType»
• MIME-тип
• Расширение файла.

Вы можете связать несколько разных расширений файлов с одним и тем же типом MIME в одной строке.

AddType video/mpeg mpg MPEG MPG  

Принудительная загрузка по типу MIME

Хотите, чтобы каждая ссылка на тип файла загружалась автоматически, а не просто открывалась в браузере? Затем используйте MIME-тип application/octet-stream, например:

AddType application/octet-stream pdf

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

AddType application/octet-stream rtf txt pdf docx doc

Список расширений файлов и типов MIME — основы .htaccess

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

AddType application/macbinhex-40 hqx
AddType application/netalive net
AddType application/netalivelink nel
AddType application/octet-stream bin exe
AddType application/oda oda
AddType application/pdf pdf
AddType application/postscript ai eps ps
AddType application/rtf rtf
AddType application/x-bcpio bcpio
AddType application/x-cpio cpio
AddType application/x-csh csh
AddType application/x-director dcr
AddType application/x-director dir
AddType application/x-director dxr
AddType application/x-dvi dvi
AddType application/x-gtar gtar
AddType application/x-hdf hdf
AddType application/x-httpd-cgi cgi
AddType application/x-latex latex
AddType application/x-mif mif
AddType application/x-netcdf nc cdf
AddType application/x-onlive sds
AddType application/x-sh sh
AddType application/x-shar shar
AddType application/x-sv4cpio sv4cpio
AddType application/x-sv4crc sv4crc
AddType application/x-tar tar
AddType application/x-tcl tcl
AddType application/x-tex tex
AddType application/x-texinfo texinfo texi
AddType application/x-troff t tr roff
AddType application/x-troff-man man
AddType application/x-troff-me me
AddType application/x-troff-ms ms
AddType application/x-ustar ustar
AddType application/x-wais-source src
AddType application/zip zip
AddType audio/basic au snd
AddType audio/x-aiff aif aiff aifc
AddType audio/x-midi mid
AddType audio/x-pn-realaudio ram
AddType audio/x-wav wav
AddType image/gif gif GIF
AddType image/ief ief
AddType image/jpeg jpeg jpg jpe JPG
AddType image/tiff tiff tif
AddType image/x-cmu-raster ras
AddType image/x-portable-anymap pnm
AddType image/x-portable-bitmap pbm
AddType image/x-portable-graymap pgm
AddType image/x-portable-pixmap ppm
AddType image/x-rgb rgb
AddType image/x-xbitmap xbm
AddType image/x-xpixmap xpm
AddType image/x-xwindowdump xwd
AddType text/html html htm
AddType text/plain txt
AddType text/richtext rtx
AddType text/tab-separated-values tsv
AddType text/x-server-parsed-html shtml sht
AddType text/x-setext etx
AddType video/mpeg mpeg mpg mpe
AddType video/quicktime qt mov
AddType video/x-msvideo avi
AddType video/x-sgi-movie movie
AddType x-world/x-vrml wrl

Блокировать хотлинкинг — Руководство по .htaccess

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

<img src=”http://yourdomain.com/video.mpg”>

Маршрут хотлинкинга экономит ваши усилия и пропускную способность. И нет, это не значит, что мы это одобряем — как раз наоборот.

<img src=”http://originaldomain.com/video.mpg”>

То же самое происходит с файлами CSS и JS, но в основном это происходит с изображениями и видео. Такие сайты, как Википедия, не возражают против того, чтобы вы это делали. И есть другие, которые хотят, чтобы вы сделали это, потому что это помогает их потребностям в SEO. Кроме того, есть такие, как JQuery, которые используют CDN для совместного использования своих библиотек JS, поэтому вам не нужно размещать их самостоятельно. Но многие веб-хосты рассматривают хотлинкинг как способ кражи их материалов и захвата пропускной способности.

Если ваш сайт не очень большой, то вы не хотите получать тысячи запросов каждый день. Особенно если учесть, что они не приводят посетителей на ваш сайт и не приносят вам никакой пользы. Итак, если хотлинкинг только повышает ваше кровяное давление, вы можете его заблокировать. Просто добавив некоторые правила mod_rewrite в ваш файл .htaccess.

RewriteEngine on
RewriteCond % !^$
RewriteCond % !^http://(www.)?forinstance.com/.*$ [NC]
RewriteRule .(gif|jpg|jpeg|png|js|css)$ - [F]

Не забудьте изменить forinstance.com в строке 3 на ваше подлинное доменное имя. Таким образом, мы перехватываем любые запросы, исходящие не из вашего домена. И проверьте их, чтобы увидеть, соответствуют ли они одному из расширений файлов, которые вы определили в строке 4. Если есть какое-либо совпадение — запрос отклонен. Вы также можете легко добавить в список другие расширения файлов, отредактировав последнюю строку.

Включение CGI везде

CGI — Common Gateway Interface — это метод на стороне сервера, который включает не-HTML-скрипты (например, SSI или Perl) на веб-страницах. CGI-скрипты обычно находятся в папке с именем /cgi-bin. Конфигурации сервера должны рассматривать любой ресурс в этом каталоге как сценарий, а не как страницу.

Проблема заключается в том, что URL-адреса, которые ссылаются на ресурсы CGI, должны содержать /cgi-bin/. Таким образом, они могут разместить детали реализации в вашем URL-адресе — обратный шаблон, которого вам следует избегать по нескольким причинам. Между тем, сложный сайт может нуждаться в лучшей структуре, чем просто множество скриптов, забитых в одну папку /cgi-bin.

Чтобы ваш сервер анализировал сценарии CGI, независимо от местоположения каталога, просто поместите это в свой файл .htaccess:

AddHandler cgi-script .cgi
Options +ExecCGI

Если у вас есть другие расширения файлов, которые вы хотели бы обработать как сценарии CGI, просто добавьте их в первую строку.

Скрипты как исходный код

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

RemoveHandler cgi-script .pl .cgi .php .py
AddType text/plain .pl .cgi .php .py

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

RemoveHandler cgi-script .pl .cgi .php .py
AddType application/octet-stream .pl .cgi .php .py

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

Настройка параметров PHP

Иногда вам нужно настроить параметры PHP, и это лучше всего сделать с помощью файла с именем php.ini. Дело в том, что некоторые хостинговые компании, особенно виртуальные хостеры, не позволяют своим клиентам делать это. Но вы можете обойти это, внедрив правила php.ini в свой файл .htaccess. Вот синтаксис:

php_value [имя настройки] [значение]

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

php_value upload_max_filesize  12M

Вы не можете указать все настройки PHP в файле .htaccess. Например, вы не можете отключить_классы вот так. Чтобы увидеть полный список всех настроек php.ini, ознакомьтесь с официальным руководством по директивам php.ini.

Когда не использовать .htaccess

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

Далее вверх по дереву

Если вам захочется поместить директиву в файл .htaccess, вам, вероятно, следует вместо этого выбрать файл httpd.conf. Это файл настроек конфигурации для всего сервера. Надлежащим домом для настроек PHP также является файл php.ini, и у большинства языков есть свои собственные эквиваленты.

Допустим, вы разместили директивы выше в дереве, в файле httpd.conf, php.ini или другом подходящем для этого языка файле. Затем вы можете встроить эти настройки в механизм синтаксического анализа сервера. С .htaccess вы должны проверять и интерпретировать директивы каждый раз, когда поступает запрос.

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

Жаль, что многие провайдеры виртуального хостинга не пускают своих клиентов в файлы httpd.conf или php.ini. Следовательно, вынуждая их довольствоваться более медленным файлом .htaccess.

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