RewriteCond %{REQUEST_URI} !.*index\.html
Правило перезаписи https://www.%{HTTP_HOST}/index.html [R=302,L]
С этим есть пара проблем...
Вам, кажется, не хватает Правило перезаписи шаблон (первый аргумент) полностью, поэтому эта директива не будет соответствовать.
Если бы это действительно совпало, это было бы префиксом www. субдомен еще раз. Я предполагаю, что вы ставите это перенаправление после канонические перенаправления (HTTP на HTTPS и без www на www) - как и должно быть. Таким образом, это будет перенаправлено на https://www.www.example.com/index.html, потому что к моменту срабатывания этого перенаправления имя хоста уже является каноническим.
условие (RewriteCond директива) на самом деле не нужна, так как эта проверка (что /index.html еще не запрошен) может более эффективно обрабатываться Правило перезаписи сама директива.
Например:
Правило перезаписи !^index\.html$ /index.html [R=302,L]
Нет необходимости включать схему+имя хоста в замена string, так как вы все равно хотите перенаправить на то же самое. Если вы хотите быть явным, вы можете написать https://%{HTTP_HOST}/index.html.
Обратите внимание, что в нынешнем виде index.html не может ссылаться ни на какие другие местный ресурсы (изображения, CSS, JavaScript и т. д.), поскольку эти запросы также будут перенаправлены. Чтобы разрешить доступ к локальным ресурсам, вам нужно добавить пару условий, чтобы исключить запросы на статические ресурсы.
RewriteCond %{REQUEST_URI} !.\.(jpg|png|webp|css|js)$
RewriteCond %{REQUEST_FILENAME} !-f
Правило перезаписи !^index\.html$ /index.html [R=302,L]
Либо разместите эти ресурсы на внешнем домене. (Или в подкаталоге и исключить весь подкаталог.)
Однако, если бы я вообще решил «перенаправить», я бы, возможно, перенаправил на более уникальный/значимый именованный файл, например. /coming-soon.html. Проблема с использованием /index.html это если вы позже захотите обслуживать другой контент по этому URL-адресу, и он был кэширован (по какой-либо причине). Хотя /coming-soon.html вероятно, должно быть «noindex».
ОДНАКО может быть предпочтительнее вообще не перенаправлять, а вместо этого обслуживать временный Ответ «503 Служба недоступна». Видеть мой ответ на следующий вопрос в стеке веб-мастеров для получения дополнительной информации об этом:
В стороне:
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} выкл.
Правило перезаписи ^(.*)$ https://%{HTTP_HOST}/$1 [L,R=301]
Вы находитесь за внешним прокси-сервером, который управляет SSL-соединением?
Если да, то все в порядке, хотя второе условие, проверяющее HTTPS Поэтому переменная сервера является лишней. Однако, если вы нет за прокси-сервером SSL, эти директивы уязвимы для обхода (т. е. пользователь не перенаправляется на HTTPS), если X-Forwarded-Proto: https заголовок вводится в запрос.
ОБНОВИТЬ:
ОК, это работает так, как я хочу. Но можно ли их как-то совместить?
RewriteCond %{HTTP_HOST} !^www\. [НЗ]
RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTPS} выкл.
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{REQUEST_URI} !.*скоро будет\.html [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}/coming-soon.html [R=302,L]
Как отмечалось выше, последнее правило по сути такое же, как следующее (при использовании в сочетании с предыдущими каноническими переадресациями), которое проще и эффективнее:
RewriteRule !^coming-soon\.html$ /coming-soon.html [R=302,L]
Во втором правиле вы также должны изменить Правило перезаписи шаблон от ^(.*)$ к ^ (аналогично первому правилу). ^(.*)$ излишне фиксирует обратную ссылку и менее эффективен.
Вы упомянули в более раннем комментарии (теперь удаленном), что хотите, чтобы это работало и для любого субдомена. Он «работает» для любого поддомена, однако всегда будет добавляться дополнительный www поддомен, который может быть или не быть желательным? (Необычно иметь www суб-поддомен на поддомены. YMMV.)
Нет никакой реальной необходимости «объединять» эти правила. Вы, конечно, не можете комбинировать их, если вы хотите перенаправить 301 на www + HTTPS до перенаправления 302 на страницу «скоро». Хотя первые два правила (редиректы 301) можно «объединить» в одно правило, это бесполезно.
Единственная незначительная проблема здесь заключается в том, что потенциально (максимум) 2 перенаправления. Во-первых, 301 на www+HTTPS по исходному URL-адресу, а второй 302 на страницу «скоро».
Я бы спросил, действительно ли вам нужно первоначальное перенаправление 301 на www + HTTPS, когда вы все равно перенаправляете пользователя на временный страница "скоро".После того, как вы внедрили новый сайт (заменив страницу «скоро»), вы должны реализовать каноническую переадресацию. Перенаправление 302 по-прежнему может перенаправлять на www+HTTPS. (Однако существует пограничный случай, когда /coming-soon.html запрашивается напрямую.)
Например:
# 302 редирект на ближайшую страницу (www+HTTPS)
RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+?)\.?$
RewriteRule !^coming-soon\.html$ https://www.%1/coming-soon.html [R=302,L]
# Пограничный случай...
# Следующие два правила применяются, только если "/coming-soon.html" запрашивается напрямую
# и запрашивается имя хоста без www и/или HTTP
# в этом случае 301 редирект на то же на www+HTTPS
# субдомен www отсутствует...
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
# HTTP + www был запрошен
RewriteCond %{HTTPS} выкл.
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Любой запрос на http://example.com/foo 302 перенаправляется прямо на https://www.example.com/coming-soon.html.
Если http://example.com/coming-soon.html должен быть запрошен, тогда он 301 перенаправляется на https://www.example.com/coming-soon.html (просто исправляя поддомен HTTPS и www).
Существует не более 1 внешнего перенаправления.
