RewriteCond %{REQUEST_URI} !.*index\.html
RewriteRule https://www.%{HTTP_HOST}/index.html [R=302,L]
Există câteva probleme cu asta...
Se pare că îți lipsește RewriteRule model (primul argument) complet, astfel încât această directivă nu se va potrivi.
Dacă aceasta se potrivește, ar fi prefixul www. subdomeniu din nou. Presupun că plasezi această redirecționare după redirecționările canonice (HTTP către HTTPS și non-www către www) - așa cum ar trebui să fiți. Deci, aceasta ar redirecționa către https://www.www.example.com/index.html, deoarece în momentul în care această redirecționare este declanșată, numele de gazdă este deja canonic.
The condiție (RescrieCond directivă) nu este cu adevărat necesară, deoarece această verificare (care /index.html nu este deja solicitat) ar putea fi gestionat mai eficient de către RewriteRule directivă în sine.
De exemplu:
RewriteRule !^index\.html$ /index.html [R=302,L]
Nu este nevoie să includeți schema+numele de gazdă în substituţie șir, deoarece doriți să redirecționați la același oricum. Dacă vrei să fii explicit, poți scrie https://%{HTTP_HOST}/index.html.
Rețineți că, așa cum este, index.html nu poate face referire la niciunul altul local resurse (imagini, CSS, JavaScript etc.), deoarece aceste solicitări vor fi și ele redirecționate. Pentru a permite accesul la resursele locale, ar trebui să adăugați câteva condiții pentru a exclude cererile de resurse statice.
RewriteCond %{REQUEST_URI} !.\.(jpg|png|webp|css|js)$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule !^index\.html$ /index.html [R=302,L]
Alternativ, găzduiți aceste resurse pe un domeniu extern. (Sau într-un subdirector și excludeți întregul subdirector.)
Cu toate acestea, dacă aleg să „redirecționez”, probabil că aș redirecționa către un fișier cu nume mai unic/mai semnificativ, de ex. /coming-soon.html. Problema cu utilizarea /index.html este dacă mai târziu doriți să difuzați conținut diferit pe acea adresă URL și acesta a fost memorat în cache (din orice motiv). Cu toate că /coming-soon.html ar trebui să fie probabil „noindex”.
CU toate acestea, poate fi de preferat să nu redirecționați deloc și să serviți în schimb a temporar Răspuns „503 Service Unavailable”. Vedea raspunsul meu la următoarea întrebare din stiva de webmasteri pentru mai multe informații despre aceasta:
Deoparte:
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [L,R=301]
Sunteți în spatele unui proxy front-end care gestionează conexiunea SSL?
Dacă sunteți, atunci este în regulă, deși a doua condiție care verifică HTTPS variabila server este deci superfluă. Totuși, dacă ești nu în spatele unui proxy SSL, atunci aceste directive sunt vulnerabile la eludare (adică utilizatorul nu este redirecționat către HTTPS) dacă un X-Forwarded-Proto: https antetul este injectat în cerere.
ACTUALIZAȚI:
OK, asta funcționează așa cum vreau eu. Dar le pot combina într-un fel?
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{REQUEST_URI} !.*coming-soon\.html [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}/coming-soon.html [R=302,L]
După cum sa menționat mai sus, ultima regulă este în esență aceeași cu următoarea (atunci când este utilizată în combinație cu redirecționările canonice precedente), care este mai simplă și mai eficientă:
RewriteRule !^coming-soon\.html$ /coming-soon.html [R=302,L]
În a doua regulă, ar trebui să schimbați și RewriteRule model din ^(.*)$ la ^ (la fel ca prima regulă). ^(.*)$ captează în mod inutil o referință în spate și este mai puțin eficient.
Ați menționat într-un comentariu anterior (acum șters) că doriți ca acest lucru să funcționeze și pentru orice subdomeniu. „Funcționează” pentru orice subdomeniu, cu toate acestea, va adăuga întotdeauna un suplimentar www subdomeniu, care poate fi sau nu de dorit? (Nu este obișnuit să aveți un www sub-subdomeniu activat subdomenii. YMMV.)
Nu este nevoie reală de a „combina” aceste reguli. Cu siguranță nu le puteți combina dacă doriți să redirecționați 301 către www+HTTPS înainte de a redirecționa 302 către pagina „în curând”. În timp ce primele două reguli (301 redirecționări) pot fi „combinate” într-o singură regulă, aceasta nu servește la nimic.
Singura problemă minoră aici este că există potențial (cel mult) 2 redirecționări. Mai întâi, un 301 către www+HTTPS pe calea URL originală și un al doilea 302 către pagina „în curând”.
M-aș întreba dacă aveți nevoie de redirecționarea inițială 301 către www+HTTPS atunci când oricum redirecționați utilizatorul către un temporar pagina „în curând”.Odată ce ați implementat noul site (înlocuind pagina „în curând”), atunci veți implementa redirecționarea canonică. Redirecționarea 302 poate redirecționa în continuare către www+HTTPS. (Există, totuși, un caz limită când /coming-soon.html este solicitat direct.)
De exemplu:
# 302 redirecționează către pagina viitoare (www+HTTPS)
RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+?)\.?$
RewriteRule !^coming-soon\.html$ https://www.%1/coming-soon.html [R=302,L]
# Carcasa Edge...
# Următoarele două reguli se aplică numai dacă „/coming-soon.html” este solicitat direct
# și este solicitat fie numele de gazdă non-www și/sau HTTP
# în acest caz 301 redirecționează către același pe www+HTTPS
Lipsește subdomeniul # www...
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
# HTTP + www a fost solicitat
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Orice cerere pentru http://example.com/foo este 302 redirecționat direct către https://www.example.com/coming-soon.html.
Dacă http://example.com/coming-soon.html ar trebui solicitat, atunci este redirecționat către 301 https://www.example.com/coming-soon.html (doar se repară subdomeniul HTTPS și www).
Există cel mult 1 redirecționare externă.
