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

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

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

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

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

1. В папке, в которой должны выполняться скрипты CGI, создайте файл . 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 уже сами по себе являются сжатыми форматами. 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>

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

   В этой скромной статье описано далеко не все. 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 и пробуем мерить красоту до и после.

   Думаю, получился у Вас htaccess!

    

   Переадресация на https в htaccess, примеры и тестирование

   Эта статья рассказывает л настройке автоматического редиректа клиента сервера Apache на использование защищенного протокола HTTPS. Статья содержит примеры кода и рассказывает об особенностях применения.

   Фрагменты кода htaccess для переадресации http на https

   Есть несколько вариантов записи условия и правила переадресации.

   index\.php$ — [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /blog/index.php [L] </IfModule> # END WordPress …

   Особенности, связанные со структурой каталогов

   Встречаются конфигурации веб-серверов с несколькими файлами .htaccess – если на веб-сервере используются CMS в подкаталогах:, например, в папке /blog/ находится блог на WordPress, а в папке /forum/ находится конференция PHPBB, то оказывается, что на сервере будет не один файл .htaccess, а несколько – в данном примере три.

   /root
       .htaccess
       /blog
           .htaccess
       /download
       /forum
           .htaccess
       /picture

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

   . htaccess.

   Проверка работы редиректа на https и решение проблем

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

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

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

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

   И, наконец, остаётся проверить работу переадресации с обновленными файлами .htaccess. Это необходимо сделать для каждого каталога со своим .htaccess. То есть если на сайте три файла ,htaccess, как в примере выше, то нURL из корневого каталога сайта, из блога и из форума. На каждой из них должна произойти переадресация с http на https.

   Если какой-то из .htaccess не сработал, проверьте, что код в него был добавлен правильно. Для WordPress важно, чтобы код был вставлен до строк WordPress.

   После этого автоматический переход на https будет работать для всех страниц сайта.

   Узнать больше

   How directives are applied — Apache HTTP Server Tutorial: .htaccess files — описание, в каком порядке применяются директивы для нескольких .htaccess в разных каталогах.

   Переадресация на https в htaccess, примеры и тестирование

   Убедиться, что .htaccess и mod_rewrite работают должным образом

   Перейти к навигации по документации

   Bolt широко использует общую функцию, называемую «перезапись URL». Этот в основном означает, что вы можете запросить красивый URL-адрес, например /page/about-this-website . в вашем браузере, а за кулисами ваш веб-сервер просто «переведет» это для запуска index. php с правильными параметрами, чтобы Bolt мог произвести правильная страница для вас.

   Это не работает из коробки на всех веб-серверах, но это сложно Требования к использованию Bolt. Если вы читаете эту страницу, вы, вероятно, находитесь в процесс настройки Bolt и после запроса первой страницы вы были перенаправлены на страницу

   /bolt/userfirst , где вы увидели следующее сообщение об ошибке:

   Одна из трех следующих возможностей создает проблемы:

   • Вы потеряли файл .htaccess
   • Apache полностью игнорирует .htaccess
   • Mod_rewrite не включен

   Проверить, работает ли

   .htaccess ¶

   Самый простой способ проверить, использует ли apache ваш файл .htaccess или нет. игнорирует его, это намеренно сломать его.

   Отредактируйте файл .htaccess так, чтобы первая строка читалась как «Тест.»:

    Тест.
   # Установить обработчик по умолчанию
   DirectoryIndex index. php index.html index.htm
   ...
    

   Теперь, если вы обновите страницу в браузере, вы должны увидеть страницу с ошибкой, например это:

   Если вы видите эту ошибку, это на самом деле хорошо

   ! Это означает, что Apache анализируя файл .htaccess , он обнаруживает ошибку, которую мы туда записали! Так далеко, так хорошо!

   Если вы делаете , а не , видите «Внутреннюю ошибку сервера», ваша установка Apache игнорирует .htaccess , и вам нужно это исправить. Как правило, Apache игнорирует .htaccess из-за следующей конфигурации Apache AllowOverride нет . Проверьте конфигурацию виртуального хоста и добавьте/измените AllowOverride All .

   Пример:

    <Каталог /var/www/site/example.com/>
           Индексы опционов FollowSymLinks
           Разрешить переопределить все
           Требовать все предоставленные
        

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

   • Загрузите скрипт здесь: htaccess_tester.php на GitHub
   • Переименуйте его в htaccess_tester.php , если необходимо.
   • Поместите его в папку, куда вы положили Bolt.
   • Откройте его в браузере с URL-адресом. (поэтому убедитесь, что вы не получаете к нему доступ в виде файла :// )
   • Если вы получили сообщение об ошибке, вам нужно будет исправить ее, убедившись, что .htaccess файл существует и доступен для чтения.

   Правильно:

   Проверить, работает ли

   mod_rewrite ¶

   Чтобы проверить правильность работы mod_rewrite , выполните следующие действия:

   • Загрузите скрипт здесь: htaccess_tester.php на GitHub
   • Переименуйте его в htaccess_tester.php , если необходимо.
   • Поместите его в папку, куда вы положили Bolt.
   • Создайте файл .
     .*$ htaccess_tester.php
     • В браузере откройте /test с правильным доменным именем. Таким образом, это должно выглядеть как http://localhost/test или http://example.org/test .
     • Если вы видите следующее, это работает! Если вы видите что-то еще, вам понадобится исправить это.

     Правильно:

     Мой htaccess не работает? Что делать?¶

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

     Включите

     .htaccess в вашем httpd.conf или apache.conf ¶

     Необычно, но возможно, что .htaccess не включен на вашем сайте. Если вы размещаете его самостоятельно, это достаточно легко исправить. Откройте свой httpd.conf или apache.

     conf в текстовом редакторе и найдите раздел :

      <Каталог "/var/www/htdocs">
         Аллововеррайд Нет 

     Изменить AllowOverride строка на:

      Разрешить переопределение всех 

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

     Если ваш сайт размещен в другом месте, проверьте панель управления (Plesk, DirectAdmin, CPanel, что угодно), чтобы узнать, можно ли включить там .htaccess . Если нет, обращайтесь ваш хостинг-провайдер, чтобы сделать это за вас.

     Включить

     mod_rewrite в Apache¶

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

     на разных установках: Как включить mod_rewrite для Apache 2.2.

     Проверка файлов журналов Apache¶

     Apache регистрирует партий материалов. Проверьте журналы «доступа» и «ошибки», созданные Apache, чтобы узнать, содержат ли они ценную информацию. Обычное место для этих файлов /var/log/apache2/ , но он может находиться по другому пути на вашем система. Проверьте файл apache .conf , чтобы увидеть, где эти файлы могут быть скрыты.

     Включение Rewritebase¶

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

     Изменить

      # Некоторые серверы требуют установки RewriteBase. Если это так, установите правильную папку.
       # Переписать базу / 

     до:

      # Некоторые серверы требуют установки RewriteBase. Если это так, установите правильную папку.
       Переписать базу / 

     Переместите свой сайт на «верхний уровень»¶

     Если вы настраиваете Bolt во вложенной папке и предыдущий совет не работает, вы можно попробовать настроить Bolt на собственном поддомене, так как это обычно дает меньше проблемы. Итак, вместо использования http://example.org/testingbolt настройте его как http://testingbolt.example.org/ .

     Свяжитесь с вашим веб-хостингом¶

     Спросите своего веб-хостинга, что может быть не так. Чем больше информации вы им дадите, тем больше шанс, что они могли бы быть в состоянии помочь вам.

     Использовать предварительно настроенную сборку Apache¶

     Если вы настраиваете Apache на своем компьютере, а он оказывается сложно настроить, вам следует рассмотреть возможность использования XAMPP (Windows), MAMP (OS X) или AMPPS (Windows, OS X, Linux).

     Вместо этого используйте Nginx¶

     Если вам надоели махинации Apache, вы можете подумать о том, чтобы отказаться от них в в пользу Nginx. Nginx — высокопроизводительный веб-сервер, который на самом деле проще настроить, чем Apache.

     Предыдущий Запуск Bolt с использованием встроенного веб-сервера PHP

     Следующий Настройка сертификатов центра сертификации cURL SSL/TLS

     apache 2.

     2 - Как выполнить проверку синтаксиса файла .htaccess в среде общего хостинга?

     спросил 13 лет, 2 месяца назад

     Изменено 2 года, 5 месяцев назад

     Просмотрено 10 тысяч раз

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

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

     Приветствуются идеи и предложения.

     • apache-2.2
     • .htaccess
     • perl
     • синтаксис
     1

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

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

     2

     Вот два полезных бесплатных сервиса:

     Этот сервис позволяет загружать .htaccess файл для проверки.
     Позволяет вставить содержимое файла .htaccess в текстовое поле для проверки.

     2

     Самой надежной проверкой синтаксиса является сам Apache.

     Если вы можете справиться с 500 мс возможного простоя (время, необходимое для отправки http-запроса к локальному хосту, очень приблизительно), сделайте следующее:

     1. Сделайте резервную копию текущего файла htaccess
     2. Заменить текущий файл htaccess файлом для проверки
     3. Сделать запрос к серверу, например "curl localhost"
     4. Если curl не удался, поместите резервную копию обратно
     2

     Используя крутые текстовые редакторы, такие как Coda для Mac или TextMate для Mac или Notepad++ для ПК, вы можете включить подсветку синтаксиса, что может быть не идеально, но будет полезно.