Проверить htaccess – 19 полезных возможностей файла .htaccess / PromoPult corporate blog / Habr

Содержание

Проверка работы htaccess и сжатие для ускорения сайта.

 

 

Поговорим откровенно, ДА, про htaccess и сжатие.

Думаю что встречались с ситуацией когда ваш сайт перестает отвечать на запросы.

Или начинает медленно грузиться и начинает вести себя странно. На простом хостинге помимо вашего сайта на сервере находится еще два десятка других сайтов.

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

Файл .htaccess позволяет изменять многие настройки вашего сайта … как настройки веб-сервера Apache, так и опции PHP.

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

В корне сайта вы можете объявить -Indexes, а в избранных каталогах создать ещё один файл .htaccess и в нем объявить +Indexes.

Помните !

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

И в том числе и на поддомены (поскольку директории поддоменов являются поддиректориями основного сайта).

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

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

На заметку…

Некоторые FTP-клиенты считают файлы, начинающиеся с точки, скрытыми и не отображают их по умолчанию. В таких случаях для того, чтобы видеть файл .htaccess, необходимо в настройках FTP-клиента включить настройку «Отображать скрытые файлы».

На заметку…

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

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

Для под-домена наследуются настройки .htaccess домена.

На заметку…

При открытии директории без указания конкретного файла веб-сервер ищет файлы index.htm, index.html, index.php для отображения (индексные файлы).

Если индексные файлы отсутствуют, сервер возвращает ошибку 403 Forbidden, так как отображение списка файлов в директории по умолчанию запрещено.

Чтобы ошибка 403 Forbidden не отображалась, либо создайте в директории индексный файл, либо добавьте в файле .htaccess опцию:

Options +Indexes

Установка индексного файла для сайта

По умолчанию индексным файлом вашего сайта веб-сервер считает файл (в порядке приоритета): index.html, index.php.

Чтобы установить в качестве индексного файла произвольный файл, следует добавить инструкцию:

DirectoryIndex имя_файла

Например, следующая инструкция предписывает веб-серверу при обращении к сайту открывать в качестве индексной страницы скрипт на языке Perl, размещенный в директории cgi-bin вашего сайта:

DirectoryIndex /cgi-bin/engine.pl

Как включить отображение ошибок PHP?

Для отображения ошибок PHP добавьте в файл .htaccess директиву:

php_value display_errors 1

Как изменить максимальный размер загружаемых файлов в PHP?

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

php_value upload_max_filesize 20M
php_value post_max_size 20M

Вместо 20M укажите желаемый размер ограничения. Значение этих параметров не может быть больше 50M. Обратите внимание, что символ “M” (латинская M) указывается слитно со значением.

Как указать интерпретатору PHP необходимость обрабатывать не только файлы .php?

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

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

AddType application/x-httpd-php .phtml

Как изменить время хранения сессий PHP

Изменение времени хранения сессий может потребоваться, например, если вы хотите, чтобы данные об авторизации пользователей на вашем сайте сохранялись дольше.

По умолчанию время хранения сессий — 1440 секунд (24 минуты), cookie с идентификатором сессии — до закрытия браузера пользователем.

Для изменения времени хранения сессий PHP необходимо внести несколько изменений в .htaccess.

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

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

Для изменения времени хранения сессий добавьте в .htaccess следующие директивы:

# Создайте отдельную директорию для хранения сессий вашего сайта,
# например, domains/ВАШ_САЙТ/tmp. Это необходимо, чтобы PHP не удалял сессии сайта
# при очистке старых сессий других сайтов, работающих на аккаунте.
# Установите директорию хранения сессий для сайта с помощью session.save_path.
php_value session.save_path /home/ВАШ_ЛОГИН/domains/ВАШ_САЙТ/tmp

# Установите максимальное время жизни сессии в секундах.
# 604800 – 1 неделя.
php_value session.gc_maxlifetime 604800

# Установите время жизни cookie, которая сохраняет идентификатор сессии

# в браузере пользователя.
php_value session.cookie_lifetime 604800

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

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

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

  1. Указывать вложенность директорий хранения сессий с помощью аргумента N в session.save_path. Очищать старые сессии при этом необходимо собственными скриптами. Более подробная информация об этом методе находится в описании session.save_path в документации PHP.
  2. Реализовать собственный механизм хранения сессий (например, в MySQL) и установить его с помощью session_set_save_handler().

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

Директивы SSI (Server Side Includes) по умолчанию обрабатываются в файлах с расширением .shtml (например, index.shtml). Чтобы SSI обрабатывались и в других файлах, необходимо в файле .htaccess указать следующие директивы:

AddType text/html .html .ssi
AddOutputFilter INCLUDES .html .ssi

Вместо “.ssi .html” укажите расширения файлов, в которых должны обрабатываться директивы SSI.

Обратите внимание:  не рекомендуется использовать в одном и том же файле PHP и SSI одновременно.

Как настроить выполнение скриптов CGI?

Для выполнения скриптов CGI в какой-либо папке необходимо настроить веб-сервер соответствующим образом с помощью файла .htaccess.

  1. В папке, в которой должны выполняться скрипты CGI, создайте файл .htaccess вида: Options +ExecCGI
    AddHandler cgi-script .cgi .pl Вместо “.cgi .pl” укажите список расширений, которые должны обрабатываться как скрипты.
  2. Загрузите скрипты в папку.
  3. С помощью Вашего файлового менеджера установите файлам скриптов права на выполнение (755).

Как изменить ограничение на использование оперативной памяти в PHP?

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

php_value memory_limit 128M

Вместо 128M укажите желаемый размер ограничения. Обратите внимание, что символ “M” (латинская M) указывается слитно со значением.

Как сделать так, чтобы сайт всегда открывался по основному имени?

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

RewriteEngine on
RewriteCond %{HTTP_HOST} !^example.com$
RewriteRule ^(.*) http://example.com/$1 [R=301,L]

Замените example.com на основное имя вашего сайта. Теперь при обращении к сайту пользователи будут автоматически перенаправлены на его основное имя.

Немного SEO (куда же без него) 

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /
RewriteCond %{HTTP_HOST} ^black-web
RewriteRule (.*) [R=301,L]
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/
RewriteRule ^index\.php$ http://www.black-web.ru/ [R=301,L]
</IfModule>

Обязательно не забыть про условие <IfModule mod_rewrite.c>.

Не окажись у хостера данного модуля и ваш сайт станет выдавать 500-ую ошибку. Данный конкретный модуль входить в сборку Апача по-умолчанию. Ну а вдруг… Хостеры и их админы бывают всякие.

В данной части пользы больше для SEO. Модуль rewrite как следует из его названия занимается перенаправлениями

В этой части файла мы указали две склейки: мы склеили ваш_сайт и www.ваш_сайт Даже если пользователь наберет ваш сайт без WWW его перебросить 301 редериктом на www.ваш_сайт.

А также мы избавились /index.php в строке запроса. Если пользователь наберет www.ваш_сайт/index.php его перебросит (снова 301 редериктом) на www.ваш_сайт.

Теперь поисковики не будут путаться между www и не будут дублировать главную страницу в результатах индексирования вашего сайта. Гуглим СЕО склейки домена, если не понимаете зачем это нужно.

Итак…  .htcces и сжатие для ускорения сайта.

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

У Апача есть два модуля сжатия.

Оба не являются модулями по умолчанию, поэтому необязательно могут присутствовать у вашего провайдера. Но как показала практика у 99% провайдеров один из них стоит.

Наиболее распространен mod_deflate. Чтобы его с помощью сжимать весь контент на вашем сайте добавьте в .htaccess следующие строки:

<ifModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/css text/javascript application/javascript application/x-javascript
</ifModule>

Как видите мы должны перечислить mime type файлов, которые следует подвергать сжатию.

Сюда можно добавить и видео и картинки, но толку это даст мало. Потому что jpeg или gif уже сами по себе являются сжатыми форматами. Также как avi или flv. Вы фактически нечего не выиграете указав их.

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

<IfModule mod_gzip.c>
mod_gzip_on         Yes
mod_gzip_dechunk    Yes
mod_gzip_item_include file                \.(html?|txt|css|js|php|pl)$
mod_gzip_item_include mime                ^text\.*
mod_gzip_item_include mime                ^application/x-javascript.*
mod_gzip_item_exclude mime                ^image\.*
mod_gzip_item_exclude rspheader  ^Content-Encoding:.*gzip.*
</IfModule>

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

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

Можете воспользоваться этим или этим онлайн сервисом для проверки включения сжатия на вашем сервере.

Оказывается можно быстрее … Если применить кеширование страниц.

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

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

В html разметки мы всегда можем использовать meta теги. И через php мы может устанавливать заголовки ответа сервера. Остается вопрос, как быть с css, js, image и т.д. и т.п.

Помочь нам в этом могут два модуля: mod_headers и mod_expires которые могут установить заголовки в ответ сервера и подсказать вашему браузеру, что и как нужно кешировать.

Один из модулей обычно стоит у провайдера, но как и в случае с любым модулем, который не входит в стандартную сборку Апача, 100% гарантии никто вам не даст. Поэтому снова во избежание 500й ошибки указывает условия для каждого из модулей.

<ifModule mod_headers.c>
#кэшировать html и htm файлы на один день
<FilesMatch “\.(html|htm)$”>
Header set Cache-Control “max-age=43200”
</FilesMatch>
#кэшировать css, javascript и текстовые файлы на одну неделю
<FilesMatch “\.(js|css|txt)$”>
Header set Cache-Control “max-age=604800”
</FilesMatch>
#кэшировать флэш и изображения на месяц
<FilesMatch “\.(flv|swf|ico|gif|jpg|jpeg|png)$”>
Header set Cache-Control “max-age=2592000”
</FilesMatch>
#отключить кэширование
<FilesMatch “\.(pl|php|cgi|spl|scgi|fcgi)$”>
Header unset Cache-Control
</FilesMatch>
</IfModule>

Вот такой синтаксис у mod_headers.

В данной секции я отключил кеширование php файлов. Хотя по моему мнению небольшой временной интервал кеширования им не повредит.

5-30 секунд, это интервал времени, за который мало что меняется. А многие пользователи любят пользоваться клавишей back (вернуться назад).

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

Во второй секции где идут условия для mod_expires я именно так и делаю — для php ставлю небольшой интервал кеширования.

<ifModule mod_expires.c>
ExpiresActive On
#по умолчанию кеш в 5 секунд
ExpiresDefault “access plus 5 seconds”
#кэшировать флэш и изображения на месяц
ExpiresByType image/x-icon “access plus 2592000 seconds”
ExpiresByType image/jpeg “access plus 2592000 seconds”
ExpiresByType image/png “access plus 2592000 seconds”
ExpiresByType image/gif “access plus 2592000 seconds”
ExpiresByType application/x-shockwave-flash “access plus 2592000 seconds”
#кэшировать css, javascript и текстовые файлы на одну неделю
ExpiresByType text/css “access plus 604800 seconds”
ExpiresByType text/javascript “access plus 604800 seconds”
ExpiresByType application/javascript “access plus 604800 seconds”
ExpiresByType application/x-javascript “access plus 604800 seconds”
#кэшировать html и htm файлы на один день
ExpiresByType text/html “access plus 43200 seconds”
#кэшировать xml файлы на десять минут
ExpiresByType application/xhtml+xml “access plus 600 seconds”
</ifModule>

Подведем итог…

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

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

В результате всех манипуляций у меня стоит такой файл следующего содержания:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch bMSIE !no-gzip !gzip-only-text/html
</ifmodule>
<ifModule mod_expires.c>
ExpiresActive On
ExpiresDefault “access plus 5 seconds”
ExpiresByType text/html “access plus 1 seconds”
ExpiresByType image/gif “access plus 2592000 seconds”
ExpiresByType image/jpeg “access plus 2592000 seconds”
ExpiresByType image/png “access plus 2592000 seconds”
ExpiresByType text/css “access plus 604800 seconds”
ExpiresByType text/javascript “access plus 604800 seconds”
ExpiresByType application/x-javascript “access plus 604800 seconds”
<ifModule mod_headers.c>
<filesMatch “\.(ico|pdf|flv|jpg|jpeg|png|gif|swf)$”>
Header set Cache-Control “max-age=2592000, public”
</filesMatch>
<filesMatch “\.(css)$”>
Header set Cache-Control “max-age=604800, public”
</filesMatch>
<filesMatch “\.(js)$”>
Header set Cache-Control “max-age=216000, private”
</filesMatch>
<filesMatch “\.(xml|txt)$”>
Header set Cache-Control “max-age=216000, public, must-revalidate”
</filesMatch>
<filesMatch “\.(html|htm|php)$”>
Header set Cache-Control “max-age=1, private, must-revalidate”
</filesMatch>
</ifModule>
</IfModule>
# END WordPress

А вот профессионально написанный .hatcces  https://github.com/Roosso/other/blob/master/.htaccess

По мне многовато там всячины а может и ошибаюсь. Для тех у кого все получилось, идем на www.webpagetest.org и пробуем мерить красоту до и после.

А здесь уже готовенький  .hatcces для пользования: .htaccess

Думаю получился  htaccess и сжатие для ускорения сайта !

 

Схожие статьи по совпадениям:

wp.aspekti.eu

Защита сайта с помощью .htaccess и .htpasswd

В данной статье будет рассмотрен самый простой и доступный способ защиты — базовая аутентификация.

Замечание

Аутентификация — процесс, с помощью которого проверяется, что некто является именно тем, за кого он себя выдает. Как правило, проверка включает в себя ввод имени и пароля.

Рассмотрим, как работает базовая аутентификация.
При обращении посетителя в защищаемую директорию, сервер Apache в ответ на запрос посылает заголовок с кодом 401 (401 authentication required header). Браузер посетителя принимает заголовок с кодом 401 и выводит окно с полями для ввода имени пользователя и пароля. После ввода имени и пароля эти данные отсылаются назад серверу, который проверяет имя пользователя на предмет нахождения в специальном списке, а пароль на правильность. Если все верно, то посетитель получает доступ к ресурсу. Вместе с заголовком браузеру посылается специальной имя, называемое областью действия. Браузер кэширует не только имя и пароль, чтобы передавать их при каждом запросе, но и область действия. Благодаря этому, ввод имени и пароля в защищаемой директории осуществляется только раз. В противном случае их необходимо было бы вводить при каждом запросе к защищаемой директории. Кэширование параметров аутентификации (имя, пароль, область действия), обычно осуществляет только в пределах одного сеанса.

Замечание

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

Замечание

WEB-сервер Apache поддерживает еще один вид защиты — digest-аутентификацию. При digest-аутентификации пароль передается не в открытом виде, а в виде хеш-кода, вычисленному по алгоритму MD5. Поэтому пароль не может быть перехвачен при сканировании трафика. Но, к сожалению, для использования digest-аутентификации необходимо установить на сервер специальный модуль — mod_auth_digest. А это находится только в компетенции администрации сервера. Также, до недавнего времени, digest-аутентификация поддерживалась не всеми видами браузеров.

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

1. WEB-сайт и FTP-доступ к нему.
2. Права на создание файлов .htpaccess и организацию защиты с помощью них.
3. Утилита генерации паролей htpasswd.exe

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

Замечание

Удобно создавать файлы .htaccess с помощью встроенного редактора в оболочках Far, WindowsCommander, TotalCommander и т.п., а также в редакторе Блокнот.

Замечание

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

Перед тем как сохранить файл, впишите в него следующие строки:

AuthType Basic
AuthName admin
require valid-user

Затем, через FTP-доступ, перепишите файл .htaccess на сайт, в ту директорию, которую вы хотите защитить.

Замечание

Действие файлов .htaccess распространяется не только на ту директорию, где лежит файл, но и на все поддиректрии, лежащие уровнем ниже.

Далее через браузер обратитесь к этой директории. Если Вы защищаете директорию admin и переписали туда файл .htaccess, то для проверки Вам следует вписать в адресную строку браузера следующий URL: http://www.mysite.ru/admin/.

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

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

Замечание

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

Файл с паролями создается утилитой htpasswd.exe. Если у Вас на машине установлен WEB-сервер Apache, то данная утилита находится в директории с установленным Apache-ем в подкаталоге bin.

Замечание

Если у Вас не установлен Apache, то утилиту htpasswd.exe можете скачать по ссылке: http://www.softtime.ru/files/htpasswd.zip.

Для работы с утилитой htpasswd.exe необходим интерфейс работы с командной строкой. Интерфейсом работы с командной строкой обладают такие программы как Far, WindowsCommander и т.п. Здесь будет рассмотрена работа с командной строкой с помощью утилиты cmd, которая входит в поставку Windows 2000/XP и т.п.
Нажмите «Пуск»->»Выполнить», введите в строку ввода cmd и нажмите ОК. Вам откроется окно утилиты CMD.

Далее необходимо перейти в директорию, где находится утилита htpasswd.exe. Допустим, сервер Apache установлен в директории с:/Apache2, тогда введите в командную строку команду: cd../../apache2/bin и нажмите ввод.

Вы перешли в директорию с:Apache2 in. Теперь нужно дать команду на создание файла с паролем. Введите в командную строку следующее:

htpasswd -cm .htpasswd admin

* -cm — это ключи для утилиты. Ключ с — указывает, что необходимо создать новый файл с паролями. Если файл с таким именем уже существует, то он будет перезаписан. Ключ m — определяет шифрование по алгоритму MD5.
* .htpasswd — имя файла с паролями (можете использовать любое имя).
* admin — имя посетителя, которому будет разрешен доступ в закрытую область сайта.

В ответ, должен появится запрос на ввод пароля и его повтор. Если все правильно, то в завершении появится сообщение: Adding password for user admin. И в директории c:Apache2 in появится файл .htpasswd, к котором будет находиться строка с именем пользователя и хеш-кодом его пароля. Для того, что бы в тот же файл .htpasswd добавить еще одного пользователя следует убрать ключ -c из команды запуска утилиты htpasswd.exe

htpasswd -m .htpasswd admin

Замечание

Если файл с паролями не был создан, то возможно, некоторые ключи утилиты не поддерживаются в Вашей операционной системе. Например, иногда не поддерживается ключ m. В этом случае, Вам нужно ввести htpasswd -c .htpasswd admin
Для того, чтобы посмотреть ключи и параметры работы утилиты введите htpasswd.exe /? Вам будет выдано описание интерфейса.

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

И положите его в ту директорию, где находится Ваш файл с паролями. Теперь посетители сайта не смогут получить к нему доступ.

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

Для защиты директории могут использоваться следующие директивы:

* AuthType — Тип используемой аутентификации. Для базовой аутентификации эта директива должна иметь значение: Basic
* AuthName — Имя области действия аутентификации. Текст, помогающий посетителю понять, куда он пытается получить доступ. Например, может быть написано: «Private zone. Only for administrator!»
* AuthUserFile — путь к файлу с паролями (.htpasswd).
* AuthGroupFile — путь к файлу групп, если он существует.
* Require — Одно или несколько требований, которые должны быть выполнены для получения доступа к закрытой области.

AuthType Basic
AuthName "Private zone. Only for administrator!"
AuthGroupFile /usr/host/mysite/group
AuthUserFile /usr/host/mysite/.htpasswd
require group admins

Следует более подробно описать директивы AuthUserFile и AuthGroupFile. В них прописываются абсолютные пути к соответствующим файлам от корня сервера.

Внимание!

Относительные пути работать не будут!

Путь от корня сервера, можно узнать, спросив у администрации сервера, либо можно попробовать выяснить его самим. Для этого выполните функцию phpinfo(). На экран будет выведена фиолетовая таблица. Значение абсолютного пути от корня сервера можно посмотреть в переменных: doc_root, open_basedir, DOCUMENT_ROOT.
Директива Require определяет кому разрешен доступ к закрытой области. Например,

* require valid-user — разрешен доступ всем прошедшим проверку
* require user admin alex mango — разрешен доступ только посетителям с именами admin, alex, mango. Естественно, они должны пройти аутентификацию.
* require group admins — разрешен доступ всем пользователям из группы admins

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

Пример файла групп

Admins: admin alex mango
Users: guest user max23

В группу Admins входят посетители с именами admin, alex, mango. А группу Users входят посетители с именами guest, user, max23.

Примеры файлов .htaccess

Доступ всем пользователям, прошедшим авторизацию

AuthType Basic
AuthName "Private zone. Only for administrator!"
AuthUserFile /usr/host/mysite/.htpasswd
require valid-user

Доступ только пользователям admin и root

AuthType Basic
AuthName "Private zone. Only for administrator!"
AuthUserFile /usr/host/mysite/.htpasswd
require user admin root

Доступ только пользователей из группы admins

AuthType Basic
AuthName "Private zone. Only for administrator!"
AuthUserFile /usr/host/mysite/.htpasswd
AuthGroupFile /usr/host/mysite/group
require group admins

Запрет доступа только к файлу private.zip

AuthType Basic
AuthName "Private zone. Only for administrator!"
AuthUserFile /usr/host/mysite/.htpasswd
require valid-user

www.internet-technologies.ru

Где найти справочник по .htaccess? — Хабр Q&A

Спасибо за ответ. Прошу прощения с воспалением лёгких мучаюсь, голова совсем не соображает. Проблема в следующем. Есть две версии сайта - основной и мобильный на поддомене. Основная проиндексирована ПС без ошибок, мобильную только на днях добавил. Онлайн сервисами проверка .htaccess показывает, что половина условий не выполняется, так на кой тогда лишнее. И вообще "меня терзают смутные сомнения" в правильности составления, я в этом вопросе чайник. Не откажите в помощи, подскажите что и где не так. Попробую выложить оба файла. Заранее благодарю за помощь.
Файл основного сайта
<IfModule mod_rewrite.c>
RewriteEngine On 
RewriteCond %{HTTP_HOST} ^www.remdomteh.com.ua$ [NC] 
RewriteRule ^(.*)$ http://remdomteh.com.ua/$1 [R=301,L]
Options +FollowSymLinks

RewriteEngine On
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /(.*)index\.html($|\ |\?)

RewriteRule ^ /%1 [R=301,L]
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /(.*)index\.php($|\ |\?)
RewriteRule ^ /%1 [R=301,L]

RewriteCond %{HTTP_USER_AGENT} ((.*iPhone.*)|(.*iPod.*)|(.*BlackBerry.*)|(.*Android.*Mobile.*)|(.*Windows\ CE.*)|(.*IEMobile.*)|(.*Opera\ Mini.*)|(.*Opera\ Mobi.*))
RewriteCond %{REQUEST_FILENAME} !\.(jpg|gif|png|css|js|txt|ico|pdf|bmp|tif|mp3|wav|wma|asf|mp4|flv|mpg|avi|csv|doc|docx|xls|xlsx|ppt|pptx|zip|rar|tar|gz|dmg|iso)$ [NC]
RewriteCond %{HTTP_REFERER} !^[url]http://remdomteh.com.ua(/)?[/url]
RewriteRule ^(.*)$ http://m.remdomteh.com.ua/$1 [L,R=302]
</IfModule>

ErrorDocument 404 /404.html

А это для мобильной версии, на поддомене.
<IfModule mod_rewrite.c>
  Options +FollowSymlinks
  RewriteEngine on
  RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
  RewriteRule ^ http://%1%{REQUEST_URI} [R=301,L]

</IfModule>

ErrorDocument 404 /404.html

Что нужно - просто убрать отображение с www в адресе, в конце index.html и php, включить переадресацию на мобильную версию с основного сайта. Сжатие можно добавить, а то PageSpeed всё время об этом упоминает. Сервер Apache и gzip включен.
Благодарю за понимание и помощь)))

qna.habr.com

Как определить вредоносные строки .htaccess? — Хабр Q&A

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

Я сменил главную страницу сайта, удалил подозрительный слайдер (некоторые онлайн проверки на него показывали), вообщем абсолютную чистую страницу сделал. Отправил письмо гугл, чтобы опять проверили мой сайт. Пришло письмо, с которого я и узнал, что проблема не решена и :

Проверьте свой сайт на смартфоне и Вы увидите, что он перенаправляет пользователей на спамный домен. Если смартфона под рукой нет, можно воспользоваться эмулятором мобильных устройств в Chrome (developer.chrome.com/devtools/docs/device-mode), где в качестве устройста можно указать, например, Google Nexus 5 или Apple iPhone 5. При таком виде взлома злоумышленник часто вносит изменения в Ваш файл .htaccess. Ознакомьтесь с этими случаями из практики: , а затем проверьте свой файл .htaccess на предмет неожиданных изменений

Собственно вот и вопрос: я не спец в этих htaccess, как разобраться что в этом файле нужное, а что вредоносное?

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://feeds.feedburner.com/InplastCompany$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.yandex.ru/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://yandex.ru/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://yandex.ru$ [NC]
RewriteCond %{HTTP_REFERER} !^http://blogs.yandex.ru/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://blogs.yandex.ru$ [NC]
RewriteCond %{HTTP_REFERER} !^http://images.yandex.ru/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://images.yandex.ru$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.google.ru/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.google.ru$ [NC]
RewriteCond %{HTTP_REFERER} !^http://google.ru/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://google.ru$ [NC]
RewriteCond %{HTTP_REFERER} !^http://images.google.ru/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://images.google.ru$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.google.com/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.google.com$ [NC]
RewriteCond %{HTTP_REFERER} !^http://google.com/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://google.com$ [NC]
RewriteCond %{HTTP_REFERER} !^http://images.google.com/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://images.google.com$ [NC]
RewriteCond %{HTTP_REFERER} !^$ [NC]
RewriteRule .*\.(jpe?g|gif|bmp|png)$ - [F]
RewriteRule .*\.(.*.*.*jpg|jpeg|gif|png|bmp)$ http://sau.su/57f20dab4ce6da79ccf9aa5529e70707/prison.jpg [L]
FileETag MTime Size
<ifmodule mod_expires.c>
<filesmatch ".(jpg|gif|png|css|js)$">
ExpiresActive on
ExpiresDefault "access plus 1 year"
</filesmatch>
</ifmodule>
<ifModule mod_gzip.c>
 mod_gzip_on Yes
 mod_gzip_dechunk Yes
 mod_gzip_item_include file \.(html?|txt|css|js|php)$
 mod_gzip_item_include handler ^cgi-script$
 mod_gzip_item_include mime ^text/.*
 mod_gzip_item_include mime ^application/x-javascript.*
 mod_gzip_item_exclude mime ^image/.*
 mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post\.php*
RewriteCond %{HTTP_REFERER} !.*inplast-nn.ru.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) ^http://%{REMOTE_ADDR}/$ [R=301,L]





# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

qna.habr.com

.htaccess

15.10.2014

Почему то на просторах рунета информация о локальной настройки веб-сервера Apache посредством конфигурационного файла .htaccess приводится как то не полно и однобоко. В основном приводятся примеры (часто не рабочие) или сухой перевод англоязычной документации.

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

Редиректы

Редиректы осуществляются с помощью модуля mod_rewrite. Задаются правила преобразований в виде следующей конструкции:


<IfModule mod_rewrite.c>
  Options +FollowSymLinks
  RewriteEngine On

  [СЮДА ПИШЕМ ПРАВИЛА]  

</IfModule>

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


RewriteCond [СТРОКА ДЛЯ СРАВНЕНИЯ] [УСЛОВИЕ] [ФЛАГИ]
RewriteCond [СТРОКА ДЛЯ СРАВНЕНИЯ] [УСЛОВИЕ] [ФЛАГИ]
RewriteRule [ШАБЛОН] [СТРОКА ПОДСТАНОВКИ] [ФЛАГИ]

Строки RewriteCond - задают условия для срабатывания следующего за ними правила RewriteRule. Условий может быть несколько, они накладываются по правилу AND. Но можно изменить правило на OR с помощью флага OR.

В качестве [СТРОКИ ДЛЯ СРАВНЕНИЯ] могут использоваться различные переменные. Ссылка на полный список Я приведу только те, которые нужны чаще всего:

%{REQUEST_URI} Строка запроса (без доменного имени, и GET параметров), пример "/server/htaccess/"
%{HTTP_HOST} Доменное имя, например "max22.ru"
%{QUERY_STRING}Строка GET параметров

[УСЛОВИЕ] также как и [ШАБЛОН] представляют собой perl совместимое регулярное выражение, с некоторыми дополнениями, позволяющими например проверить файл ли это, или существующий url.

[ФЛАГИ] Флаги пишутся в квадратных скодках через запятую: [NC,OR]. Флаги для условий:

NC Регистронезависимая проверка
OR Условие сопостовляется с остальными про правилу ИЛИ

Подвыражения в регулярных выражениях (заключенные в скобки), доступны для вставки в [СТРОКУ ПОДСТАНОВКИ], обращаться к подвыражениям нужно так: %N - для подвыражений в условиях (RewriteCond) и $N - для подвыражений в правилах (RewriteRule), где N - порядковый номер подвыражения.

RewriteRule - правило подстановки. Если запрос подходит под вышестоящие проверки и [ШАБЛОН], то применяется правило подстановки. Здесь регулировать поведение также можно с помощью флагов. Флаги есть разные, приведу наиболее часто используемые:

NC Регистронезависимая проверка
R=301 Будет редирект с кодом 301, можно указать другой код
L Это последнее правило, больше не применять правил преобразований

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

Внимание! Браузеры кешируют редиректы!!!

Причем обычные сочетания типа Ctrl+F5 или Ctrl+R не помагают. Я во время тестирования каждый раз открываю страницу в НОВОМ окне в режиме инкогнито. Причем старые страницы в режими инкогнито надо закрывать.

Примеры

Универсальный редирект с www на без www

Тут самое интересное, почему то везде приводятся примеры, жестко привязанные к домену сайта. Зачем?, если есть универсальное решение:


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

Проверяем доменное имя, если оно начинается с www, то сработает правило: "все, на http://%1/$1". Здесь %1 это наш домен без www (взят из условия), а $1 это адрес (взят из самого правила).

Универсальный редирект с без www на www


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

Тут маленько сложнее. Первое условие нужно для того чтобы получить домен (%1), оно всегда истина. Второе условие проверяет, что домен начинается не с www. Ну и само правило, аналогичное предыдущему примеру

Простой редирект


RewriteRule ^news/happy.* /news.html [R=301,L]

Для простого редиректа условия задавать не обязательно, только правило.

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


RewriteRule ^news/happy.* /news.html [L]

Иногда требуется, чтобы был редирект без смены адреса, т.е. реврайт без редиректа. Для этого просто не указываем флаг редирект (R), и получаем желаемый результат, теперь по адресу news/happy получим news.html, а в адресной строке останется news/happy

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

Например, нужно что бы со страницы /?action=page&id=15 был редирект на /page/15/:


RewriteCond %{QUERY_STRING} action=page [NC]
RewriteCond %{QUERY_STRING} id=(\d+) [NC]
RewriteRule .* /page/%1/? [R=301,L]

Поясню, первым условиям проверяем что есть get параметр action=page, вторым условием проверяем что id равно числу. Эти условия нельзя объединять, т.к. параметры могут идти и наоборот, т.е. index.php?action=page&id=15 и index.php?id=15&action=page должны быть равноценны. Но и наконец правило, там все обычно, кроме знака вопрос (?) на конце. Он нам нужен, чтобы отсечь исходные GET параметры, иначе получим /page/15/?action=page&id=15

Редирект на мобильную версию сайта

Допустим, что мобильная версия расположена на поддомене m.site.ru. Будем переходить на мобильную версию только с главной страницы основного домена.


RewriteCond %{HTTP_USER_AGENT} (?i:midp|samsung|nokia|j2me|avant|docomo|novarra|palmos|palmsource|opwv|chtml|pda|mmp|blackberry|mib|symbian|wireless|nokia|hand|mobi|phone|cdm|upb|audio|SIE|SEC|samsung|HTC|mot-|mitsu|sagem|sony|alcatel|lg|eric|vx|NEC|philips|mmm|xx|panasonic|sharp|wap|sch|rover|pocket|benq|java|pt|pg|vox|amoi|bird|compal|kg|voda|sany|kdd|dbt|sendo|sgh|gradi|jb|dddi|moto|iphone|android) [NC] 
RewriteCond %{HTTP_HOST} site.ru
RewriteRule ^$ http://m.site.com/ [R=302,L]

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

Второй строкой проверяем что мы находимся на нужном домене (т.к. пример не универсальный)

Третьей строкой, мы проверяем, что находимся на главной страницы (без всяких параметров и прочего) и перенаправляем на поддомен.

Универсальная версия

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


RewriteCond %{HTTP_HOST} ^(.*)$ [NC]
RewriteCond %{HTTP_USER_AGENT} (?i:midp|samsung|nokia|j2me|avant|docomo|novarra|palmos|palmsource|opwv|chtml|pda|mmp|blackberry|mib|symbian|wireless|nokia|hand|mobi|phone|cdm|upb|audio|SIE|SEC|samsung|HTC|mot-|mitsu|sagem|sony|alcatel|lg|eric|vx|NEC|philips|mmm|xx|panasonic|sharp|wap|sch|rover|pocket|benq|java|pt|pg|vox|amoi|bird|compal|kg|voda|sany|kdd|dbt|sendo|sgh|gradi|jb|dddi|moto|iphone|android) [NC]
RewriteRule ^$  http://m.%1 [R=302,L]

Редирект с главной страницы

Речь идет про запрос типа site.ru (без site.ru/index.php)

Здесь оказалось не все так очевидно, я столкнулся с необъяснимым поведением.

Реврайт без редиректа (урл не меняется). Рабочий вариант:


RewriteRule ^index.php$  /about/ [L]

Редирект. НЕ рабочий вариант:


RewriteRule ^index.php$  /about/ [R=301,L]

Реврайт без редиректа (урл не меняется). НЕ рабочий вариант:


RewriteRule ^$  /about/ [L]

Редирект. Рабочий вариант:


RewriteRule ^$  /about/ [R=301,L]

Если мне кто - нибудь расскажет почему эти примеры работают крест накрест, а обратно не работают - буду очень рад.

max22.ru

Не корректно работает rewriteRule в htaccess? — Хабр Q&A

Столкнулся с такой бедой - не корректно обрабатывается rewriterule в htaccess при кажущейся простате в обработке. не понимаю в какую сторону рыть, настройки сервера?

имею htaccess

RewriteEngine on
RewriteBase /
Options +FollowSymlinks

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

#RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.php\ HTTP/
#RewriteRule ^index\.php$ / [R=301,L]

#RewriteCond %{REQUEST_METHOD} =GET
#RewriteCond %{REQUEST_URI} ^(.*)/index\.php$
#RewriteRule ^(.*)$ %1/ [R=301,L]

RewriteCond %{REQUEST_URI} !(.*)/$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !\..+$
RewriteRule ^(.*)$ $1/ [L,R=301]

RewriteRule ^(.*)/(.*)/(.*)/(.*)/(.*)/(.*)/?$ index.php\?la\=$1&url\=$2&country\=$3&region\=$4&city\=$5&dop\=$6 [QSA,L] #/ru/forecast/Russia/Murmansk/Apatity/10days - <b>ЗДЕСЬ ПРОБЛЕМА!!!</b>
RewriteRule ^(.*)/(.*)/(.*)/(.*)/(.*)/?$      index.php\?la\=$1&url\=$2&country\=$3&region\=$4&city\=$5 [QSA,L] #/ru/forecast/Russia/Murmansk/Apatity
RewriteRule ^(.*)/(.*)/(.*)/(.*)/?$           index.php\?la\=$1&url\=$2&country\=$3&region\=$4 [QSA,L] #/ru/forecast/Russia/Murmansk
RewriteRule ^(.*)/(.*)/(.*)/?$                index.php\?la\=$1&url\=$2&country\=$3 [QSA,L] #/ru/forecast/Russia/
RewriteRule ^(.*)/(.*)/?$                     index.php\?la\=$1&url\=$2 [QSA,L] #/ru/forecast/
RewriteRule ^([^/.]*)/?$             	      index.php\?la\=$1 [QSA,L]
RewriteCond %{THE_REQUEST}  !images
RewriteCond %{THE_REQUEST}  !tr

AddDefaultCharset UTF-8

ErrorDocument 404 /404.php

при запросе
domain.net/ru/forecast/Russia/Moscow_oblast/Trostniki/ - выдает все как надо
т.е. la="ru", url="forecast", country="Russia" и т.д.
и при других запросах с меньшим кол-вом параметров тоже работает корректно.

а при запросе
domain.net/ru/forecast/Russia/Moscow_oblast/Trostniki/10days/ - параметр la (первый в обработке в htaccess) принимает значение la="ru/forecast" - соответственно, все остальные параметры получаются не корректные

разные вариации перепробовал, но так и не понял, в чем беда?!

qna.habr.com

Настраиваем редирект с HTTP на HTTPS

Приветствую вас на сайте Impuls-Web!

Сегодня мы рассмотрим последний этап перевода сайта на SSL-сертификат, в котором нам нужно настроить редирект с http на https, или, другими словами, перенаправление с нашего прежнего адреса, начинающегося с http://, на новый адрес по протоколу HTTPS.

Навигация по статье:

Обучение фотошоп

В предыдущих статьях я рассматривала процесс получения у установки SSL сертификата. Если вы их не читали – вот ссылки:
Нужен ли SSL-сертификат для сайта?
Как получить бесплатно SSL-сертификат для сайта?
Как получить SSL сертификат?
Как установить SSL-сертификат на хостинг?

Переадресация на https через htaccess

Если ваш сайт уже проиндексирован то перед настройкой редиректа вам нужно произвести склейку зеркал, а потом уже настраивать редирект. Это поможет минимизировать потери трафика и позиций . О том как это сделать написано тут.

Для того, что бы настроить редирект с http на https, вам нужно, при помощи программы Notepad++, в корне вашего сайта открыть файл .htaccess, и далее, в самом начале этого файла, прописать один из нескольких вариантов перенаправления.

Как пользоваться Notepad++ и настроить для него FTP-подключение я рассказывала в одной из прошлых статей, с которой вы можете ознакомиться по этой ссылке:

Редактирование файлов сайта в Notepad++

редактирование файла htaccess

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

Если вы не хотите экспериментировать с различными способами перенаправления, то лучше всего будет обратиться в техподдержку вашего хостинга и уточнить у них, как лучше всего настроить редирект с HTTP на HTTPS именно для вашего хостинга.

Варианты написания серверного редиректа для HTTPS

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

Вариант 1

RewriteCond %{HTTPS} =off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [QSA,L]

RewriteCond %{HTTPS} =off

RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [QSA,L]

Вариант 2

RewriteCond %{SERVER_PORT} !^443$ RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R,L]

RewriteCond %{SERVER_PORT} !^443$

RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R,L]

Вариант 3

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

RewriteCond %{ENV:HTTPS} !on

RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Вариант 4

RewriteCond %{HTTP:X-HTTPS} !1 RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

RewriteCond %{HTTP:X-HTTPS} !1

RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Вариант 5

RewriteCond %{HTTP:CF-Visitor} '"scheme":"http"' RewriteRule ^(.*)$ https://www.site.ru/$1 [L]

RewriteCond %{HTTP:CF-Visitor} '"scheme":"http"'

RewriteRule ^(.*)$ https://www.site.ru/$1 [L]

Вариант 6

RewriteCond %{HTTP:X-Forwarded-Protocol} !=https RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

RewriteCond %{HTTP:X-Forwarded-Protocol} !=https

RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

Вариант 7

RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteCond %{HTTPS} off RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]

RewriteCond %{HTTP:X-Forwarded-Proto} !https

RewriteCond %{HTTPS} off

RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]

Вариант 8

RewriteEngine On RewriteCond %{HTTPS} off RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

RewriteEngine On

RewriteCond %{HTTPS} off

RewriteCond %{HTTP:X-Forwarded-Proto} !https

RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

После вставки одного из этих вариантов в файл .htaccess, сохраняете изменения.

Проверка редиректа

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

Так же, вы можете воспользоваться одним из онлайн-сервисов, которые позволяют просмотреть правильность выполнения редиректа. Например, Redirect Checker. Для выполнения проверки вам нужно:

  1. 1.Перейти на страницу онлайн-сервиса по этой ссылке
  2. 2.В поле для ввода указать адрес, с которого должно осуществляться перенаправление в формате http://имя-сайта.ру .
  3. Сервис проверки редиректа
  4. 3.А затем нажать на кнопку «Analyse».

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

Результат проверки перенаправления

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

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

проверка редиректа под поисковую систему

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

Так же, вы можете назначить 301 редирект сразу после получения и установки с SSL-сертификата, но в этом случае вы рискуете тем, что многие страницы вашего сайта могут на время выпасть из поисковой выдачи.

Как научиться продвигать сайты?

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

С уважением Юлия Гусарь

impuls-web.ru

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *