Htaccess — Вопрос по mod_rewrite (дублирование загрузки страниц)


Содержание

Переписать мой файл .HTACCESS

Я знаю, что этот вопрос был опубликован несколько раз на этом форуме.

И я следовал каждому приведенному примеру. Перепробовал каждый код.

И все же я не могу добиться желаемого результата.

У меня проблема с перезаписью моего файла .HTACCESS

В основном, я хочу сделать 4 вещи:

(а) удалить все расширения PHP

(б) удалить все расширения HTML

(c) удалить любые косые черты

(d) добавить кучу «jibberish» в конце любых URL,

так что ссылка не видна неопытному глазу.

Я не нашел ничего в Интернете о том, как справиться с этим четвертым вопросом

Что касается первых трех, я получил это из онлайн-урока:

Но это не работает.

В моих файлах HTML / PHP я пытался запустить тест, удалив расширения.

Например, я изменил:

Я удалил расширение HTML (я сделал то же самое для файлов PHP тоже)

Очевидно, мой HTACCESS файл неверный.

Но не уверен, в чем проблема ��

ОБНОВИТЬ

После тщательного изучения, это то, что я создал в качестве файла HTACCESS:

Но это все еще не работает

ОБНОВИТЬ

Я наконец получил это работает

Я просто закомментировал КАЖДУЮ другую строку из кода и оставил только это:

Что касается меня, я не могу точно понять, ЧТО беспокоило код в первую очередь.

Очевидно, что Htaccess может принять сотни строк кода.

Но как их наложить, в правильном порядке? Потому что с помощью процесса исключения (то есть, закомментировав каждую строку отдельно), я могу сделать вывод, что мой синтаксис кода был неправильным!

Но почему именно?

Должен ли я объявлять условие (COND) перед каждым правилом?

Или ………… я должен объявить условия только ОДИН РАЗ ………. и затем исправить все правила ниже этого:

Я изучил все доступные онлайн-учебники, и они нигде не затрагивают этот вопрос.

Решение

Чтобы ответить на вопрос, который вы упомянули в комментарии .. Вы htaccess не является правильно настроен.

Я нашел очень хороший объясненный ответ онлайн. Ссылка здесь

После нескольких обходных попыток мне удалось заставить перезаписывать URL работать так, как я хотел, чтобы я мог сделать довольно без расширения
URL-адреса для моих сайтов (например, domain.com/thispage).

Потому что лично я нашел htaccess и mod-rewrite плохо
документировано, за исключением мучительно технической документации Apache, я
думал, что я сломаю код, который я использую:

Options + FollowSymlinks Во-первых, просто чтобы быть в безопасности, мы делаем
убедитесь, что опция FollowSymlinks включена, чтобы сервер
на самом деле обрабатывать и следовать нашим «вымышленным» URL.

RewriteEngine On RewriteEngine — это работающий над перезаписью мод
делать всю нашу работу, поэтому мы должны включить ее.

RewriteBase / yourdir Это позволяет нам установить любой каталог в качестве базы для
переписывает и облегчает написание наших регулярных выражений и
переписывает, так как нам не приходится иметь дело с надоедливыми базовыми каталогами. Это
также очень удобно при переносе кода из каталога на
сервер разработки до корня живого сайта.

RewriteCond% ! (. [^. /] +) $, Так как мы не хотим делать
любые существующие файлы недоступны, мы уверены, что URI (в этом
case часть URL после нашей базовой директории) не имеет файла
расширение. Регулярное выражение более буквально проверяет, что оно «делает
не содержать точку, за которой следуют один или несколько символов, которые не являются
точка или косая черта. «

RewriteCond% ! -D Это говорит Rewrite Engine не
переписать URL, если он совпадает с существующим именем на сервере с
флаг каталога (т. е. если это каталог).

RewriteCond% ! -F И этот, аналогично, говорит об этом
не переписывать имена существующих файлов.

RewriteRule ^ (. *) Yourscript.php? Yourargument = $ 1 [PT] Наконец, мы имеем
фактическое правило переписывания. Так как я хочу передать переменные
к PHP-скрипту для загрузки контента, так настроено мое правило. это
соответствует практически любому числу или комбинации символов после нашего
RewriteBase, который мы установили ранее, и передает части, соответствующие внутри
круглые скобки там, где мы помещаем наши пронумерованные переменные $ в нашем
переписанный URL. Таким образом, первый набор скобок идет до $ 1, второй
набор будет идти до $ 2 и так далее. Наконец, если вы хотите связать
вывод одного правила перезаписи на следующий, вы устанавливаете флаг [PT], чтобы разрешить
для прохождения переписанных URL.

Одно важное замечание: работа RewriteEngine немного забавна
учитывая, как человек будет читать код … На самом деле он проверяет
регулярное выражение в вашем RewriteRule перед проверкой любого
из условий, указанных выше правила RewriteCond. Итак по порядку
для любого из ваших условий, которые будут проверены, все это должно сначала
найти действительное совпадение для работы.

Наконец, если вы хотите скопировать и вставить, вот весь код
вместе, готовы быть добавлены в файл .htaccess и дать вам
URL без расширений путем передачи переменных в сценарии:

301 Редирект .htaccess — полный обзор с примерами

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

Самый главный файл .htaccess располагается в корне сайта:

Его действия распространяются на текущий каталог и на все вложенные каталоги. Т.е. у владельцев сайтов есть возможность воздействовать только на работу своего проекта, не мешая работе всего сервера. Если этот файл отсутствует, то его можно создать с помощью любого блокнота. Главное, чтобы название файла было «.htaccess» — без форматов .txt, .doc и т.д.

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

Чуть ниже мы рассмотрим все распространенные варианты редиректов через .htaccess , а для начала ознакомимся с опциями и правилами.

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

Разместите эти строки в самом верху файла .htaccess , чтобы иметь возможность работать с директивами модуля mod_write.

Также на хостинге должны быть включены модули mod_alias (для поддержки Redirect, RedirectPermanent и RedirectMatch).

1. Правила Redirect, RewriteRule и RewriteCond

1.1. Директива Redirect

Redirect устанавливает прямой редирект с одной страницы на другую.

В status пишут код редиректа. Является необязательным параметром. Чаще всего пишут 301, что сигнализирует о постоянном смене адреса страницы.

Важно, чтобы страница «откуда» была прописана в формате без указания полного адреса сайта, но с указанием полного относительного адреса URL начиная со слэша «/» (т.е. с корня сайта). Страницу куда идет редирект нужно писать полностью, т.е. абсолютный адрес страницы URL (т.е. с названием домена и протокола http или https).

Можно также писать по другому

1.2. Директива RewriteRule

Директива RewriteRule устанавливает правила перехода. Синтаксис следующий:

  • При внешнем редиректе меняется урл адреса в строке браузера — » [R=301,L] «
  • При внутреннем — не меняет урл адреса в строке браузера — » [R=301] » или » [L] «

1.3. Директива RewriteCond

Директива RewriteCond определяет условия при котором выполняется правила в RewriteRule.

Например, этими условиями могут быть браузер пользователя, IP-адрес, заголовок и т.д.

1.4. Директива RedirectMatch

Директива RedirectMatch аналогична Redirect с той лишь разницей, что позволяет записывать регулярные выражения.

2. Примеры 301 редиректов в .htaccess

Мы уже рассматривали множество примеров с редиректом по .htaccess в статьях:

Здесь мы дополним варианты редиректов, которых еще не было.

2.1. Редирект с одной страницы на другую

Редирект с site.ru/cat/oldpage на site.ru/newpage.html

Или второй вариант:

2.2. Редирект со всех файлов .htm на .html

Или второй вариант:

2.3. Редирект всего каталога на другую страницу

С любой страницы в каталоге и подкаталогах /old/ будет происходит редирект на /new.php

2.4. Удаление лишних слэшей в адресе URL

Например, страница /catalog///stranica.html доступна и открывается. Чтобы избежать такой ситуации и не плодить бесконечное число дублей следует записать следующий редирект

2.5. Реврайт без редиректа

Можно загрузить другую страницу без смены адреса страницы URL. Например, загрузим страницу /news.html , а в адресной строке будет отображаться адрес /news/happy

2.6. Простановка замыкающего слеша в конце адреса главной страница

Например, многие сервера работают так, что последний слэш не пишется в URL. Например, http://site.ru . Ниже приведенный код решают это проблему: сайт будет открывать по http://site.ru/

2.7. Удаляем директорию каталога из URL

Например для редиректа со страницы site.com/directoriya/stranica.html на site.com/stranica.html нужно прописать следующее:

Или второй вариант:

2.8. Редирект GET параметров

Например, сделать редирект со страницы /?act=page& > на /page-2/

2.9. Редирект на мобильную версию сайта m.site.ru

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

2.10. Редирект с поддомена

Например, выполним редирект с любой страницы поддомена poddomen.site.ru на основной домен site.ru

3.Другие примеры с htaccess

3.1. Запретить IP-адрес и браузер

Запретим открывать сайт для пользователя с браузера IE с IP-адресом 172.111.222.55

3.2. Запретить конкретный файл

Запретим для всех файл disable_file.html :

3.3. Разрешить доступ с одного ip

Доступ будет разрешен только с одного ip-адреса 172.111.222.55

3.4. Запретить доступ с разных ip

Запретить доступ к сайту с нескольких ip-адреса 172.112.222.55, 172.113.222.55, 172.114.*.*

3.5. Редирект в URL с больших символов на маленькие

Все большие буквы в адресе URL будут переведены на маленькие.

Настройка mod_rewrite

Что такое mod_rewrite?

Вспомните последнее посещение интернет-магазина. Найдя нужный товар, вы, вероятно, увидели примерно такой URL:

Это происходит не потому, что разработчики этого сайта потратили уйму времени, чтобы настроить отдельные директории для разных категорий товара, а благодаря удобному модулю по имени mod_rewrite. Данный модуль позволяет создавать пользовательские и упрощенные URL-адреса. На самом деле URL выглядит примерно так:

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

Требования

Для выполнения данного руководства понадобятся привилегии root (чтобы получить более подробную информацию, читайте статью «Начальная настройка сервера Ubuntu»).

Кроме того, нужно предварительно установить apache. Для быстрой установки этого веб-сервера в Ubuntu используйте команду:

sudo apt-get install apache2

1: Включение mod_rewrite

Для начала нужно включить mod_rewrite, это очень просто:

sudo a2enmod rewrite

Данная команда включит модуль или же выведет сообщение «Module rewrite already enabled» в случае если модуль уже включен.

2: Что такое .htaccess?

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

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

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

Создать файл .htaccess можно при помощи текстового редактора, а затем выгрузить его на сайт при помощи ftp-клиента.

Обратите внимание: файл должен называться именно .htaccess; имя файла не должно содержать дополнительных расширений.

В качестве альтернативы можно создать файл .htaccess через терминал при помощи этой команды, заменив example.com доменным именем сайта.

sudo nano /var/www/example.com/.htaccess

Включение файла .htaccess

Чтобы разрешить файлу .htaccess переопределять стандартные настройки сайта, откройте конфигурационный файл.

Примечание: для этого понадобятся расширенные привилегии sudo.

sudo nano /etc/apache2/sites-available/default

В этом файле найдите следующий раздел и измените значение строки AllowOverride (замените None на All). В результате раздел будет иметь такой вид:

Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all

Сохранив изменения и закрыв файл, перезапустите сервер apache. Теперь файлы .htacess доступны всем сайтам сервера.

sudo service apache2 restart

Теперь все готово для переписывания URL-адресов сайта.

3: Переписывание URL-адресов

Вся операция переписывания URL происходит в файле .htaccess. В целом, все команды перезаписи URL-адреса следовать той же схеме:

RewriteRule Pattern Substitution [OptionalFlags]

Опции, использованные в данной команде:

  • RewriteRule: Это раздел, в котором можно задать нужные директивы.
  • Pattern: этот раздел предназначен для интерпретации нужного URL-адреса с помощью регулярных выражений. Это руководство не охватывает регулярные выражения; некоторую полезную информацию по этому вопросу можно найти на сайте Apache.
  • Substitution: отображает фактический URL страницы. Такую ссылку трудно запомнить, поскольку она состоит из параметров PHP или длинных последовательностей цифр, например: www.bestshop.com/gadgets.php?innovation=laptops
  • Optional Flags: флаг представляет собой тег в конце директивы RewriteRule, способный изменить поведение выражения. Некоторые общие флаги: [F] запрещает URL, [NC] игнорирует заглавные буквы, [R = 301] или [R = 302] контролируют используемый код переадресации, [L] говорит о том, что это последнее правило в серии.

Примеры перезаписи URL-адреса

Пример 1: открываете страницу А – попадаете на страницу Б

Это наиболее простой пример перезаписи URL: посетитель сайта вводит в браузер один URL, но перенаправляется на другой. Чтобы настроить такое поведение, следуйте инструкциям этого раздела.

HackWare.ru

Этичный хакинг и тестирование на проникновение, информационная безопасность

Полное руководство по mod_rewrite (часть 5): Частые случаи и примеры использования mod_rewrite

Оглавление. Полное руководство по mod_rewrite

8. Директива RewriteOptions, технические подробности, когда НЕ использовать mod_rewrite

В предыдущих частях мы изучили практически всю документацию по mod_rewrite. Остались директивы RewriteMap и RewriteOptions. RewriteMap также используется для перезаписи URL адресов, но применяется реже других; к ней мы вернёмся позже. Директива RewriteOptions также применяется нечасто. Особенностью RewriteMap является то, что её нельзя использовать в .htaccess. Её можно использовать только в контексте сервера, либо виртуальных хостов. По большому счёту, RewriteMap не добавляет новой функциональности – она только позволяет вынести большой массив данных, которые нецелесообразно или слишком сложно описывать при помощи регулярных выражений, в отдельные файлы. Получаются такие выделенные базы данных. Тем не менее, мы всё равно рассмотрим RewriteMap в одной из последующих частей.

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

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

Проверка доступности mod_rewrite

Как включить RewriteEngine

О включении модуля mod_rewrite в конфигурационном файле Apache было рассказано в первой части. Если модуль включен, то его необходимо активировать в файле .htaccess директивой RewriteEngine:

Это достаточно сделать один раз, даже если вы используете несколько правил перезаписи.

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

Как проверить, включён ли mod_rewrite

Как проверить в PHP включён mod_rewrite или нет

Самым простым способом является использование функции phpinfo(). Если модуль включён, то в таблице apache2handler в колонке Loaded Modules будет указано mod_rewrite (а также все другие модули, которые включены).

Этот способ является самым универсальным: вы можете использовать его в любой системе, в том числе на совместном (shared) хостинге.

Как проверить в Windows включён ли mod_rewrite

Откройте командную строку (Win+x, затем выберите Windows PowerShell). Перейдите в каталог, где размещены бинарные файлы Apache. Например, в моём случае это папка C:\Server\bin\Apache24\bin\:

И выполните там команду:

Будет выведен полный список модулей.

Как проверить в Linux включён ли mod_rewrite

Чтобы вывести список всех загруженных веб-сервером Apache модулей, используется опция -M. Исполнимый файл веб-сервера может называться apache2ctl или httpd в зависимости от используемого дистрибутива.

Для Debian, Ubuntu, Kali Linux, Linux Mint и их производных команда для вывода списка модулей следующая:

Для Arch Linux, BlackArch и некоторых других дистрибутивов команда такая:

Проверка включён ли mod_rewrite с помощью .htaccess

В файле .htaccess запишите директиву:

И попробуйте открыть адрес папки, где вы сохранили .htaccess, если возникнет ошибка «500 Internal server error», значит модуль mod_rewrite не включён в конфигурационном файле Apache.

Как сделать так, чтобы правила перезаписи использовались только если mod_rewrite включен

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

Вместо многоточий запишите желаемые директивы mod_rewrite, пример:

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

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

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

Использование mod_rewrite для перенаправления (редиректа) и переназначения URL

Страница поменяла адрес, как показать новую страницу по старому адресу без редиректа

Предположим, мы недавно переименовали страницу foo.html в bar.html и теперь хотим, чтобы старый URL также работал для обратной совместимости. Однако мы хотим, чтобы пользователи старого URL-адреса даже не узнали, что страницы были переименованы, то есть мы не хотим, чтобы адрес изменялся в их браузере.

Цукерберг рекомендует:  Расширение - Расширение для фреймворка.

Мы с помощью RewriteRule делаем преобразования запроса, содержащего старый адрес, на новый, задав следующее правило:

В этом примере ^/foo\.html$ является регулярным выражением. Символы ^ и $ обозначают начало и конец строки соответственно. Перед точкой стоит слеш, чтобы символ трактовался буквально (как точка), а не как подстановочный символ (в качестве подстановочного символа точка означает любой один символ).

Страница поменяла адрес, как перенаправить на новую страницу при запросе старой (редирект)

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

Мы принудительно перенаправляем HTTP на новый URL-адрес, что приводит к изменению адреса страницы в браузере и, следовательно, того, что показано пользователю:

Кстати, для простых случаев редиректа можно использовать директиву Redirect. Эта директива не смогла бы заменить первый пример, когда мы показываем содержимое другой страницы без смены адреса (без редиректа). С Redirect второй пример выглядел бы так:

Переадресация при смене домена

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

Вы можете использовать mod_rewrite для перенаправления этих URL на новый домен, но также рассмотрите вариант с использованием директив Redirect или RedirectMatch.

В последующих примерах замените example.com на адрес сайта, куда должен выполняться редирект.

Правило означает найти запросы, которые содержат строку, которая начинается с /docs/ (символ ^ означает начало строки, а /docs/ — это буквальная последовательность символов), за которой затем следует что угодно (точка означает любой символ, а знак плюс означает один или более раз). Скобки образуют обратную ссылку. Т.е. то, что совпадает с выражением в скобках, можно использовать в дальнейшем, сославшись на это с помощью $1.

В строке перезаписи http://new.example.com/docs/ является буквальной частью, а $1 – это то, что совпало с частью выражения в скобках, т.е. обратная ссылка на (.+).

Таким образом, если был сделан запрос http://another.com/docs/best, то будет сделана переадресация на адрес http://new.example.com/docs/best.

Директивы Redirect и RedirectMatch должы быть «легче» для сервера, но не всегда сложные случаи можно описать без использования mod_rewrite.

Простой редирект на новый сайт

Если сайт сменил домен и не сохранил структуру страниц, т.е. если вам нужно перенаправить все запросы на новый сайт (например, на его главную страницу), то это делается так:

В результате независимо от запрошенной страницы, все запросы будут переданы на главную страницу другого домена. Замените https://newsite.ru на тот сайт, куда вы перенаправляете запросы.

Как переправить все запросы из одной директории, в другую

Псевдоним для единичной директории:

Все обращения к содержимому директории source-directory будут переадресованы к содержимому директории target-directory.

Использовать URL адресов без расширения файлов .php

Этот снипет позволяет вам использовать URL без расширения PHP, например, example.com/users вместо example.com/users.php.

Универсальный документ ошибки (Error Document) для не найденных ресурсов (ошибка 404 Not Found)

Следующее правило выводит указанный вами файл в случае возникновения ошибки 404 Not Found. Обратите внимание, что вам самим нужно указать правильный код ответа HTTP 404 в заголовках ответа (в PHP коде, например).

Если это правило перезаписи вызовет ошибку сервера, то замените флаг [END] на [L]. Флаг [END] подходит лучше, но поддерживается Apache 2.4 и не поддерживается версией Apache 2.2.

Вместо /dir/error.php нужно указать путь до файла, который вы хотите показывать в случае возникновения ошибки 404 (файл не найден).

Со статики на динамику

Как мы можем трансформировать статичную страницу foo.html в динамичный вариант foo.cgi бесшовным образом, т.е. без уведомления браузера/пользователя.

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

quux/foo.html внутренне приводить к вызову /

Обратная совместимость для изменений расширения файла

Как мы можем сделать обратную совместимость URL (виртуально ещё существующих) после миграции document.YYYY в document.XXXX, например, после перехода ряда.html файлов на .php?

Мы переписываем имя в его базовое имя и проверяем наличие файла с новым расширением. Если он существует, мы берем его, иначе URL используется в исходном состоянии.

В этом примере используется часто забываемая возможность mod_rewrite, вытекающая из порядка выполнения набора правил. В частности, mod_rewrite оценивает левую сторону RewriteRule (Шаблон поиска), прежде чем оценивать директивы RewriteCond. Следовательно, $1 уже определён к тому времени, когда оцениваются директивы RewriteCond. Это позволяет нам проверять наличие исходного (document.html) и целевого (document.php) файла с использованием того же базового имени файла.

Этот набор правил предназначен для использования в контексте директорий (в блоке или в файле .htaccess), так что проверки -f смотрят в каталог по правильному пути. Возможно, вам потребуется установить директиву RewriteBase, чтобы указать базу каталогов, в которой вы работаете.

Замена на WebP изображения

Если поддерживаются WebP изображения, и изображение с файловым расширением .webp найдено в том же месте, где на сервере находится картинка jpg/png, то вместо неё будет отправлено изображение WebP.

Канонические имена хостов и URL. HTTPS

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

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

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

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

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

Как сделать редирект с HTTP на HTTPS

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

В этом примере переменная % содержит on, если сайт использует HTTPS и содержит off, если используется HTTP. Таким образом, адрес страницы переписывается только если к ней обращаются по HTTP.

В RewriteRule в качестве шаблона поиска используется ^ — символ начала строки. Т.е. под это условие подпадают все строки. Цель переадресации указывается с помощью буквальной строки https:// и двух переменных окружения % и % .

Также на вашем HTTPS веб-сайте рекомендуется включить HTTP Strict Transport Security (HSTS) для помощи в предотвращении атак человек-посередине. Для этого достаточно добавить строки:

Как сделать редирект на с HTTP на HTTPS всех страниц кроме некоторых

Предположим, что нам нужно перевести на HTTPS все страницы кроме тех, которые находятся в папке /.well-known/, тогда используется следующая конструкция:

Замените /.well-known/ на желаемую папку или адрес страницы.

Если нужно исключить несколько страниц или каталогов, то составьте регулярное выражение с альтернативным выбором, т.е. с использованием трубы (|). Например, нужно включить переадресацию на HTTPS для всех страниц кроме находящихся в папке /.well-known/, в папке /test/, а также файла /stay-away.php:

Важно : если установлен заголовок Strict-Transport-Security:

То правила с выборочным использованием или не использованием HTTPS для определённых страниц работать НЕ БУДУТ! Веб-браузер, получая этот заголовок, для всего сайта — для всех страниц и даже для всех субдоменов, включает HSTS (HTTP Strict Transport Security). С практической точки зрения это означает, что веб-браузер будет работать только с HTTPS страницами — открывать их сразу по HTTPS протоколу даже если ссылка или редирект указывают на использование HTTP протокол. Аналогичное правило распространяется на субдомены; если сертификат не поддерживает какой-либо субдомен сайта, то такой адрес будет невозможно открыть. Сайт с включённым HSTS невозможно добавить в исключения веб-браузера, чтобы он игнорировал ошибки неправильных SSL сертификатов.

Как сделать редирект на с HTTP на HTTPS только некоторых страниц

Если вам нужно перенаправить с HTTP на HTTPS только отдельные страницы, то подойдут показанные ранее примеры. Единственное необходимое в них изменение – убрать восклицательный знак (!), который служит для отрицания совпадения.

Для настройки редиректа на HTTPS только для папки /.well-known/

Для настройки редиректа на HTTPS только для папки /.well-known/, папки /test/, а также файла /stay-away.php:

Принудительное использование HTTPS за прокси

Полезно, если у вас есть прокси-сервер перед вашим сервером, отключающий TLS.

Всегда использовать WWW перед именем домена

Если вы хотите, чтобы в строке браузера перед названием домена всегда шло www, то используйте следующие правила:

Обратите внимание, что example.com нужно заменить на домен вашего сайта, вместо протокола http:// может быть указано https://, а в строке ^example\.com слеш перед точкой не случаен – эта строка является регулярным выражением, чтобы точка рассматривалась не как подстановочный символ, а как буквальная точка, используется слеш.

Всегда использовать WWW перед именем домена – универсальный вариант

Этот вариант подойдёт без изменений для любых сайтов: не нужно указывать имя хоста (доменное имя), а также не нужно указывать, используется ли протокол HTTP или HTTPS. Т.е. это более универсальный вариант.

Первое условие проверяет, не является ли значение Host пустым (в случае HTTP/1.0). Второе проверяет, не начинается ли Host на www..

Обратите внимание на RewriteCond %s ^on(s)|. Здесь используется довольно хитрый приём. Как было сказано чуть выше, переменная окружения % содержит on, если сайт использует протокол HTTPS, и содержит off, если используется HTTP. К переменной окружения добавлена буквальная буква s, в результате происходит проверка строки %s, которая, в зависимости от того, включен ли HTTPS или нет, может сводиться к ons или offs. Эта строка сравнивается с регулярным выражением ^on(s)|, где ^ — это символ начала строки. Символ трубы (|) говорит о том, что подойдёт любая альтернатива – стоящая перед этим символом или после. Перед этим символом стоит строка on(s), а после – ничего. Пустая строка соответствует любой сравниваемой строке. Исходя из этого, результат RewriteCond всегда будет сводиться к истине. Но в зависимости от того, какая часть регулярного выражения совпала: on(s) или пустая строка, обратная ссылка будет иметь значение «s» или будет пустой строкой. Обратная ссылка задаётся скобками, в которых находится буква s.

В результате http%1 при RewriteRule будет сводиться к https или к http.

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

Никогда не использовать WWW перед именем домена

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

В нём замените http://example.com на имя вашего домена. Также обратите внимание на протокол. Во второй строке слеши используются для того, чтобы точки в регулярном выражении трактовались как буквальные символы (а не подстановочные).

Никогда не использовать WWW перед именем домена – универсальный вариант

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

В этом наборе условий и правила не нужно указывать свой домен – конструкция является универсальной для любого сайта, также подходит для сайтов на HTTP и HTTPS.

Принудительное использование канонического имени с HTTPS и www

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

В этом примере имеются два правила перезаписи. Первое перенаправляет на HTTPS. Второе правило перезаписывает любой запрос с неверным доменом на использование www. Флаг [NC] означает совпадение независимо от регистра.

Четвёртый способ (замените domain.ru на свой домен):

Канонический вид с HTTPS и без www

Если ваш сайт работает на HTTPS, но вы не хотите видеть www в адресной строке браузера перед именем домена, то используйте:

Принудительное SSL и www для главного домена, принудительное SSL без www для всех поддоменов (кроме локальных)

Замените domain.ru на имя вашего домена.

Принудительное добавление конечного слеша к адресу сайта

Если вам нужно добавить к URL конечный слеш (в том случае, если он отсутствует), то воспользуйтесь этим правилом перезаписи:

Удаление конечного слеша

Этот сниппет перенаправит пути, заканчивающиеся на слеши, на аналогичные, но без конечного слеша (кроме действительных директорий), к примеру http://www.example.com/blog/ на http://www.example.com/blog. Это важно для SEO, поскольку рекомендуется иметь канонический URL для каждой страницы.

Если вам нужно убрать из URL конечный слеш, то для этого используйте:

Удаление конечных слешей из произвольных путей

Удаление конечных слешей из URL для веб-сайтов, размещённых в директории (как example.org/blog/):

Удаление лишних слешей в адресе URL

Например, страница /catalog///stranica.html доступна и открывается. Чтобы избежать такой ситуации и не плодить бесконечное число дублей следует записать следующий редирект:

Здесь последовательно используется два правила для того, чтобы удалять многократные слеши из любой части URL: начала, середины, конца.

В первом правиле используется переменная % , она содержит полный запрос, примерно следующего вида:

Для разделения частей запроса в выражениях условий, используется \s, которая означает белые пробелы.

Контроль доступа и блокировка хотлинка

Ограничение доступа по IP

Модуль mod_rewrite умеет переадресовывать, показывать различные страницы или блокировать доступ в зависимости от IP пользователя. Но если вам нужно просто заблокировать доступ для определённых IP, либо разрешить доступ определённым IP, но намного более удобным и лучшим вариантом будет использовать другой модуль, отвечающий за Контроль доступа к сайту (по ссылке подробная инструкция и множество примеров ограничения доступа к папка и отдельным файлам).

Запрет доступа к скрытым файлам и директориям

Скрытые файлы и директории (это те, чьи имена начинаются на точку .), должно в основном, если не всегда, быть защищены от просмотра веб-клиентами. Примеры таких файлов и папок: .htaccess, .htpasswd, .git, .hg

В качестве альтернативы, чтобы запутать атакующего, при попытке открыть такие файлы можно вызвать ошибку «Not Found».

Запрет хотлинка изображений

Хотлинк (англ. hotlink) – включение в веб-страницу файлов-изображений или других ресурсов с чужого сервера.

При использовании следующих правил вам нужно отредактировать домен example.com на имя вашего сайта.

Также при тестировании помните о кэшировании (если оно включено, то изображении некоторое время всё равно будет отдаваться из кэша).

Приведённый выше вариант разрешит отправку изображений при пустом реферере («Blank Referrers»).

Что такое пустой реферер? Некоторые посетители имеют персональные файерволы или антивирусные программы, которые удаляют информацию о реферере (referrer) страницы, которую отправляет ваш веб-браузер. Защита от хотлинка основывается на этой информации. Поэтому если вы выберите запрет отправки изображений пользователям с пустым реферером, то вы заблокируете этих пользователей. Также это не позволит пользователям напрямую получать доступ к изображению, если они набрали его URL в браузере.

Допустим, вы не хотите разрешать «пустой реферер», тогда используйте следующий вариант:

Допустим вы хотите показать изображение в духе «STOP HOTLINKING», тогда используйте следующий метод:

Не забудьте поменять адрес изображения (http://example.com/blocked.png) на свой. Также убедитесь, что это изображение НЕ защищено от хотлинка, в противном случае ваш сервер попадёт в бесконечную петлю.

Запрет хотлинкинга только для определённых доменов

Иногда нужно отключить хотлинкинг изображений только для некоторых плохих парней. Для запрета хотлинка только от определённых доменов, таких как blockurl1.com, blockurl2.com и blockurl3.com, но разрешения любым другим сайтам вставлять ваши изображения:

Вы можете добавить столько различных доменов, сколько вам нужно. Каждая строка RewriteCond должна заканчиваться флагами [NC,OR]. NC означает игнорировать регистр. OR означает логическое ИЛИ, т.е. правило сработает, если совпал этот домен или любой другой. Последний домен в списке идёт без флага OR, поскольку строки RewriteCond заканчиваются.

Последняя строка содержит URL «http://example.com/blocked.gif», который содержит изображение, которое будет показываться когда совпадут перечисленные условия – т.е. сработает запрет хотлинка.

Строка RewriteCond % !blocked\.gif$ [NC] ОТКЛЮЧАЕТ запрет хотлинка для изображения, которое показывается в случае срабатывания правил – это позволяет избежать бесконечного цикла.

Вы можете показывать сообщение об ошибке 403 Forbidden вместо изображения. Для этого замените последнюю строку в предыдущем примере на:

Разрешение хотлинка для определённых сайтов

Чтобы разрешить хотлинк для определённых сайтов, укажите в следующих правилах свой сайт и сайты, которым вы хотите предоставить разрешение на вставку ваших картинок:

Блокировка пользователя по рефереру (Referrer)

Блокировка пользователей на основе ссылающегося домена. Это запрещает доступ для всех пользователей, кто пришёл (отправлен с) определённого домена:

Замените somedomain.com и anotherdomain.com на действительные значения доменов (сайтов), которые вы не любите.

Блокировка плохих ботов, клонеров сайтов, офлайн браузеров

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

Обратите внимание, что список неполный и (возможно), неактуальный. Дополняйте/редактируйте список на основе анализа логов ваших веб-сайтов.

Если вместо блокировки доступа, вы хотите отправлять их на какие-нибудь адские веб-сайты по вашему выбору, то замените последнюю строку на:

Или отправьте их на виртуальную чёрную дыру фальшивых email адресов:

Запрет доступа к файлу или директории в определённые периоды времени

Закрытие доступа в полночь:

Закрытие доступа с 12 до 15 часов:

Следующий набор директив запрещает доступ с 18 часов до 7 часов утра. При попытке посетить сайт в этот промежуток времени, будет выдан ответ 403 Forbidden (флаг [F]):

SEO блог

Рассмотрим пример этих директив, взятый из файла .htaccess для некоторой cms. В качестве справочника будем смотреть на официальное описание работы mod_rewrite.

Options +FollowSymlinks
RewriteEngine On

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

RewriteRule ^\.htaccess$ [F]

Options +FollowSymlinks переопределяет поведение сервера для символических ссылок. Обычно символические ссылки уже разрешены в файле конфигурации сервера httpd.conf, но если это не так, то эта директива необходима для работы mod_rewrite.

Второй строчкой идет «RewriteEngine On». Когда она включена все дальнейшие директивы тоже выполняются, установка ее в off отключает выполнение всех нижележащих директив. RewriteEngine не наследуется и поэтому ее надо включать во всех файлах httaccess, в которых имеются директивы mod_rewrite.

Следующие две директивы перенаправляют запрос с нашему сайту (example.ru), набранный без префикса «www» к нашему же сайту, но с префиксом «www». Флаг [L] в RewriteRule приводит к отказу от обработки следующих RewriteRule, а флаг [R=301] делает внешнее перенаправление с помощью 301 редиректа. «http://www.example.ru» явно указывает префикс перенаправления.

Далее в нашем примере идет директива «RewriteBase /». Такая установка отменяет базу перенаправления по умолчанию — физического адреса директории, где лежит файл htaccess. Tак как физический адрес обычно не совпадает с URL, то она обычно необходима.

Следующая одиночная директива «RewriteRule ^\.htaccess$ [F]» запрещает доступ к файлу, совпадающему с регулярным выражением «^.\htaccess$» с помощью флага [F]. Смысл регулярного выражения в скобках: ^ — начало строки; \. — символ точка, так как точка является специальным символом, то его экранируют; $ — конец строки.


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

Следующая директива «RewriteCond % (.*)/$» разрешает перенаправление для адресов, оканчивающихся на «/».

mod_rewrite в примерах и рекомендациях

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

Мир Вам Братья и Сёстры! По просьбам трудящихся сегодня я здесь типа обучающая программа, которую зовут Олег, и, сегодня мы с Вами попробуем объяснить, самим себе в первую очередь, основные принципы работы чудо-модуля mod_rewrite дабы иметь отчётливое понимание как работают условия и правила, а не просто тупо их копировать/вставлять. Итак, начнём.

Модуль Apache mod_rewrite является очень мощным, но в то же время сложным, инструментом для манипуляции с URL перенаправлениями/преобразованиями/запретами. С помощью этого чудо-модуля можно выполнять практически любые URL преобразования/манипуляции на стороне сервера.

Обратите внимание, что для некоторых манипуляций с URL не требуется такой мощный и сложный (особо для начинающих) модуль как mod_rewrite. Для простых задач можно использовать mod_alias. Под словом «мощный» имеется ввиду не только широкие возможности по преобразованию URL-ов, но и повышенный расход ресурсов сервера в сравнении с другими модулями.

Регулярные выражения mod_rewrite

mod_rewrite использует Perl Compatible Regular Expression (PCRE — Perl совместимые регулярные выражения). В этой статье, мы не будем подробно описывать использование регулярных выражений имхо этой теме посвящены целые тома книг и в одной статье нельзя охватить данную тематику.

Для большего понимания механизмов PCRE рекомендую запастись какой-то книгой, например » Книга Джеффри Фридла «Регулярные выражения» «, или как минимум ознакомьтесь с материалами по ссылкам:

Главное, что нужно помнить, — это то, что в регулярных выражениях используются специальные символы (метасимволы) и обычные символы (литералы). Основными метасимволами являются [ ] \ / ^ $ . | ? * + ( ) < >. Метасимволы всегда нужно экранировать обратным слэшем «\», — это относится к пробелу («\ «), а также тому же обратному слэшу («\\»).

Цукерберг рекомендует:  Так почему Google невзлюбил NPAPI

Нужно помнить, что mod_rewrite использует оригинальный PCRE (Perl совместимые регулярные выражения), но с некоторыми дополнениями:

  • ‘ !Условие ‘ (несоответствие условию)
  • ‘ ‘ (лексически меньше условия)
  • ‘ >Условие ‘ (лексически больше условия)
  • ‘ =Условие ‘ (лексически равно условию)
  • ‘ -d ‘ (является ли каталогом)
  • ‘ -f ‘ (является ли обычным файлом)
  • ‘ -s ‘ (является ли обычным файлом с ненулевым размером)
  • ‘ -l ‘ (является ли символической ссылкой)
  • ‘ -F ‘ (проверка существования файла через подзапрос)
  • ‘ -U ‘ (проверка существования URL через подзапрос)

Порядок обработки правил mod_rewrite

Порядок обработки правил mod_rewrite является далеко не очевидным. Правила mod_rewrite составляются примерно в таком порядке:

Теперь чуть подробнее:

  • RewriteEngine — должна быть одна;
  • RewriteBase — может пригодится при использовании в правилах относительных ссылок, но если относительные ссылки относятся к корню каталога, то данная директива может не использоваться, теоретически может использоваться многократно перед каждым из правил;
  • RewriteCond — условие, которое должно быть соблюдено перед выполнением правила, условий может быть несколько;
  • RewriteRule — собственно само правило, которое выполняется при соблюдении условия.

Порядок размещения правил .htaccess важен потому что механизм преобразований обрабатывает их в специальном порядке. Строчка за строчкой сначала просматриваются RewriteRule директивы и при соответствии URL шаблону (Pattern, исходный_url) конкретного правила проверяются условия (RewriteCond директивы) относящиеся к этому правилу. Условия (RewriteCond) всегда должны быть перед правилами (RewriteRule)! На рис. ниже показан порядок обработки правил mod_rewrite.

Как видно, Текущий URL сначала сравнивается с Шаблон правила и при совпадении с шаблоном проверяет условия, если Текущий URL удовлетворяет условиям, то к нему применяется правило и Преобраз. URL идёт дальше на обработку если не указан флаг [L] (last).

Флаг [L] нужно использовать для каждого правила, разумеется если дальнейшая трансформация URL не требуется.

Далее директива » RewriteEngine on » не будет упоминаться в примерах, — т.е. будем подразумевать, что она уже была добавлена ранее и в дальнейшем дублировать её мы не будем.

Переменные mod_rewrite

В условиях (RewriteCond) и в правилах (RewriteRule) можно использовать переменные сервера.

1. HTTP headers (RqH — Request Header):

  • HTTP_USER_AGENT — содержит полную строку заголовка «User-Agent:»;
  • HTTP_REFERER — адрес с которого пришел пользователь;
  • HTTP_COOKIE — доступ к списку COOKIE браузера;
  • HTTP_FORWARDED — содержит IP-адрес прокси-сервера или сервера балансировки нагрузки;
  • HTTP_HOST — адрес хоста/сервера, который запросил пользователь, например, example.com;
  • HTTP_PROXY_CONNECTION — содержит лексему соединения (connection-token) «close» или «Keep-Alive», предназначен для согласования постоянных соединений между клиентом и сервером (аналог заголовка Connection);
  • HTTP_ACCEPT — заголовок согласования содержимого, которое поддерживает браузер/клиент пользователя, например » text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 » («тип/подтип», через запятую, где тип – это тип содержимого, а подтип – это уточнение типа.). Если заголовок Accept содержит » Accept: */* » (*/*), то это означает, что клиент готов принять содержимое любого типа.

2. connection & request (соединение & запрос):

  • REMOTE_ADDR — IP-адрес клиента;
  • REMOTE_HOST — ДНС-имя IP-адреса клиента;
  • REMOTE_PORT — номер текущего порта клиента;
  • REMOTE_USER — содержит имя авторизированного (средствами сервера) пользователя;
  • REMOTE_IDENT — переменная будет установлена только если подключен модуль mod_ >REQUEST_METHOD — метод, которым был сделан запрос, GET|GET|HEAD и т.д.;
  • SCRIPT_FILENAME — полный путь к запрошенному файлу, например /var/www/public_html/script_name.php;
  • PATH_INFO — Содержит предоставленный пользователем путь, который содержится после имени скрипта, но до строки запроса (?). Например, если скрипт был запрошен по URL http://www.example.com/php/path_info.php/some/stuff?foo=bar, то переменная $_SERVER[‘PATH_INFO’] будет содержать /some/stuff.
  • QUERY_STRING — строка GET запроса, если запрошен адрес http://example.com/index.php?var=1&var=2, то QUERY_STRING будет содержать var=1&var=2; AUTH_TYPE — тип аутентификации, если выполнена HTTP-аутентификация, может быть Basic или Digest.

3. server internals (внутренние сервера):

  • DOCUMENT_ROOT — полный путь к домашнему каталогу пользователя, например /var/www/public_html/
  • SERVER_ADMIN — данные администратора сервера/виртуального_хоста, обычно адрес электронной почты;
  • SERVER_NAME — имя сервера, обычно из директивы ServerName;
  • SERVER_ADDR — IP-адрес сервера;
  • SERVER_PORT — порт сервера;
  • SERVER_PROTOCOL — версия используемого протокола, например HTTP/1.0 или HTTP/1.1;
  • SERVER_SOFTWARE — название/версия сервера.

4. date and time (системные, дата и время):

  • TIME_YEAR — год, 2014
  • TIME_MON — месяц, 05
  • TIME_DAY — день, 07
  • TIME_HOUR — час, 04 (24)
  • TIME_MIN — минуты, 38
  • TIME_SEC — секунды, 55
  • TIME_WDAY — день недели, 3 (среда)
  • TIME — в формате год-мес-день-час-мин-сек, например 20140514234534

5. specials (специальные):

  • API_VERSION — в формате «20051115:33»
  • THE_REQUEST — подробности GET/POST запроса, например «GET /index.html HTTP/1.1»
  • REQUEST_URI — относительный УРЛ запроса «/index.html»
  • REQUEST_FILENAME — полный локальный путь к файлу или скрипту в файловой системе, соответствующего запроса
  • IS_SUBREQ — если выполняется подзапрос, то переменная содержит true, в противном случае false
  • HTTPS — on/off, если используется/неиспользуется HTTPS

6. переменные результата выполнения:

  • $1 — $1, $2 и т.д. образуются при совпадении (шаблона1.*) (шаблона2.*) из RewriteRule
  • %1 — %1, %2 и т.д. образуются при совпадении (шаблона1.*) (шаблона2.*) из RewriteCond

Дополнительные ссылки по HTTP заголовкам и переменным сервера:

Флаги mod_rewrite

Для управления поведением условий (RewriteCond) и правил (RewriteRule) в mod_rewrite используются флаги [флаги] .

Более подробно о флагах читаем в оригинале:

Протоколы разрешённые в mod_rewrite

mod_rewrite будет определять подстановочный УРЛ как внешний если указаны один из протоколов:

  • ajp:// — Apache JServ Protocol
  • balancer:// — Apache Load Balancer
  • ftp:// — File Transfer Protocol
  • gopher:// — Gopher (protocol)
  • http:// — Hypertext Transfer Protocol
  • https:// — Hypertext Transfer Protocol Secure
  • ldap:// — Lightweight Directory Access Protocol
  • nntp:// — Network News Transfer Protocol
  • ldap: — Lightweight Directory Access Protocol
  • mailto: — The mailto URI scheme
  • news: — News Protocol

.htaccess и порядок размещения правил

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

  1. CORE директивы;
  2. Конфигурация модулей.

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

Примеры mod_rewrite правил

Запрет доступа с помощью mod_rewrite

1. Запрещаем посещать наш веб-сайт в рабочее время:

Это правило закроет доступ с 8-и вечера и до 7-и утра. Приведённый выше пример специально для любителей копи/пасты содержит преднамеренную ошибку в синтаксисе, HTTP 500 (ошибка сервера), которая повлечёт запись в логе ошибок RewriteRule: bad flag delimiters . Переводится, как плохой разделитель флагов, — вместо [ F ] нужно использовать [F] , т.е. избегать пробелов и прочих разделителей, кроме запятой!

2. Наглухо запрещаем боту WBSearchBot трогать наш сайт:

Хотя, немного подправив правило, можно т.с. перевести стрелы на кого-то ещё, так сказать натравить бота на другой сайт, мол . ты что, офонарел!? Иди тренируйся, вон, на нём. :)) (из Х/Ф Операция «Ы» и другие приключения Шурика):

WBSearchBot (Mozilla/5.0 (compatible; WBSearchBot/1.1; +http://www.warebay.com/bot.html)) довольно агрессивный бот и от него можно смело избавляться.

3. Запрещаем POST запросы для старых протоколов:

В предыдущем примере код ответа 303 See Other указан не случайно, — дело в том, что если метод перенаправления (обычно GET) отличается от метода запроса (например POST), то в случае возврата кодов ответа 301-302 вместо автоматического редиректа в браузер будет выдана страница со ссылкой для ручного перехода по ней! В случае же с ответом 303 See Other перенаправление выполняется автоматически методом GET независимо от метода запроса.

4. Hotlink protection — запрещаем отображение наших изображений с других сайтов:

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

1. Перенаправляем запрос к сайту http://example.com/ (без www префикса) на http://www.example.com/ (с www префиксом):

2. Перенаправляем наши RSS/ATOM ленты на FeedBurner

Обратите внимание, что в конце каждой ссылки в правилах (RewriteRule) стоит символ «?», — он требуется для того, чтобы в конец ссылки, по которой будет перенаправлен запрос, не добавлялись параметры QUERY_STRING! если не указать символ «?», то в итоге перенаправление будет по адресу http://feeds.feedburner.com/remote-shaman-blog?option=com_content&view=featured&Item > и http://feeds.feedburner.com/remote-shaman-forum?format=feed соответственно.

Итоги

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

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

Руководство по настройке htaccess (переадресации, ЧПУ) для SEO

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

В сравнении с расширениями для CMS-систем (к примеру, плагины для WordPress), использование прямых указаний в htaccess имеет ряд неоспоримых преимуществ. Перечислим основные из них:
1. Уменьшение нагрузки на MySQL. SEO-дополнения регулярно обращаются к базе данных, так как именно там сохраняется информация о текущей конфигурации. В то же время, редиректы через htaccess функционируют на уровне сервера — их использование ощутимо повышает общую производительность проекта.
2. Работа в условиях ограниченного доступа. Файл дополнительной конфигурации позволяет задавать параметры для отдельных каталогов. Благодаря ему можно осуществлять тонкую настройку даже в том случае, если ресурс размещен на шаред-хостинге и непосредственная работа с httpd.conf невозможна.
3. Дополнительная защита. В отличие от robots.txt, директивы, прописанные в htaccess обязательны к исполнению Apache. Это обеспечивает эффективное управление индексацией, а также защиту системы от спам-ботов и сканеров.

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

Базовые возможности htaccess

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

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

ErrorDocument ошибка /errors/ошибки.html

Например:
ErrorDocument 404 /errors/404.html

Наиболее распространенные ошибки:
403 — запрет на доступ к файлу/странице
404 — запрашиваемый документ/ссылка отсутствует, либо не корректный URL.
500 — внутренняя ошибка сервера.

2. Запрет просмотра для определенных User-Agent
Абсолютно каждое интернет-приложение, будь то браузер или поисковый робот, имеет особый идентификатор — User-Agent. Зная его значение, можно заблокировать нежелательные программы. В СЕО указанный прием используется для запрета индексации и защиты от различных сканеров. Также можно весьма эффективно противостоять спаммерам. Переадресация htaccess такова:

RewriteEngine on RewriteBase / RewriteCond % ^ SpamBot_1 [OR] RewriteCond % ^ SpamBot_2 RewriteRule ^.*$ — [F]

Выше мы запретили доступ к площадке условным спам-ботам 1 и 2. При попытке сканирования, будет выводиться стандартная 403 ошибка.
Примечание: указанная выше методика, несмотря на все преимущества, имеет один недостаток — требуется знать User-Agent утилиты, которую вы хотите запретить. Спамеры стараются обойти подобную защиту, оставляя его пустым, либо размещая там случайную информацию. Противодействовать вредоносным программам в этом случае можно с помощью такого кода:

RewriteEngine On RewriteCond % ^$ [OR] RewriteCond % ^.*( |’|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR] RewriteCond % ^.*(HTTrack|clshttp|archiver|loader|email|nikto|miner|python).* [NC,OR] RewriteCond % ^.*(winhttp|libwww\-perl|curl|wget|harvest|scan|grab|extract).* [NC] RewriteRule ^(.*)$ — [F,L]

Запись позволяет отфильтровывать пустые и подозрительные User-Agent, а также сканеры, использующие наиболее популярные методы парсинга веб-сайтов.

3. Запрет хотлинков
Термин “хотлинк” обозначает подключение к веб-странице файла (чаще всего, изображения), расположенного на сторонних ресурсах. Мало того, что у вас, фактически, воруют контент — при этом создается еще и дополнительная нагрузка на проект. Бороться с этим можно, настроив в htaccess проверку переменной HTTP_REFERER. Если ее значение не совпадает с именем сервера, на котором размещен оригинал, изображение будет подменяться “заглушкой” (например, картинкой с вашим копирайтом):

# Проверка HTTP_REFERER RewriteEngine On RewriteCond % !^$ RewriteCond % !^http://(.+\.)?tekseo\.su/ [NC] # Замена запрашиваемого файла картинкой с копирайтом RewriteCond % !copyright\.gif$ [NC] RewriteRule \.(jpg|jpeg|gif|bmp|png)$ https://tekseo.su/images/copyright.gif [L]

4. Технические работы
Если планируются глобальные изменения (редизайн, или добавление нового функционала), возникает необходимость установки “заглушки”. Штатные средства большинства движков закрывают сайт для всех, что весьма неудобно. Однако настроенный через htaccess редирект позволяет оставить проект доступным администратору, в то же время демонстрируя посетителям страницу с информацией о технических работах:

RewriteEngine On # Вносим в исключения свой IP, а также внутренний адрес сервера. RewriteCond % !Ваш_IP RewriteCond % !127.0.0.1 # Переадресуем на заглушку хосты, переходящие куда-либо, кроме maintenance.php. RewriteRule !maintenance.php$ http://www.tekseo.su/maintenance.html [L,R=307]

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

В первую очередь, стоит разобраться с файлами, которые практически никогда не изменяются (изображения, документы pdf, doc, видео):

Header set Cache-Control «max-age=29030400, private»

Здесь для файлов с перечисленными расширениями мы установили заголовок Cache-Control, задав срок хранения в 1 год через переменную max-age. Вы можете уменьшить данный интервал, однако учтите — время задается в секундах. Private указывает, что кэширование необходимо осуществлять только на стороне пользователя, минуя прокси.

Правило для скриптов, стилей, xml лучше всего прописать отдельно, снизив время до пары дней:

Header set Cache-Control «max-age=172800, private»

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

Header unset Cache-Control

Также можно задать период в 30-60 секунд (это практически не создаст проблем посетителям, однако поможет снизить нагрузку на Апач в прайм-тайм).

6. Управляем индексированием
Поисковики склонны своевольничать, не оглядываясь на инструкции robots.txt. Особенно часто этим грешит Google, способный проиндексировать даже закрытую страницу, перейдя на ресурс по внешнему линку. Частично проблема решается через мета-тег robots, вот только его можно указать лишь для html-документа. Если же от цепких лап «паука» требуется скрыть файл, стоит обратиться к htaccess, благо X-Robots-Tag поддерживает все существующие директивы индексирования:

Header set X-Robots-Tag “index, nofollow, noarchive, nosnippet”

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

7. Сообщаем Гуглу о мобильной версии сайта
Если веб-ресурс генерирует различный код в зависимости от устройства пользователя, с которого осуществляется просмотр, а ссылки при этом не меняются, велик риск попасть под санкции Google (такое поведение может расцениваться как попытка подмены контента). Неприятностей можно избежать, прописав строчку:

Header append Vary User-Agent

Данная запись сообщает, что содержимое страницы варьируется в зависимости от User-Agent.

Настройка постоянного редиректа

Код состояния HTTP 301 указывает на то, что запрошенный документ навсегда сменил адрес, а текущий URL следует считать устаревшим. Это позволяет не только перенести весь заработанный вес (в том числе: Траст, PR, ТИЦ), но и автоматически переправить пользователя на корректную страницу.

1. Со старого URL на новый
Самая простая переадресация htaccess может быть задана с помощью директивы Redirect, используемой модулем Apache — mod_alias. Выглядит запись таким образом:

Redirect 301 /old-page.html https://tekseo.su/new-page.html

Преимущество способа заключается в простом синтаксисе, недостаток — в том, что для перенаправления большого количества устаревших адресов, придется вручную прописывать каждый. Если же их число составляет десятки и сотни, лучше всего использовать mod_rewrite, который позволяет задавать redirect посредством регулярных выражений. Такой подход открывает широчайшие возможности для управления URL, в том числе создавать ЧПУ из автоматически сгенерированных ссылок. Для использования этого метода необходимо активировать (т.е. прописать в htaccess) не только сам модуль, но и опцию FollowSymLinks:

Options +FollowSymLinks RewriteEngine On # Размещаемый код редиректа

2. Склейка домена с www и без www
Можно сказать, что это — основы технического SEO, ведь именно данные правила помогают исключить множественные дубли контента и объединить вес входящих ссылок. Существует два различных решения, одно из которых привязано к конкретному домену, другое же является универсальным. Чем именно воспользоваться — дело вкуса. Синтаксис таков:

а) Переадресация домена с префиксом www на домен без www

RewriteCond % ^www.tekseo\.su$ [NC] RewriteRule ^(.*)$ https://tekseo.su/$1 [R=301,L]

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

б) Перенаправление домена без префикса www на домен с www

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

То же самое, но без привязки к домену:

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

3. Лишние слэши и тире
Весьма распространенная болезнь CMS — доступность сайта по адресам со знаком «/» на конце и без. Проблему также способен решить 301 redirect в htaccess, причем возможны два варианта:

а) Если вы желаете получить URL вида https://tekseo.su, необходимо прописать:

б) Если, напротив, требуется получить линки в формате https://tekseo.su/, то:

RewriteBase / RewriteCond % !-f RewriteCond % !(.*)/$ RewriteRule ^(.*[^/])$ $1/ [L,R=301]

Помимо этого, может наблюдаться появление лишних слэшей или тире (например, https://tekseo.su/category///page—1.html). 301 редирект в htaccess выглядит:

#Избавляемся от слэшей RewriteCond % ^(.*)//(.*)$ RewriteRule . %1/%2 [R=301,L] #Удаляем дополнительные тире RewriteCond % ^(.*)—(.*)$ RewriteRule . %1-%2 [R=301,L]

4. Избавляемся от index.php и index.html
Другая ситуация — дублирование урлов с index.php на конце. Побороть ее можно с помощью пары строчек:

RewriteCond % ^[A-Z]<3,9>\ /index\.php\ HTTP/ RewriteRule ^index\.php$ https://tekseo.su/ [R=301,L]

Выше задан redirect 301 в htaccess для homepage. Аналогичным образом можно удалить index.php для любой другой категории:

RewriteCond % ^[A-Z]<3,9>\ /category/index\.php\ HTTP/ RewriteRule ^index\.php$ https://tekseo.su/category/ [R=301,L]

5. Меняем домен
Если сайт переименован, стоит задать глобальную переадресацию. Сделаем перенаправление с tekseo.su и www.tekseo.su на http://new-tekseo.su/

RewriteCond % ^www\.tekseo\.su$ [NC] RewriteRule ^(.*)$ http://new-tekseo.su/$1 [L,R=301] RewriteCond % ^tekseo\.su$ [NC] RewriteRule ^(.*)$ http://new-tekseo.su/$1 [L,R=301]

6. Склейка доменов
При использовании алиасов, дабы исключить появление дублей, осуществляется склейка доменов. Сделать это можно посредством robots.txt, указав поисковым роботам основное зеркало, однако перенаправление является более надежным методом. Здесь задан редирект с tekseo.com и www.tekseo.com на tekseo.su:

RewriteCond % ^tekseo.com$ [OR,NC] RewriteCond % ^www.tekseo.com$ [NC] RewriteCond % !^/robots.* RewriteRule ^(.*)$ https://tekseo.su/$1 [R=301,L]

7. 301 редирект ссылки с GET-параметром на другую динамическую
Достаточно нетривиальная задача, подобная необходимость может возникнуть при обновлении модулей, или радикальной переработке структуры размещенного контента. Разберем на следующем примере — ссылку вида /?option=mod_articles&page >

Другой случай из разряда казуистики: установив SEF-модуль на свой сайт, вы можете обнаружить, что он конфликтует с некоторыми расширениями, заботливо удаляя параметры из сгенерированных урлов. Если в целом новая система полностью вас устраивает, от нее не обязательно отказываться — достаточно прописать переадресацию в htaccess, передавая часть URL в виде GET-запроса (проще говоря, подставить вопросительный знак в нужное место ссылки):

RewriteCond % ^/parametеr$ RewriteRule ^(.*)$ http://site.com/?$1 [R=301,L]

Здесь мы сделали подмену исходного статического адреса http://www.tekseo.su/parametеr на динамический http://www.tekseo.su/?parametеr.

Формирование ЧПУ на уровне сервера

Создание человекопонятных урлов — одна из ключевых задач технической оптимизации веб-ресурсов. В отличие от примеров, приведенных выше, универсального рецепта здесь не существует. Прописывание автоматических ЧПУ в htaccess требует знания регулярных выражений. В нашем случае они будут использоваться для обнаружения тех или иных фрагментов ссылок и последующей их замены/удаления с целью получения SEF-конструкций. Для грамотного их построения применяются знаки препинания и специальные символы:
“^” — циркумфлекс, начало строки;
“$” — доллар, конец строки;
“.” — точка, любой единичный символ;
“*” — звездочка, любое количество символов, расположенных после указанного знака. Самостоятельно практически не используется;
“.*” — точка и звездочка, любое число любых символов;
“+” — плюс, аналог звездочки, однако предшествующий ему символ должен присутствовать хотя бы один раз;
“?” — знак вопроса, указывает, что стоящая перед ним конструкция (будь то единственный символ или группа) может отсутствовать (например, редирект 301 в htaccess, содержащий ^/page_1/?$ будет работать независимо от того, есть на конце слэш или нет);
“()” — круглые скобки, выделяют некую последовательность (запись формата (.*) обозначает группу из любого количества случайных знаков);
“[]” — квадратные скобки, любой указанный символ (^[0-9] будет означать, что в начале строки может располагаться случайная цифра от 0 до 9);
“<>” — фигурные скобки, указывают, сколько раз встречается символ или их сочетание (так, выражение [a-z] <3>значит, что строчные буквы латинского алфавита могут встречаться три раза);
“|” — вертикальная черта, логический оператор “or” (или), задает несколько условий (например, можно перечислить вероятные расширения файлов (jpg|jpeg|gif|bmp|png));
“\” — обратный слэш, служит для экранирования служебных знаков, если они являются предметом поиска (то есть, сочетание «\.» означает, что точка — значимый символ).

Еще одна важная деталь — флаги, идущие после кода htaccess redirect и заключенные в квадратные скобки. Нас интересуют следующие:

L — останавливает преобразования адреса сразу после выполнения строчки;
R= — определяет тип редиректа, если значение не указать, сервер по умолчанию выдаст код 302 (перемещен временно);
NC — независимо от регистра, позволяет обрабатывать урлы с заглавными и строчными буквами одним и тем же правилом;
S= — указывает количество правил, которые нужно пропустить;
N — сигнализирует о необходимости перезапуска, при этом обрабатывая результат предыдущего преобразования;
F — выводит ошибку 403 (доступ запрещен).

Цукерберг рекомендует:  Html - Как сделать верстку с динамическими блоками

Теперь осталась самая малость — изучить директивы, переменные окружения Apache и опции, после чего вы сможете создавать редиректы htaccess самостоятельно. Строго говоря, из директив требуется знать только две основные:
RewriteCond — посредством нее задаются условия, при которых выполняется соответствующее правило;
RewriteRule — применяется собственно для задания перенаправления.

Из всего обилия переменных окружения наиболее часто употребляются следующие:
REQUEST_FILENAME (или SCRIPT_FILENAME) — полный путь к файлу, соответствующий текущему запросу;
REQUEST_URI — путь, прописанный в HTTP-запросе;
QUERY_STRING — GET-параметры.

Опции же пригодятся такие:
-d — проверка, ведет ли заданный путь к каталогу;
-f — проверка, является ли имя файлом;
-s — действует аналогично f, однако также проверяет размер файла (он должен быть больше 0).

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

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

В заключении стоит разобрать еще один крайне важный момент — работу с RewriteRule. Данная директива позволяет создавать собственные переменные, что существенно упрощает работу с ЧПУ в htaccess. Для этого используются конструкции $1, $2, $3 и т.д. (а также %1, %2, %3), где цифра обозначает место расположения в строке. Но в чем же разница между $1 и %1? $1 используется для подстановки значений внутри самого правила RewriteRule, а %1 забирает таковое из условия RewriteCond.

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

Это можно сделать буквально в одну строчку:

RewriteRule ^articles/([A-Za-z0-9-]+)/(.+)/([0-9]+).html$ index.php?cat=$1&subcat=$2&page=$3 [L]

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

Им соответствуют следующие регулярные выражения:
$1=([A-Za-z0-9-]+) — здесь мы указали, что последовательность может содержать цифры, заглавные и строчные буквы латиницы, а также тире;
$2=(.+) — второй блок может содержать любой символ;
$3=([0-9]+) — третий, только цифры.

Если заданные условия соблюдены, происходит подстановка соответствующего значения GET-параметра, из них и формируется SEF-линк.

Переменную %1 проиллюстрируем на примере рассмотренного выше универсального редиректа на домен без www. Здесь с помощью %1 мы подставляем значения, заданные в RewriteCond.

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

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

Понимание регулярных выражений дает возможность задавать редиректы через htaccess практически любой сложности. Зная синтаксис, можно создавать правила для SEF-адресов независимо от типа и особенностей системы управления контентом. Давайте же теперь разберем различные варианты подобного кода:

1. Удаление технических категорий
Исключение из ссылки ненужных элементов позволяет сократить ее длину. Многие движки создают древовидные структуры документов, добавляя в URL служебную информацию (например, “category” в WordPress). В итоге урлы становятся чересчур громоздкими, принимая вид https://tekseo.su/category/articles/page_1.html. Данную проблему можно решить с помощью специализированных плагинов, либо прописав ЧПУ в htaccess. Последнее также пригодится владельцам самописных ресурсов, не поддерживающих SEO функционал. Для указанного примера правило будет выглядеть следующим образом:

RewriteRule ^category/(.+)$ https://tekseo.su/ [R=301,L]

На выходе мы получим: https://tekseo.su/articles/page_1.html

2. Преобразование динамических ссылок в ЧПУ
Весьма плохо обстоят дела с динамическими ссылками, представляющими собой адрес исполняемого скрипта и GET-параметр, который ему передается. В этом случает исходный урл содержит знак вопроса, что осложняет процесс создания редиректа. Apache обрабатывает их следующим образом: все, что находится до “?” воспринимается как URl, все, что после — становится параметром, передаваемым скрипту. Чтобы перенаправление сработало верно, обработку нужно разбить на две части. В зависимости от местоположения знака, возможны варианты:

а). Знак вопроса находится после названия файла (например, https://tekseo.su/index.php?cat_ >

б). Если же вопросительный знак идет сразу после слэша (например, https://tekseo.su/pages/?cat_ >

Автоматизировать процесс перезаписи можно, используя переменные. Тогда конструкция становится даже более наглядной. Усложним предыдущий пример. Предположим, у нас есть ссылка https://tekseo.su/index.php?cat_ >

RewriteRule ^articles/(.+)/(.+).html index.php?cat_ >

Особое применение 301-го редиректа

В заключении разберем нестандартные варианты использования hypertext access.

1. Работа с кириллическими доменами
Специфических особенностей работы с зоной .рф не существует, но проблема в том, что htaccess не поддерживает кириллицу. Поэтому перед тем, как прописывать настройки, необходимо преобразовать имя сайта в punycode. Сделать это можно посредством специальных конвертеров, либо воспользовавшись сервисом whois.

Давайте зададим перенаправление запросов с tekseo.su на тексео.рф:

RewriteEngine on RewriteCond % ^www\.tekseo.su [NC] RewriteRule ^(.*)$ http://xn--e1aaornd.xn--p1ai /$1 [R=301,L]

2. Подмена внешней ссылки на внутреннюю
Достаточно остроумный способ, позволяющий сделать урл, ведущий на сторонний ресурс, внутренним в глазах поисковых роботов. Представим ситуацию: вы хотите поставить на своем сайте линк на профиль ВКонтакте http://vk.com/id12345. Чтобы скрыть его от глаз роботов, можно воспользоваться атрибутом nofollow, либо создать мнимую страницу “my_social”, добавив следующее:

RewriteEngine on Redirect 301 https://tekseo.su/my_social http://vk.com/vk_id12345

Формально ссылка останется внутренней, при этом пользователи ресурса ничего не заметят.

3. Редирект с прописных на строчные буквы
Одна из распространенных проблем многих CMS — появление дублей страниц, начинающихся с прописных и строчных букв (например, tekseo.su/Page1 и tekseo.su/page1). 301 редирект в htaccess способен справиться и с этой задачей, причем обработка будет происходить в автоматическом режиме и вам не придется описывать перенаправление вручную для каждого URL. Решение таково:

RewriteEngine On RewriteRule [A-Z] — [E=HASCAPS:TRUE,S=1] # Пропускаем секцию, если заглавные буквы отсутствуют. RewriteRule ![A-Z] — [S=28] # Замена букв латинского алфавита с A-Z на a-z. RewriteRule ^([^A]*)A(.*)$ $1a$2 . RewriteRule ^([^Z]*)Z(.*)$ $1z$2 # Запускаем повторный обход, если имеются еще заглавные буквы. # В конце добавляем постоянный редирект htaccess. RewriteRule [A-Z] — [N] RewriteCond % TRUE RewriteRule ^/?(.*) /$1 [R=301,L]

4. Каноничные адреса для файлов
12 февраля 2009 года Гугл аннонсировал поддержку тега rel=”canonical”. Одновременно о работе с атрибутом заявили Yahoo и Bing, а в настоящее время канонические ссылки распознают практически все крупные поисковики. С помощью него можно указать, какая из копий веб-документа является исходной, передав оригиналу значения тИЦ, PR и т.д.

Чтобы задать rel=”canonical”, его необходимо прописать внутри тега соответствующей страницы:

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

Header add Link ‘ ; rel=”canonical”‘

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

RewriteRule ([^/]+).pdf$ – [E=FILENAME:$1] Header add Link ‘ ; rel=”canonical”‘

5. Запрещаем воровство статей ВКонтакте
В процессе борьбы с дублями контента вы можете обнаружить ссылки такого вида: http://www.tekseo.su/page-name.html&post=-123_456. Эта проблема связана с наличием плагина социальных сетей, а именно — кнопкой ВКонтакте. Когда кто-либо решает поделиться очередной статьей на стене, в паблике или группе, автоматически генерируется подобный адрес. И все бы ничего, но такие урлы «на ура» индексируются поисковиком Google. Чтобы это предотвратить, достаточно добавить в htaccess следующее:

RewriteEngine On RewriteCond % ^(.*)\&post= RewriteRule ^(.*)\&post=(.*)$ $1 [R=301,L]

Как видно, потенциал hypertext access чрезвычайно высок. Его грамотное использование позволяет решать абсолютное большинство задач технической оптимизации, используя нативные модули сервера. Что немаловажно, благодаря этому можно отказаться от программных “костылей”, получая дополнительные выгоды, в числе которых повышение производительности и защищенности курируемого проекта.

Примеры URL преобразований

Полная поддержка директив .htaccess прилагается.

Пролонгации домена 199-00 руб

Правила преобразования ссылок:

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

При наличии в файле .htaccess каких либо директив модуля mod_rewrite не наследуется ничего, а состояние по умолчанию выставляется таким же, как в главном конфигурационном файле веб-сервера (по умолчанию «off»). Поэтому, если нужны правила преобразования для конкретного каталога, то нужно еще раз вставить директиву «RewriteEngine on» в .htaccess для конкретного каталога.

При наследовании правил из верхних каталогов и добавлении к ним новых свойственных только данному каталогу — необходимо выставить в начале следущее: «RewriteEngine on» и «RewriteOptions inherit» — последняя директива сообщает серверу о продолжении.

Для того что бы склеить веб-домен

Для того что бы избавиться раз и навсегда от www, и склеить домен без www (http://htaccess.net.ru т.е. в адресной строке больше ни когда не будет домена с www — http://www.htaccess.net.ru), нужно использовать следующий код:

RewriteCond % ^www\.htaccess.net.ru [NC]

RewriteRule ^(.*)$ http://htaccess.net.ru/$1 [R=301,L]

Htaccess перенаправление — редиректом 301 — «документ перемещен навсегда» с легкостью решает эту задачу.

Что бы сделать наоборот — склеить сайт без www (http://htaccess.net.ru), с www (http://www.htaccess.net.ru — т.е. использовать в урлах только его) необходимо использовать следующий код .htaccess размещенный в корне домена:

RewriteCond % ^htaccess.net.ru [NC]

RewriteRule ^(.*)$ http://www.htaccess.net.ru/$1 [R=301,L]

Выставляем на суд общественности присланную нам конфигурацию — настройку .htaccess «/» — слеша, с подстановкой его в конце и так же с принудительным его убираем.

Убрать слэш в конце url, .htaccess убираем слэш в конце строки урла — ссылки

# убрать слэш в конце строки ссылки, в конце url

RewriteCond % !-d # не каталог

RewriteCond % ^(.+)/$ # окончивается в том числе на точку в конце

RewriteRule ^(.+)/$ /$1 [R=301,L] # убираем слеш в конце url — после последнего символа

Добавить слэш в конце url, htaccess добавляем слэш в конце строки урла — ссылки

#добавить слэш в конце строки ссылки, в конце url

RewriteCond % !(.*)/$ # не окончивается в том числе на точку в конце

RewriteRule ^(.*[^/])$ $1/ [L,R=301] # ставим — добавляем слеш в конце url — после последнего символа

Посетители веб-сайта авторизуются при помощи стандартной авторизации ( AuthType BasicAuth ). Необходимо по ссылке / home показывать содержимое их домашних каталогов:

Есть два каталога /home/net/storag1 и /home/net/storage2, в которых нужно искать запрашиваемые файлы:

RewriteCond /home/net/storage1/% -f

RewriteRule (.+) /home/net/storage1/$1 [L]

RewriteCond /home/net/storage2/% -f

RewriteRule (.+) /home/net/storage2/$1 [L]

Закрыть доступ к веб-сайту в рабочее время:

Перенаправление пользователя с определенным юзер-агентом — браузером на определенную версию сайта (например, при заходе с айфона — перенаправлять направить пользователя на поддомен с специальной мобильной версией сайта:

RewriteRule .* http://iphone.htaccess.net.ru/ [R]

Или же перенаправлять не на поддомен, а в специальный каталог сайта /iPhone-versia/, код .htaccess следующий:

RewriteRule .* /iPhone-versia/ [R]

В данном случае мы применили глобальную переменную HTTP заголовка «User-Agent», который отправляют все браузеры при заходе на любой ресурс (этот заголовок в ряде браузером можно изменять на любое значение, но в 99% это ни кто не делает, так как это снижает комфорт серфинга в интернете, так как, например ряд сайтов верстает версту -дизайн сайта под каждый браузер, с учетом его специфики выполнения спецификаций HTML5, CSS и других стандартов, которые разные браузеры часто выполняют со значительными отличиями.

Браузер iPhone имеет значение «User-Agent» следующее:

Mozilla/5.0 (iPhone; U; CPU like Mac OS X; ru)

AppleWebKit/420+ (KHTML, like Gecko) Version/3.1 Mobile/1C25 Safari/419.5

Перенаправление домашних каталогов для чужаков

Мы хотим перенаправить URL домашних каталогов на другой веб-сервер www.somewhere.com когда запрашиваемый пользователь не принадлежит локальному домену ourdomain.com. Это иногда используется в контексте виртуальных хостов.

Просто правило на перенаправление:

Перенаправление несуществующих URL на другой веб-сервер

Типичный часто задаваемый вопрос по URL преобразованиям — это как перенаправить несуществующие запросы с сервера А на сервер B. Обычно это делается через ErrorDocument CGI-скрипты на Perl, однако с модулем mod_rewrite тоже есть решение. Заметьте однако, что это менее ресурсоёмко чем использвание ErrorDocument CGI-скрипта!

Первое решение имеет лучшую производительность однако меньшую гибкость и меньшую защиту от ошибок:

Проблема здесь в том, что это будет работать только для страниц находяшихся внутри DocumentRoot. Тогда как вы можете добавить больше условий (например ещё и для управления домашними каталогами, и т.д.) есть лучший вариант:

Здесь используется функция опережающей проверки URL (look-ahead), присутствующая в mod_rewrite. В результате это будет работать для всех типов URL и к тому же это безопасно. Однако это снижает производительность веб-сервера, потому что для каждого запроса производится более одного внутреннего подзапроса. Поэтому, если ваш веб-сервер имеет мощный процессор, используйте этот вариант. Если это медленная машина, используйте первый или лучше ErrorDocument CGI-скрипта.

Редиректы в зависимости от времени

Когда нужно применять уловки типа содержания зависящего от времени масса вебмастеров все ещё используют CGI скрипты которые производят редиректы на специальные страницы. Как это может быть сделано через mod_rewrite?

Есть много переменных названных TIME_xxx для условий редиректа. В связке со специальными лексикографическими образцами для сравнения STRING и =STRING мы можем производить редиректы зависящие от времени:

Управление содержанием — От старого с новому (внутреннее)

Предположим что мы недавно переименовали страницу bar.html в foo.html и сейчас хотим для обратной совместимости сделать доступным и старый URL. В действительности мы хотим чтобы пользователи использующие старый URL даже не узнали что страницы были переименованы.

Мы перенаправим старый URL на новый через внутренний редирект путем следующих директив:

RewriteRule ^foo\.html$ bar.html

От старого с новому (внешнее)

Снова предположим что мы недавно переименовали страницу bar.html в foo.html и хотим сейчас для обратной совместимости сделать доступным и старый URL. Однако, в этот раз мы хотимчтобы пользователи использующие старый URL узнали этот новый URL, т.е. адресная строка их браузеров также должна измениться.

Мы используем HTTP редирект на новый URL который приведет к к изменениям в браузерах(в адресной строке) и таким образом это видят пользователи:

RewriteRule ^foo\.html$ bar.html [R]

Содержимое зависимое от браузера

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

Мы не можем использовать content negotiation потому что браузеры не не представляют свой тип в этой форме. Вместо этого мы должны использовать HTTP заголовок «User-Agent». Следующее условие делает следующее: Если HTTP заголовок «User-Agent» начинается с «Mozilla/3», страница foo.html преобразуется в foo.NS.html и редирект прекращается. Если браузер «Lynx» или «Mozilla» версий 1 или 2 URL становится foo.20.html. Все остальные браузеры получают страницу foo.32.html. Это делается следующим набором директив:

RewriteRule ^foo\.html$ foo.NS.html [L]

RewriteRule ^foo\.html$ foo.20.html [L]

RewriteRule ^foo\.html$ foo.32.html [L]

Предположим что есть чудесные страницы на удалённых хостах и мы хотим внести их в наше пространство имен(сайт). Для FTP серверов мы бы использовали программу зеркало которая в действительности управляет обновлениями копий удалённых данных на локальной машине. Для веб-сервера мы могли бы использовать программу webcopy которая делает похожие вещи по HTTP. Однако обе эти технологии имеют один главный недостток: локальная копия актуальна всегда настолько, насколько часто мы запускаем эту программу. Было бы намного лучше если бы зеркало было не статическим должно быть полное соответствие копий, вне зависимости от частоты запуска этой программы. Вместо этого мы хотим динамическое зеркало с автоматическим обновлением данных когда это необходимо (обновление данных на удаленном сервере).

Для обеспечения этой функции мы отобразим удаленную страницу или даже полностью удаленный сайт в наше веб-пространство используя Proxy Throughput опцию ( флаг [P]):

RewriteRule ^hotsheet/(.*)$ http://www.tstimpreso.com/hotsheet/$1 [P]

RewriteRule ^usa-news\.html$ http://www.quux-corp.com/news/index.html [P]

Обратное динамическое зеркало

RewriteCond /mirror/of/remotesite/$1 -U

RewriteRule ^http://www\.remotesite\.com/(.*)$ /mirror/of/remotesite/$1

От статики к динамике

Как можно трансформировать статическую страницу foo.html в её динамический вариант foo.cgi незаметным образом, т.е. так чтобы ни браузер ни пользователь не заметили этого.

Мы просто перенаправляем URL на CGI-скрипт и корректируем MIME-тип так чтобы это действительно работало как CGI-скрипт. Таким образом запрос к /

quux/foo.html внутренне приведет к вызову /

RewriteRule ^foo\.html$ foo.cgi [T=application/x-httpd-cgi]

Регенерация содержания на лету

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

Это делается следующим набором директив:

RewriteRule ^page\.html$ page.cgi [T=application/x-httpd-cgi,L]

Здесь, запрос к page.html приводит к внутреннему запуску соответствующего page.cgi если page.html все-ещё отсутствует или имеет нулевой размер. Фокус здесь в том что page.cgi это обычный CGI скрипт который (в дополнение к собственному STDOUT) записывает свой вывод в файл page.html. Запустив это один раз, сервер передает данные page.html. Когда вебмастер хочет обновить содержание, он просто удаляет page.html (обычно с помощью cronjob).

Перенаправление по языку определенному по веб-браузеру зашедшего

Файл Htaccess перенаправит посетителя с определенным языком на определенную вами страницу с соответствующим содержанием.

Оставляем естественное нужный язык (например zh -китайский), и ставим свою страницу вместо http://htaccess.net.ru/doc/additional_material/index.php:

RewriteCond % (aa|ab|af|am|ar|as|ay|az|ba|be|bg|bh|bi|bn|bo|br|ca|co|cs|cy|da|de|dz|el|en|eo|es|et|eu|fa|fi|fj|fo|fr|fy|ga|gd|gl|gn|gu|ha|hi|hr|hu|hy|ia|ie|ik|in|is|it|iw|ja|ji|jw|ka|kk|kl|km|kn|ko|ks|ku|ky|la|ln|lo|lt|lv|mg|mi|mk|ml|mn|mo|mr|ms|mt|my|na|ne|nl|no|oc|om|or|pa|pl|ps|pt|qu|rm|rn|ro|ru|rw|sa|sd|sg|sh|si|sk|sl|sm|sn|so|sq|sr|ss|st|su|sv|sw|ta|te|tg|th|ti|tk|tl|tn|to|tr|ts|tt|tw|uk|ur|uz|vi|vo|wo|xh|yo|zh|zu) [NC]

Перенаправление на папку сайта силами mod_rewrite

Добрый день, нашел и посмотрел немало примеров mod_rewrite, но проблему так и не решил, так что если кому не трудно, посоветуйте как сделать правильно или что толковое почитать.

есть сайт (site.ru) он функционирует нормально.
на нем есть папка (site.ru/folder) для нее требуется описать в .htaccess правило редиректа на (site.ru/folder/public), чтобы при этом сохранилась работа основного сайта.

Заранее очень благодарен

22.05.2013, 20:36

Перенаправление mod_rewrite
Здравствуйте, не подскажите как сделать при переходе на адрес sitename.ru/id1 или sitename.ru/id11.

mod_rewrite не работает перенаправление
Требуется заменить строчку site/index.php?producer=PRODUCERNAME на site/PRODUCERNAME. .

Mod_rewrite сайт в папку
Всем доброго времени. Сломал голову, пожалуйста помогите с задачей. Бьюсь уже около года, все.

Перенаправление в другую папку через .htaccess
Здравствуйте. Помогите, пожалуйста, с такой проблемкой. Делаю перенаправление в подпапку, но.

Создание сайта силами индуса для радио
Здравствуйте, необходимо сделать простою страничку для местного радио по интернету. Фон при.

Шпаргалка по .htaccess

Это не мануал, здесь собраны наиболее часто используемые настройки .htaccess, своего рода сборник подсказок.

Для чего нужен .htaccess

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

Правила .htaccess распространяются на все директории, где расположен файл, кроме директорий, где расположен собственный .htaccess.

Файл .htaccess считывается сервером Апач при каждом обращении, поэтому все изменения входят в силу сразу, после изменения.

Глобальные настройки сервера Апач могут содержать запрет на исполнение некоторых команд, обычно это вызывает ошибку 500. Также подобную ошибку может вызывать неправильный синтаксис или ошибка, например пропуск пробела.

Запрет доступа для определенных IP-адресов или диапазонов IP-адресов

Запрет доступа с IP-адреса 123.123.123.123.

Если не указывать последние цифры адреса, то запрет будет распространяться на весь диапазон 123.123.123.0 — 123.123.123.255.

Разрешаем доступ только с определенных IP-адресов

Принудительное задание кодировки

Иногда требуется очистка кэша браузера.

Отмена перекодировки сервером

Создание собственных страниц с сообщениями об ошибках

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

Строка ErrorDocument 404 http://site.ru/error/404.html указывает, что при ошибке 404 будет показан файл 404.html, который должен находиться в корне директории сайта. Если файл расположен в другой директории, измените путь к файлу или ссылке.

Редиректы

Редирект на .html

Пример, редирект с c site.ru/blog на site.ru/blog.html.

Редирект на страницу без слеша в конце адреса

Пример, редирект с c site.ru/blog/ на site.ru/blog.

Редирект на страницу со слешем в конце адреса

Редирект на страницу без index.php в адресе

Редирект на страницу без index.php в конце адреса

Редирект с www на без www

Редирект без www на www

Склейка доменов

Пример, у вас несколько доменов, но посетитель должен переправляться на один.

Редирект со старых статических url на новые

Пример редирект со страницы http://site.com.ru/ >

Защита от хотлинка

Если вы хотите запретить вставку изображений с сайта по прямой ссылке.

Вместо site.ru укажите адрес сайта, jpg|jpeg|png|gif — расширение запрещенных изображений, images.jpg – изображение которое будет показываться, если картинка находится не в корне сайта, укажите полный путь.

Защита от брутофорса

Разрешаем доступ к директории administrator только по протоколу HTTP, что отсеет некоторых ботов. Для каждой CMS нужно указать свой адрес, например wp-login, wp-admin и так далее.

Бытует легенда, что происхождения названия сервера Апач происходит не от названия индейского племени. Когда сервер был еще в самом начале пути, группа энтузиастов небольшие дополнения к коду, патчи (англ – patch), и «a patchy server» превратилось в Апач, а знаменитое перо на логотипе появилось позже.

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

Статья писалась эпизодическими «набегами», так что если увидите ошибку, поправьте.

Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих