Depinde unde în <VirtualHost> container pe care plasați aceste directive.
Dacă utilizați un <Directory> container (adică a director context) și dezactivarea .htaccess anulează cu totul (în caz contrar .htaccess va trece peste <Directory> container!), atunci puteți copia aproape directivele așa cum sunt (presupunând că <Directory> container face referire la același director ca și .htaccess dosarul a făcut).
Cu toate acestea, dacă introduceți aceste directive direct în interiorul <VirtualHost> container (în afara unui <Directory> container), adică. într-o virtualhost context, atunci trebuie să faceți unele modificări. Acest lucru se datorează faptului că directivele sunt procesate mai devreme, înainte ca cererea să fie mapată la sistemul de fișiere.
În directivele pe care le-ați postat, ar fi necesare doar două modificări:
Într-o virtualhost contextul, REQUEST_FILENAME variabila server nu a fost încă rezolvată la a nume de fișier. Este la fel ca REQUEST_URI (adică adresa URL care este solicitată). Deci, verificarea sistemului de fișiere va eșua întotdeauna și condiția va avea întotdeauna succes! Fie trebuie să folosiți o privire înainte. de exemplu. %{LA-U:REQUEST_FILENAME}, sau construiți singur numele absolut de fișier. de exemplu. %{DOCUMENT_ROOT}%{REQUEST_URI}. De exemplu:
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
Într-o virtualhost context, calea URL care este potrivită de RewriteRule model este relativ la rădăcină (începând cu o bară oblică). întrucât în .htaccess este relativ la directorul care conține .htaccess fișier - mai puțin prefixul barei oblice. Deci, regula așa cum este scrisă ar avea ca rezultat o dublă bară oblică la începutul căii URL, ar trebui rescrisă astfel:
RewriteRule ^/(.*)$ /$1/ [R,L]
(Cel NC steag nu este necesar aici.)
Sau (de preferință) nu utilizați o referință în spate aici și utilizați REQUEST_URI variabilă server în schimb (care ar funcționa în mod natural în .htaccess de asemenea). De exemplu:
RewriteRule ^ %{REQUEST_URI}/ [R,L]
(Deoparte: Probabil că aceasta ar trebui să fie și o redirecționare permanentă 301 (de ex. R=301). În starea actuală, aceasta va fi implicită la o redirecționare temporară 302. Dar schimbați la un 301 - dacă aceasta este intenția - după ce ați confirmat că funcționează conform intenției.)
Deci, pe scurt, acesta ar deveni:
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteCond %{REQUEST_URI} !^/application-module/(.*)$
RewriteCond %{REQUEST_URI} !(.*)json$ [NC]
RewriteCond %{REQUEST_URI} !playground/local-loader/(.*)$ [NC]
RewriteRule ^/(.*)$ /$1/ [R,L]
Deoparte:
Cele de mai sus pot fi optimizate imediat un pic prin mutarea verificării sistemului de fișiere (care este relativ scump) la ultima condiție și mutarea condiție care verifică dacă cererea nu se termină deja într-o bară oblică RewriteRule directivă. De asemenea, subpatternele regex (.*) în fiecare dintre conditii nu sunt necesare. Deci, cele de mai sus ar putea fi rescrise mai eficient:
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{REQUEST_URI} !^/application-module/
RewriteCond %{REQUEST_URI} !json$ [NC]
RewriteCond %{REQUEST_URI} !playground/local-loader/ [NC]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteRule !/$ %{REQUEST_URI}/ [R,L]
Verificarea sistemului de fișiere poate fi eliminată cu totul dacă, în schimb, excludeți cererile care conțin (așa cum arată) o extensie de fișier, dar aceasta poate depinde de structura fișierului dumneavoastră.
The condiție care verifică !json$ se pare că ar trebui să verifice .json extensia de fișier, de ex. !\.json$. (Acest lucru se leagă de comentariul meu de mai sus despre excludere toate cereri care au o „extensie de fișier”.)
Primul condiție care verifică dacă șirul de interogare este gol pare puțin ciudat (din moment ce nu contează dacă există sau nu un șir de interogare atunci când adăugați o bară oblică la calea URL), dar presupun că aceasta trebuie să fie o cerință specifică?
