Nie można ustalić reguły htaccess

9

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?

— Richard1984
źródło

Jeśli część żądania (część adresu URL po „.com”) nie kończy się na a /i nie zawiera „ .”, przekieruj żądanie, dołączając je do /. Prawdopodobną intencją tej reguły jest obsługa automatycznego indeksowania katalogów.

— peterh - Przywróć Monikę

11

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ęc https://example.org/testzostanie przekierowany do https://example.org/test/, ale https://example.org/test.htmlnie zostaną zapisane, aby https://example.org/test.html/(ale uwaga: https://example.org/test.case/folderrównież nie zostać przekierowany https://example.org/test.case/folder/ponieważ zawiera a .w URI).

## Do the following if the URI does not end with `/` or  does not contain an `.`: 
## the . is relevant for file names like test.html, which should n 
RewriteCond %{REQUEST_URI} !(/$|\.)

## Redirect it to the original URI with an added `/` and mark this as permanent:
RewriteRule (.*) %{REQUEST_URI}/ [R=301]

— Sven
źródło

„ /test.case/folderró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-urlpowinien mieć ukośnik końcowy.

— MrWhite

6

Bez sprawdzania poprawności, ale korzystając z mojego doświadczenia w przepisywaniu Apache, ta konfiguracja wydaje się:

Dopasuj w części „ścieżka” identyfikatora URI (nie w parametrze serwera, portu ani zapytania), na przykład „/my/location/file.html”.
Dopasuj, jeśli ta część nie kończy się znakiem „/” (ukośnik), lub lub nie zawiera znaku „.” (kropka) znak.
Użyj pełnej ścieżki URI i dodaj do niej ukośnik.
Wyślij przekierowanie HTTP 301 (stałe), aby skierować przeglądarkę do tego nowego identyfikatora URI.

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:

# match paths which do not end with a slash, or do not resemble a file with an extension
RewriteCond %{REQUEST_URI} !(/$|\.[^/]+$)
# redirect permanently to the same uri with a slash
RewriteRule (.*) %{REQUEST_URI}/ [R=301]

— Joffrey
ź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).

— MrWhite

@MrWhite Dobry połów! Zaktualizowałem swoją odpowiedź!

— Joffrey