.htaccess — файл для налаштування веб-сервера Apache. З його допомогою можна обмежити доступ до сайту на основі різних параметрів, налаштувати редиректи, захистити картинки від крадіжки, прискорити роботу сайту за допомогою стиснення та кешування і ще багато чого корисного.
У цій статті ви дізнаєтесь про основні особливості .htaccess, а також знайдете приклади команд, які допоможуть покращити роботу вашого сайту.
Зміст
- Що таке .htaccess і навіщо він потрібний
- Де знаходиться .htaccess
- Як створити файл .htaccess
- Синтаксис .htaccess
- Як налаштувати .htaccess
- Якщо .htaccess не працює
Що таке .htaccess і навіщо він потрібен
Інформація у цьому розділі — для загального розуміння. Ми спеціально почнемо трохи здалеку і трохи все спростимо, щоб було зрозуміло навіть новачкам.
Для роботи сайтів в інтернеті використовується спеціальна програма — веб-сервер. Вона обробляє запити користувачів і вирішує, як на них відповісти: показати запитувану сторінку, зробити редирект або взагалі заборонити доступ.
Найпопулярніший веб-сервер називається Apache. Більшість сайтів працюють саме завдяки ньому. Налаштовується Apache за допомогою конфігураційних файлів. Це текстові файли, де прописують спеціальні команди (директиви, правила), які вказують веб-серверу, як поводитися при обробці різних запитів.
Головний кофігураційний файл Apache називається httpd.conf або apache.conf (залежно від дистрибутива ОС). По можливості команди рекомендується вказувати саме в ньому, але до нього не завжди доступ.
Наприклад, доступу до httpd.conf немає на віртуальному хостингу, де на одному сервері зазвичай працюють сотні сайтів. У такій ситуації давати всім користувачам доступ до основного конфігураційного файлу небезпечно, адже тоді будь-хто зможе змінити налаштування інших користувачів.
Для таких випадків і вигадали файл .htaccess. Директиви в ньому поширюються лише на каталог, в якому він знаходиться, і на всі дочірні каталоги. Це дозволяє встановлювати для окремих каталогів на сервері свої параметри Apache, які відрізнятимуться від основної конфігурації.
В результаті доступ до головного файлу є тільки у провайдера хостингу, а клієнти можуть трохи змінити параметри веб-сервера конкретно для свого облікового запису за допомогою .htaccess.
.htaccess — додатковий конфігураційний файл Apache. З його допомогою можна змінювати параметри веб-сервера в окремих папках, без змін в основному конфігураційному файлі.
Де знаходиться .htaccess
Зазвичай файл .htaccess розміщують , щоб ефект від команд поширювався одразу на весь сайт. Як ми писали в попередньому розділі, .htaccess діє на папку, в якій знаходиться, а також на всі дочірні папки.
Якщо ви не знаходите .htaccess в кореневій папці, можливо, він просто прихований і вам потрібно увімкнути відображення прихованих файлів.
У дочірніх папках можуть бути додаткові файли .htaccess — щоб різні розділи сайту мали різні параметри веб-сервера. Але в більшості випадків одного .htaccess цілком достатньо.
Приклад ситуації, коли може бути вигідно створити кілька .htaccess файлів — у вас великий проект, де задіяно декілька CMS. Умовно кажучи, головний сайт зроблено на одній CMS, а блог на WordPress.
Як створити файл .htaccess
На локальному комп’ютері створити .htaccess можна за допомогою будь-якого текстового редактора. Просто створіть новий текстовий документ та збережіть його з правильним ім’ям.
На хостингу .htaccess можна створити за допомогою командного рядка, FTP-клієнта або панелі керування хостингом.
Ім’я файлу — .htaccess. Обов’язково з точкою на початку та обов’язково маленькими літерами. Для Apache .Htaccess та .htaccess це різні файли. Також файл не повинен мати розширення: .htaccess.txt це вже не те, потрібно саме .htaccess.
Синтаксис .htaccess
Кожна директива має починатися з нового рядка. Між групами непов’язаних один з одним директив зазвичай залишають один порожній рядок, щоб простіше було читати файл.
До директив у .htaccess можна додавати коментарі за допомогою символу #, щоб ще більше підвищити читабельність файлу. Усі рядки, які починаються з цього символу, веб-сервер ігноруватиме.
Також можна використовувати символ #, щоб вимкнути директиву, не видаляючи її з файлу. Просто встановіть цей символ на початку рядка. Мовою сисадмінів це називається «закоментувати».
Ось фрагмент .htaccess для прикладу, як можна оформити файл:
# 301 редиректи
Redirect 301 /blog/old-article-1/ https://vashdomen.com/blog/new-article-1/
Redirect 301 /blog/old-article-2/ https://vashdomen.com/blog/new-article-2/
Redirect 301 /blog/old-article-3/ https://vashdomen.com/blog/new-article-3/
# Редирект з www на без www
RewriteCond %{HTTP_HOST} ^www.vashdomen.com$ [NC]
RewriteRule ^(.*)$ http://vashdomen.com/$1 [R=301,L]
# Свої сторінки з помилками
ErrorDocument 403 /errors/403.html
ErrorDocument 404 /errors/404.html
ErrorDocument 500 /errors/500.html
ErrorDocument 504 /errors/504.html
# Максимально допустимий час виконання скрипту PHP (у секундах)
php_value max_execution_time 60
Правила для .htaccess
У цьому розділі розглянемо декілька популярних можливостей .htaccess, які допоможуть покращити роботу вашого сайту. Це не всі доступні директиви, а лише ті, які на наш досвід використовують найчастіше. Якщо чогось важливого не вистачає, поділіться своєю думкою у коментарях.
Зміни набирають чинності одразу після збереження файлу. Перезавантаження веб-сервера не потрібне (на відміну від змін httpd.conf). Але кеш браузера ніхто не скасовував, тому для перевірки директив рекомендуємо використовувати інкогніто режим у браузері.
Обмежити доступ до сайту
Найчастіше це потрібно, щоб заблокувати доступ до сайту для конкретних IP-адрес. Наприклад, якщо на сайт йде DDoS-атака, або хтось регулярно залишає спамні коментарі.
Можна вказувати IP-адреси по одному, а можна заблокувати цілий діапазон. Для цього або вкажіть частину IP-адреси у форматі 123.45.*.* або вирахуйте більш точний діапазон у форматі CIDR за допомогою спеціального калькулятора.
# Заборонити доступ до сайту з конкретних IP-адрес Order Allow,Deny Allow from all Deny from 123.45.67.89 Deny from 111.22.33.44 # Заборонити доступ для будь-яких IP, які починаються з 111.22 Deny from 111.22.*.* # Заборонити доступ до діапазону 111.22.33.0 – 111.22.33.199 Deny from 111.22.33.0/25 Deny from 111.22.33.128/26 Deny from 111.22.33.192/29
Якщо потрібно навпаки, заборонити доступ для всіх, але дозволити для конкретних IP (наприклад, на час розробки сайту) використовуйте таку команду:
# Дозволити доступ до сайту лише з конкретних IP-адрес Order Deny,Allow Deny from all Allow from 123.45.67.89 Allow from 111.22.33.44
Можна також заборонити доступ не до всього сайту, а лише до якогось конкретного файлу. Наприклад, конфігураційного файлу бази даних. У ньому зберігається пароль від бази, тому до нього ніколи не повинна отримати доступ стороння людина.
Якщо у вас сайт WordPress, конфігураційний файл бази даних називається wp-config.php. Закрити до нього доступ ззовні можна за допомогою такої команди:
# Заборонити доступ до wp-config.php <Files wp-config.php> Order Allow,Deny Deny from all </Files>
Так само можна заблокувати доступ ззовні до цілої групи системних файлів. Для цього використовується директива FilesMatch. Вона працює так само, як і Files, але підтримує регулярні вирази.
# Заборонити доступ до системних файлів <FilesMatch ".(htaccess|htpasswd|ini|phps|fla|psd|log|sh)$"> Order Allow,Deny Deny from all </FilesMatch>
Ну і останній лайфхак — дозволити доступ до адмінки сайту тільки з певних IP-адрес. Наприклад, з вашого домашнього IP або адреси вашого офісного VPN.
Для сайту WordPress для цього достатньо закрити доступ до файлів wp-login.php і xmlrpc.php. Робиться це за допомогою такої команди:
# Дозволити доступ до адмінки WordPress тільки з конкретних IP-адрес <FilesMatch "^(wp-login.php|xmlrpc.php)$"> Order deny,allow Deny from all Allow from 123.45.67.89 Allow from 111.22.33.44 </FilesMatch>
Налаштувати доступ до сайту за паролем
Ще один спосіб обмежити доступ до сайту — зробити так, щоб він відкривався за паролем.
Як і у випадку з блокуванням за IP-адресою, можна використовувати директиву у звичайному вигляді, щоб пароль встановився на всю папку, де лежить .htaccess. А можна обернути директиву в тег <Files> або <FilesMatch>, щоб встановити пароль для одного або декількох файлів.
В результаті при спробі зайти на сайт або отримати доступ до файлу відвідувач побачить таку форму для введення пароля:
Для прикладу встановимо пароль лише для сторінки входу до адмінки WordPress. У разі, якщо хтось надумає підібрати пароль до адмінки, йому спочатку доведеться підібрати пароль до сторінки, де він збирався підбирати пароль, хе-хе.
Можливо, такий варіант захисту адмінки буде для вас зручнішим, ніж блокувати до неї доступ за IP-адресою. Так, доведеться вводити два паролі замість одного, зате можна буде підключитися звідки завгодно.
# Доступ до сторінки входу в адмінку WordPress за паролем <FilesMatch "^(wp-login.php|xmlrpc.php)$"> AuthType basic AuthName "Directory Name" AuthUserFile /home/username/public_html/auth/.htpasswd Require valid-user </FilesMatch>
У цій команді:
- AuthType — тип аутентифікації. Рекомендуємо використовувати значення «basic».
- AuthName — це текст, який відвідувач повинен бачити у вікні введення пароля. Але насправді я ніколи не бачив, щоб він там відображався. Тож не так важливо, що ви сюди впишете.
- AuthUserFile — шлях до файлу .htpasswd з логінами та паролями дозволених користувачів.
- Require — вимога для доступу до папки. Значення «valid-user» говорить про те, що доступ отримають лише користувачі, які успішно пройшли аутентифікацію.
Після додавання правила до .htaccess потрібно також створити файл .htpasswd, де будуть логіни та паролі користувачів. Краще створювати його не в кореневій папці сайту, а в якійсь вкладеній, щоб до нього не можна було просто дістатися. Наприклад, у папці /auth.
У записів у файлі .htpasswd має бути формат «користувач: пароль». Але для безпеки паролі краще не зберігати у файлі у відкритому вигляді, а зашифрувати. Для цього зайдіть на сайт генератора .htpasswd, введіть там логін з паролем і натисніть «Сгенерировать».
Скопіюйте рядок і додайте його до файлу .htpasswd. Деталі входу для кожного нового користувача в цьому файлі повинні йти з нового рядка. На сайті використовуйте звичайну версію пароля, зашифрована потрібна тільки для того, щоб не зберігати пароль у відкритому вигляді.
Заблокувати ботів
Якщо ви помітили, що сайт почав повільніше працювати, тому що його сканують різні роботи, забороніть їм це робити за допомогою такої директиви:
# Блокування ботів SetEnvIfNoCase User-agent (Abonti|AhrefsBot|Aport|AspiegelBot|asterias|Baiduspider|BDCbot|Birubot|BLEXBot|BUbiNG|BuiltBotTough|Bullseye|BunnySlippers|Butterfly|CamontSpider|CCBot|Cegbfeieh|CheeseBot|CherryPicker|coccoc|CopyRightCheck|cosmos|crawler|Crescent|DeuSu|discobot|DittoSpyder|DnyzBot|DomainCrawler|DotBot|EasouSpider|EmailCollector|EmailSiphon|EmailWolf|EroCrawler|Exabot|ExtractorPro|Ezooms|FairShare|Fasterfox|FeedBooster|Foobot|Genieo|Gigabot|GrapeshotCrawler|Harvest|hloader|HTTrack|humanlinks|HybridBot|Incutio|InfoNaviRobot|InternetSeer|IstellaBot|JamesBOT|JennyBot|k2spider|kmSearchBot|larbin|LexiBot|libWeb|libwww|Linguee|LinkExchanger|LinkextractorPro|linko|LinkWalker|lmspider|LNSpiderguy|magpie|MaxPointCrawler|MegaIndex|memoryBot|MIIxpc|Mippin|MJ12bot|MLBot|moget|MSIECrawler|NetAnts|NetpeakCheckerBot|NICErsPRO|NjuiceBot|NPBot|Nutch|OLEcrawler|Openfind|PostRank|ProWebWalker|Purebot|PycURL|RepoMonkey|Riddler|RMA|Scrapy|SemrushBot|serf|SeznamBot|SISTRIX|SiteBot|SiteSnagger|Serpstat|Slurp|SnapPreviewBot|Sogou|Soup|SpankBot|spanner|spbot|Spinn3r|SpyFu|suggybot|SurveyBot|suzuran|SWeb|Teleport|Telesoft|TheNomad|TightTwatBot|Titan|True_Robot|ttCrawler|turingos|TurnitinBot|UbiCrawler|UnisterBot|Unknown|VCI|Vedma|Voyager|WBSearchBot|WebAuto|WebBandit|WebCopier|WebEnhancer|WebmasterWorldForumBot|WebReaper|WebSauger|WebStripper|Wotbox|Yeti|YottosBot|Zao|Zeus|ZyBORG) not-allowed=1 Order Allow,Deny Allow from ALL Deny from env=not-allowed
Це лише деякі боти, взагалі їх набагато більше. Якщо директива не має бота, який навантажує ваш сайт, додайте його самостійно.
Заборонити індексацію каталогів
За замовчуванням, якщо хтось безпосередньо звернеться до якогось каталогу у вас на хостингу, веб-сервер покаже його вміст. В результаті будь-який зможе покопатися у ваших файлах, завантажити їх і в гіршому випадку знайти вразливості.
Такі речі обов’язково треба забороняти. Не потрібно ризикувати безпекою вашого сайту. У .htaccess це робиться за допомогою директиви Options. Вона зробить так, щоб при прямому зверненні до каталогу виникала 403 помилка:
# Заборонити індексацію каталогів Options -Indexes
Налаштувати редирект
У цьому розділі розглянемо кілька найбільш популярних ситуацій, коли потрібно налаштувати редирект. Але взагалі це велика тема з купою нюансів. Докладно розглядаємо їх в окремій статті:
Як зробити 301 редирект у .htaccess
Редирект з однієї сторінки на іншу (якщо змінили URL-адресу сторінки):
Redirect 301 /old-url-1 /new-url-1
Редирект з одного файлу в кореневій папці сайту на інший (якщо змінили назву файлу):
Redirect 301 /contact-us.php/contact.php
Редирект усіх сторінок сайту на такі ж сторінки на іншому домені:
Redirect 301 / https://vashdomen.ua/
Редирект усіх файлів з розширенням .html на такі ж файли з розширенням .php:
RedirectMatch 301 (.*).html /$1.php
Перенаправлення домену без www на домен з www:
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www..* [NC]
RewriteRule ^(.*) http://www.%{HTTP_HOST}/$1 [R=301]
І навпаки — перенаправлення домену з www на домен без www:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.(.*)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]
Примусове перенаправлення з HTTP на HTTPs (попередньо потрібно встановити SSL-сертифікат):
RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Захистити картинки від крадіжки
Інша назва такого налаштування — захист від хотлінкінгу (від англ. hotlinking — використання прямих посилань).
Ідеться про ситуацію, коли хтось розмістив у себе на сайті зображення за посиланнями на ваш сервер. У результаті виходить так, що зображення завантажуються з вашого сервера, але трафік йде на чужий сайт. Тобто хтось нишком витрачає ресурси вашого хостингу. Відучити від цього можна за допомогою такої директиви:
# Заборона на крадіжку картинок (hotlinking)
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https://(www.)?vashdomen.com/.*$ [NC]
RewriteRule .(gif|jpg|swf|flv|png)$ https://www.vashdomen.com/feed.gif [R=302,L]
Працює ця директива так: ви розміщуєте у себе на сервері спеціальне зображення для таких злодіїв, і коли вони розміщують будь-яке ваше зображення у себе на сайті, замість нього відображається саме заготовлена картинка.
Що саме завантажити як заготовлену картинку — справа ваша. Можете намалювати у фотошопі плакат «Я краду чужі картинки» або банер із рекламою власних послуг. Тут все залежить від вашої фантазії та бажання покарати хитрунів.
Шлях до зображення для злодюжок вказується в директиві RewriteRule.
Призначити свої сторінки помилок
Якщо хочете відображати замість стандартних сторінок з помилками сторінки зі своїм дизайном, використовуйте таку директиву:
# Свої сторінки помилок ErrorDocument 403 /errors/403.html ErrorDocument 404 /errors/404.html ErrorDocument 500 /errors/500.html ErrorDocument 504 /errors/504.html
У цій директиві /errors/403.html це абсолютний шлях до файлу сторінки (без урахування доменного імені).
Повний список кодів стану ви знайдете в статті «Коди стану HTTP». Не обов’язково створювати свою сторінку для кожного коду, можна тільки для найпоширеніших помилок: 404 Not Found та 500 Internal Server Error.
В ідеалі нова сторінка помилки повинна бути не тільки красивою, але й простими словами пояснювати причини помилки, а також містити посилання, щоб відвідувач міг повернутися на сайт.
Налаштувати стиснення файлів
Для цього Apache використовується модуль mod_deflate. У прикладі перелічені не всі типи файлів. Якщо потрібно, додайте вручну типи, яких бракує.
# Стиснення для файлів HTML, CSS, JavaScript, Text, XML та шрифтів AddOutputFilterByType DEFLATE application/javascript application/x-javascript application/xml application/xhtml+xml image/svg+xml text/css text/html text/javascript text/plain text/xml
Налаштувати кешування
Встановлюємо скільки часу (в секундах) у браузері відвідувача повинні зберігатися файли тих чи інших типів. У прикладі перелічені не всі типи файлів. Якщо потрібно, додайте вручну типи, яких бракує.
# Вмикаємо модуль mod_expires ExpiresActive On # Кеш за замовчуванням — 5 секунд ExpiresDefault "access plus 5 seconds" # Кешувати зображення на місяць ExpiresByType image/x-icon "access plus 2592000 seconds" ExpiresByType image/gif "access plus 2592000 seconds" ExpiresByType image/jpeg "access plus 2592000 seconds" ExpiresByType image/png "access plus 2592000 seconds" # Кешувати HTML и CSS-файли на тиждень ExpiresByType text/css "access plus 604800 seconds" ExpiresByType text/html "access plus 604800 seconds" # Кешувати скрипти на день ExpiresByType text/javascript "access plus 86400 seconds" ExpiresByType application/x-javascript "access plus 86400 seconds"
Змінити параметри PHP
Збільшити час очікування веб-сервера під час виконання скрипту. Допоможе уникнути зависання веб-сервера під час обробки важких скриптів.
# Час очікування веб-сервера під час виконання скрипту php_value max_execution_time 60
Визначити максимальний розмір файлу, який можна завантажити (у прикладі — 128 Мб):
# Максимальний розмір файлу, що завантажується php_value upload_max_filesize 128M
Вивести помилки РНР в окремий файл:
# Виведення помилок PHP в окремий файл php_flag log_errors on php_value error_log /home/username/public_html/php_errors.log
У цій директиві /home/username/public_html/php_errors.log шлях до файлу з логами. Не забудьте змінити його.
Ці директиви не завжди підтримуються на віртуальному хостингу. Наприклад, у нас на віртуальному хостингу їх використовувати вийде лише на VPS. Причина в тому, що веб-сервер, який працює в режимі suPHP, не підтримує директиви php_flag та php_value.
Рішенням у цій ситуації буде використовувати розділ «Select PHP Version» у панелі керування cPanel. Там також можна змінити ці параметри. Альтернативний варіант — створити локальний файл php.ini та прописати ліміти в ньому.
Змінити кореневий каталог сайту
Зазвичай на віртуальному хостингу файли сайту розміщують в кореневому каталозі домену. За замовчуванням для основного домена цей каталог називається public_html, а для додаткового — так само як і сам домен.
У деяких фреймворках зустрічається інша структура, в якій файли проекту лежать не в кореневому каталозі домену, а в підкаталозі. Наприклад, Laravel, де файли проекту лежать у підкаталогу /public. Через це, після того як ви завантажите проект на хостинг і введете в браузері ваш домен, ви побачите список всіх папок і файлів замість сайту.
Рішення в такій ситуації — додати в .htaccess такий редирект, який буде спрямовувати всі запити в підпапку:
RewriteEngine On
RewriteCond %{REQUEST_URI} !/public
RewriteRule ^(.*)$ public/$1 [L]
Якщо .htaccess не працює
Коли ви додаєте правило до .htaccess і не спостерігаєте очікуваного ефекту, причина не завжди очевидна. Особливо на віртуальному хостингу, де немає доступу до основних логів веб-сервера. Ось основні причини, чому так може бути.
Причина №1: .htaccess вимкнено в httpd.conf
Можливість використання .htaccess прописується в головному конфігураційному файлі Apache за допомогою директиви AllowOverride. Якщо вона вказана зі значенням None, веб-сервер ігноруватиме .htaccess.
Така проблема може бути лише на VPS або виділеному сервері. Якщо у вас віртуальний хостинг, справа 100% у чомусь іншому.
Причина №2: Директиву не можна використовувати у .htaccess
Ще одна особливість директиви AllowOverride — з її допомогою можна дозволити в .htaccess всі директиви, а можна лише окремі групи директив. Докладніше про цю директиву читайте в офіційній документації Apache.
# Дозволити у .htaccess всі директиви AllowOverride All # Дозволити в .htaccess тільки директиви груп «Limit» та «FileInfo» AllowOverride Limit FileInfo
Ще є директива AllowOverrideList, за допомогою якої можна перерахувати конкретні директиви, які дозволені в .htaccess (а не групи директив, як у випадку AllowOverride). Докладніше про цю директиву читайте в офіційній документації Apache.
# Заборонити всі директиви, крім директив Redirect та RedirectMatch AllowOverride None AllowOverrideList Redirect RedirectMatch # Дозволити групу директив «AuthConfig» # Дозволити директиви CookieTracking та CookieName із групи «FileInfo» AllowOverride AuthConfig AllowOverrideList CookieTracking CookieName
Може бути так, що при спробі використати заборонену директиву в .htaccess виникне помилка 500 Internal Server Error. Але це не обов’язково: AllowOverride має також параметр Nonfatal, завдяки якому можна не виводити помилку, а просто робити запис у логах.
Перевірити логи помилок вдасться лише у користувачів VPS або виділеного сервера. На віртуальному хостингу до цих логів доступу немає.
Причина №3: Неправильний синтаксис директиви
У випадку з друкарською помилкою результат може бути таким самим, як ніби директива була забороненою — помилка 500 Internal Server Error. Якщо адміністратор сервера не вимкнув таку поведінку за допомогою Nonfatal у головному конфігураційному файлі.
Якщо хочете, можете перевірити вміст файлу на друкарські помилки за допомогою спеціального сервісу — валідатора .htaccess.
Причина №4: Неправильна назва файлу
Ім’я файлу повинне починатися з крапки, в ньому повинні бути лише маленькі літери і не повинно бути розширення. Файл буквально називається .htaccess. Не htaccess, не .htaccess.txt і не .Htaccess.
Теоретично, справа також може бути в тому, що стандартне ім’я .htaccess змінили в головному конфігураційному файлі веб-сервера. Це робиться за допомогою директиви AccessFileName. Наприклад, ось так:
# Змінити ім'я файлу .htaccess AccessFileName .config
Причина №5: На сервері кілька файлів .htaccess
Правила .htaccess виконуються у послідовності, в якій їх знайшов Apache. Тобто спочатку директиви з .htaccess у кореневій папці, потім директиви з .htaccess у дочірніх папках. Через це може статися так, що директиви у файлі, який розташований глибше в дереві каталогів, перезапишуть директиви з файлів, які знаходяться вище.
Причина №6: Неправильна послідовність директив
Найчастіше таке буває з директивами для редиректу RewriteRule. Якась директива, яка стоїть вище, може перетворити URL-запит таким чином, що він більше не підходитиме під умови в наступних директивах. При цьому сама по собі директива може бути складена правильно.
Щоб перевірити цей сценарій, спробуйте переставити непрацюючу директиву на початок .htaccess і повторно зберегти файл.
Що далі
Сподіваємося, стаття була для вас корисною. Якщо ви знайшли помилку або у статті не вистачає якоїсь важливої інформації, поділіться своїми думками у коментарях.