Kiedy powinienem używać ukośnika końcowego w moim adresie URL?

To nie jest kwestia preferencji. /base i /base/ mają inną semantykę. W wielu przypadkach różnica jest nieistotna. Ale jest to ważne, gdy istnieją względne adresy URL.

• child względem /base/ jest /base/child.
• child w stosunku do /base jest (być może zaskakująco) /child.

Zawsze jestem zaskoczony szerokim wykorzystaniem końcowych ukośników na adresach URL innych niż katalogowe (m.in. WordPress). To naprawdę nie powinno być debatą albo-albo, ponieważ umieszczanie ukośnika po zasobie jest semantycznie błędne. Sieć została zaprojektowana w celu dostarczania adresowalnych zasobów, a te adresy-adresy URL - zostały zaprojektowane w celu emulowania hierarchii systemu plików w stylu * nix. W tym kontekście:

• ukośniki zawsze oznaczają katalogi, nigdy pliki.
• pliki mogą mieć dowolną nazwę (z rozszerzeniami lub bez), ale nie może zawierać ani kończyć się ukośnikami.

Używając tych wytycznych, błędem jest umieszczanie ukośnika po zasobach spoza katalogu.

To nie jest kwestia estetyki, ale rzeczywiście różnica techniczna. Katalog jest całkowicie poprawny i prawie wszystko wyjaśnia. Rozwiążmy to:

Jesteś z powrotem w epoce kamienia lub obsługujesz tylko statyczne strony

Masz stałą strukturę katalogów na swoim serwerze i tylko pliki statyczne, takie jak obrazy, html i tak dalej-bez skryptów po stronie serwera lub w ogóle.

Przeglądarka żąda /index.htm, istnieje i jest dostarczana do klient. Później masz wiele - powiedzmy-przeglądanych filmów DVD i stronę html dla każdego z nich w katalogu /dvd/. Teraz ktoś prosi /dvd/adams_apples.htm i jest dostarczony, ponieważ tam jest.

Pewnego dnia, ktoś po prostu prosi /dvd/ - który jest katalogiem i serwer próbuje dowiedzieć się, co dostarczyć. Oprócz ograniczeń dostępu i tak dalej są dwie możliwości: Pokaż użytkownikowi zawartość katalogu (założę się, że już to gdzieś widziałeś) lub pokaż plik domyślny (w Apache jest to: DirectoryIndex: sets the file that Apache will serve if a directory is requested.)

Jak na razie tak dobrze, to jest oczekiwany przypadek. to już pokazuje różnicę w obsłudze, więc przejdźmy do niego:

O 5: 34 popełniłeś błąd w przesyłaniu plików

(co jest przy okazji całkowicie zrozumiałe.) Więc zrobiłeś coś zupełnie nie tak i zamiast przesłać /dvd/the_big_lebowski.htm załadowałeś ten plik jako dvd (bez rozszerzenia) do /.

Ktoś dodał Twoją /dvd/ listę katalogów (z oczywiście nie chciałeś tworzyć i zawsze aktualizować tego nifty index.htm) i odwiedzasz swoją stronę internetową. Zawartość katalogu jest dostarczana - wszystko w porządku.

Ktoś słyszał o twojej liście i pisze /dvd. A teraz jest przerąbane. Zamiast listy katalogu DVD serwer znajduje plik o tej nazwie i dostarcza plik Big Lebowski.

Więc usuń ten plik i powiedz kolesiowi, żeby przeładował stronę. Twój serwer szuka pliku /dvd, ale go nie ma. Większość serwerów będzie następnie zauważ, że istnieje katalog o tej nazwie i powiedz klientowi, że to, czego szukał, jest rzeczywiście gdzieś indziej. Odpowiedź najprawdopodobniej będzie brzmiała:

Status Code:301 Moved Permanently z Location: http://[...]/dvd/

Więc, całkowicie ignorując to, comyślisz o katalogach lub plikach, serwer może obsłużyć tylko takie rzeczy i - o ile nie powiedział inaczej-decyduje za Ciebie o znaczeniu "slash czy nie".

W końcu po otrzymaniu tej odpowiedzi klient ładuje {[1] } i wszystko w porządku.

Masz jakąś dynamiczną stronę, na której wszystko jest przekazywane do /index.php i jest przetwarzane. Do tej pory wszystko działało całkiem dobrze, ale to wszystko zaczyna czuć się wolniej i badasz.

Wkrótce zauważysz, że /dvd/list robi dokładnie to samo: przekierowanie do /dvd/list/, które jest następnie wewnętrznie tłumaczone na index.php?controller=dvd&action=list. Jedna dodatkowa prośba - ale jeszcze gorzej! customer/login przekierowania do customer/login/, który z kolei przekierowuje na adres URL HTTPS z customer/login/. W końcu masz Tony niepotrzebnych przekierowań HTTP (=dodatkowych żądań), które sprawiają, że doświadczenie użytkownika jest wolniejsze.

Najprawdopodobniej masz tutaj również domyślny indeks katalogów: index.php?controller=dvd bez action po prostu wewnętrznie ładuje index.php?controller=dvd&action=list.

Podsumowanie:

• Jeśli kończy się na / może nigdy nie być plikiem. brak zgadywania serwera.

• Slash or no slash są zupełnie inne znaczenia. istnieje techniczna różnica między "slash" a "no slash" i powinieneś być tego świadomy i odpowiednio z niego korzystać. Tylko dlatego, że serwer najprawdopodobniej ładuje /dvd/index.htm - lub ładuje poprawne Skrypty - kiedy mówisz /dvd: robi to, ale nie dlatego, że złożyłeś właściwe żądanie. Czyli /dvd/.

• Pomijając ukośnik, nawet jeśli rzeczywiście oznacza wersja z ukośnikiem daje dodatkowe żądanie HTTP kara. który jest zawsze zły (pomyśl o mobilnym opóźnieniu) i ma większą wagę niż" ładny URL " - zwłaszcza, że crawlery nie są tak głupie, jak wierzą SEO lub chcą, abyś uwierzył ;)

Kiedy tworzysz swój adres URL /about-us/ (z ukośnikiem końcowym), łatwo jest zacząć od pojedynczego pliku index.html, a następnie rozszerzyć go i dodać więcej plików (np. our-CEO-john-doe.jpg) lub nawet zbudować pod nim hierarchię (np. /about-us/company/, /about-us/products/, itd.) w razie potrzeby, bez zmiany opublikowanego adresu URL. Daje to dużą elastyczność.

Kto mówi, że nazwa pliku wymaga rozszerzenia?? zajrzyj kiedyś na maszynę *nix...
Zgadzam się z twoim przyjacielem, nie tracić Slasha.

Inne odpowiedzi tutaj wydają się sprzyjać pominięciu trailing slash. Jest jeden przypadek, w którym końcowy ukośnik pomoże w optymalizacji pod kątem wyszukiwarek (SEO). Oznacza to, że twój dokument ma coś, co wydaje się być rozszerzeniem pliku, które nie jest .html. Staje się to problemem w przypadku witryn oceniających witryny. Mogą wybrać pomiędzy tymi dwoma adresami URL:

• http://mysite.example.com/rated.example.com
• http://mysite.example.com/rated.example.com/

W takim przypadku wybrałbym ten z ukośnikiem. Dzieje się tak dlatego, że rozszerzenie .com jest rozszerzeniem dla plików wykonywalnych poleceń systemu Windows. Wyszukiwarki i kontrolery wirusów często nie lubią adresów URL, które wydają się zawierać złośliwe oprogramowanie rozpowszechniane za pośrednictwem takich mechanizmów. Końcowy ukośnik wydaje się łagodzić wszelkie obawy, umożliwiając pozycjonowanie strony w wyszukiwarkach i uzyskanie przez kontrolery wirusów.

Jeśli Twoje adresy URL nie mają . w części pliku, to zalecam pominięcie końcowego ukośnika dla uproszczenia.

Z punktu widzenia SEO wybór, czy ma zawierać końcowy ukośnik na końcu adresu URL, jest nieistotny. W dzisiejszych czasach często można zobaczyć przykłady obu w sieci. Witryna nie zostanie ukarana w żaden sposób, ani ten wybór nie wpłynie na ranking Twojej witryny w wyszukiwarkach lub inne względy SEO.

Po prostu wybierz preferowaną konwencję nazw URL i dołącz kanoniczny meta tag w sekcji <head> każdej strony internetowej.

Wyszukiwarki mogą rozważyć pojedynczy strona internetowa jako dwa oddzielne duplikaty adresów URL, gdy napotkają go z ukośnikiem końcowym i bez niego, tj. example.com/about-us/ i example.com/about-us.

Najlepszą praktyką jest dołączanie kanonicznego meta tagu na każdej stronie, ponieważ nie możesz kontrolować, w jaki sposób inne witryny łączą się z Twoimi adresami URL.

Znacznik kanoniczny wygląda tak: <link rel="canonical" href="https://example.com/about-us" />. Korzystanie z kanonicznego meta tagu zapewnia, że wyszukiwarki liczą każdy z twoich adresów URL tylko raz, niezależnie od tego, czy inne witryny zawierają końcowy ukośnik, gdy łączą się z Twoją witryną.