Mam to w swoim htaccess, ale nie mogę zrozumieć, do czego to służy. Z uwagi na naturę reguły wyszukiwanie również nie pomaga.
RewriteCond %{REQUEST_URI} !(/$|\.)
RewriteRule (.*) %{REQUEST_URI}/ [R=301]
Czy ktoś może wyjaśnić, po co to jest?
linux
apache-2.2
apache-2.4
.htaccess
mod-rewrite
Richard1984
źródło
źródło
/
i nie zawiera „.
”, przekieruj żądanie, dołączając je do/
. Prawdopodobną intencją tej reguły jest obsługa automatycznego indeksowania katalogów.Odpowiedzi:
Cała ta reguła nie jest dodanie końcowego znaku
/
do adresów URL, jeśli nie ma nikogo, a jeśli nie ma to.
w URI, więchttps://example.org/test
zostanie przekierowany dohttps://example.org/test/
, alehttps://example.org/test.html
nie zostaną zapisane, abyhttps://example.org/test.html/
(ale uwaga:https://example.org/test.case/folder
również nie zostać przekierowanyhttps://example.org/test.case/folder/
ponieważ zawiera a.
w URI).źródło
/test.case/folder
również nie zostanie przekierowany” - Drobny punkt, ale jeśli „folder” jest katalogiem systemu plików, to mod_dir (domyślnie) wyda przekierowanie 301 w celu dołączenia ukośnika końcowego. To tylko problem, jeśli/test.case/some-other-virtual-url
powinien mieć ukośnik końcowy.Bez sprawdzania poprawności, ale korzystając z mojego doświadczenia w przepisywaniu Apache, ta konfiguracja wydaje się:
Spowoduje to następujące przypadki testowe
/ -> / /test -> /test/ /my/resource -> /my/resource/ /my/resource.type -> /my/resource.type /edge.case/resource -> /edge.case/resource
Myślę więc, że reguła ma na celu dodawanie ukośników do zasobów, które nie wydają się być plikiem, ale wydaje się, że ma on przypadek na krawędzi.
Jeśli nie dodajesz ukośnika do zasobu za pomocą „.” (kropka) znak w części pliku innej niż plik, wyrażenie regularne należy zmienić na:
źródło
!(\/$|\.[^\/]*)
- Twój zaktualizowany regex tak naprawdę nie jest inny. Potrzebna jest również kotwica końca sznurka w drugiej części (która pasuje do rozszerzenia). Być może coś takiego:!(/|\.[a-zA-Z]+)$
(nie trzeba uciekać przed ukośnikami).