W adresie URL, po co jest //? [Zamknięte]

39

Zazwyczaj, gdy widzę //, zwykle następuje po pewnym prefiksie protokołu, takim jak http:lub ftp:. Nigdy nie widziałem go umieszczonego nigdzie indziej. Na przykład,

http://www.google.com/

jest typowym adresem URL.

Znalazłem jednak dwie następujące składnie, aby uzyskać różne wersje tej samej witryny,

http://www.weather.com/

http://www.weather.com//

Myślałem, że //gdziekolwiek poza specyfikacją protokołu byłoby nieprawidłowe. Ku mojemu zaskoczeniu się myliłem. Co takiego jest w zakończeniu, //że tworzysz inną wersję tej samej strony?

EDYTOWAĆ:

Ktoś w tej witrynie musiał się przekonać, ponieważ oba linki znajdują się teraz na tej samej stronie.

url syntax uri Chad Harrison
źródło
9
Gdybym musiał zgadywać, wszystko, co robisz, to dwa razy oglądanie tej samej strony, ale ta z dodatkowym / na końcu psuje CSS lub cokolwiek dzieci używają w dzisiejszych czasach do formatowania swoich stron internetowych. :)
Mark Allen
webmasters.stackexchange.com może lepiej pasować do tego pytania.
Mehper C. Palavuzlar,
1
@ MehperC.Palavuzlar Z perspektywy czasu tak. Ale w momencie pytania myślałem, że zakres jest nieco szerszy niż jest.
Chad Harrison
@MarkAllen Dobrze jej zauważyć, że użycie ///lub ////na końcu adresu URL spowodowało tym samym miejscu co /gdzie // zrobił wynik w coś innego.
Chad Harrison
Tymczasem podwójny ukośnik odwrotny (\\) jest często spotykany w Jednolitej konwencji nazewnictwa systemu Windows, np.\\HostName[@Port]\SharedFolder\Resource
William C

Odpowiedzi:

67

Wiodące //jest częścią składni adresu URL. Wynalazca sieci przeprosił za ten błąd .

Naprawdę, jeśli się nad tym zastanowić, nie potrzebuje podwójnego ukośnika. Mógłbym zaprojektować go tak, by nie miał podwójnego cięcia. - Sir Tim Berners-Lee, wynalazca sieci WWW

Jeśli chodzi o końcowe //, to tak naprawdę nie jest to podwójny ukośnik. Pierwszy ukośnik oddziela nazwę hosta od ścieżki. Ostatni ukośnik to ścieżka. Serwer sieciowy może, jeśli chce, traktować ścieżkę /inną niż pusta, a najwyraźniej robi to weather.com. Jeśli chodzi o to, czy dzieje się to przez przypadek, czy celowo, musisz o to zapytać.

David Schwartz
źródło
To jest kompletne, ponieważ można skonfigurować serwer WWW, aby szukał indeksu innego niż tylko katalog główny! Mój kapelusz jest dla ciebie dobry, proszę pana.
Chad Harrison
Czy mówisz, że http://example.commożna traktować inaczej niż http://example.com/? Nie sądziłem, że tak było w przypadku pierwszego ukośnika.
DisgruntledGoat
1
@DisgruntledGoat Ty mógł , tak, stosując pewne .htaccesszasady. Ale prawdopodobnie nie powinieneś.
Matthew
1
Nie można traktować http://example.cominaczej niż http://example.com/na serwerze WWW, ponieważ oba mają pustą ścieżkę. Możesz traktować je inaczej w przeglądarce.
David Schwartz
3
bez względu na nagłówek hosta, zero lub jeden ukośnik przekłada się na to samo żądanie http GET / HTTP/1.1:: tools.ietf.org/html/rfc2616.html#section-3.2.3
SingleNegationElimination
19

W ostatnim czasie, można argumentować, że podwójny ukośnik ma odgrywać rolę. Google zaleca (na przykład, aby uniknąć przypadkowego wywołania niezabezpieczonej zawartości z bezpiecznej strony), pomijając protokół z zasobów osadzonych (arkusze stylów, js itp.), W ten sposób

<script src="//www.google.com/js/gweb/analytics/autotrack.js"></script>

Widać więc teraz, że taki adres URL bez protokołu to w pełni kwalifikowany adres URL, a nie względny adres URL (który zaczynałby się od pojedynczego ukośnika).

DaveP
źródło
1
Ten styl nazywa się „względnym protokołem” URL / URI. Podobne pytania dotyczą SO.
hippietrail
1
Nigdy więcej nie polecam. Zobacz także paulirish.com/2010/the-protocol-relative-url
lorond
13

Faktycznie odpowiedzieć na pytanie, pierwotny opis dało protokołem http:(albo ewentualnie ftp:, gopher:, mailto:, news:, telnet:, wais:, file:i prospero:), a następnie // w celu wskazania, że lokalizator zasobów (URL) składni uniform używany, wówczas gospodarza (ewentualnie poprzedzona z user:password@), to adres właściwy początek z innym /. Zostało to zaproponowane w RFC 1738 .

W miarę ewolucji Internetu http:stał się dominującym protokołem, dlatego przeglądarki zakładają, że http://należy dodać prefiks, jeśli go nie ma.

StarNamer
źródło
3
Twoja odpowiedź wydaje się wskazywać, że coś innego niż URL mogło być użyte z protokołem w pewnym momencie, i użyłoby czegoś innego niż //wskazanie, że był używany ... Czy to prawda?
Izkata
3
@Izkata Pod koniec lat 80. i 90., kiedy zaczynał się Internet, zaproponowano kilka różnych formatów dla różnych elementów. Adresy URL były / są podzbiorem URN (patrz RFC 3305) i mogą mieć różne formaty, np isbn:1-23-456789-12-3. W praktyce http:określa, że ​​reszta będzie adresem URL. RFC są tylko propozycjami i często pozwalają na rozszerzenia, które nigdy się nie pojawiają. W pewnym momencie Tim Berners-Lee powiedział, że //jest to „podsieć” (np. http:/govnet/whitehouse.gov). Pomysł ten nigdy nie został wykorzystany, ale „//” pozostaje, ponieważ tyle kodu oczekuje i sprawdza go.
StarNamer
1
@Izkata: prawdopodobnie nie zobaczysz URN bez adresu URL używanego z protokołem komunikacyjnym; po to jest //. Wskazuje, że protokół jest używany do uzyskania dostępu do (prawdopodobnie zdalnej) lokalizacji sieciowej, w której znajduje się zasób. Tam są wiele innych tych urny, które mają inne części danych i nie używać // (przeglądarka prawdopodobnie rozpoznaje „mailto:”, na przykład). Zobacz: en.wikipedia.org/wiki/URI_scheme
KutuluMike
@MichaelEdenfield Cóż, właśnie to się teraz zastanawiam. Czy kiedykolwiek to punkt, gdzie został przeznaczony do stosowania w różny sposób - coś innego, że może komunikować się za pomocą tego samego protokołu. Jako surowy przykład, może intencją w jednym czasie były za http://www.google.com/i http:%/74.125.225.97/zarówno ważne, i //wskazywać nazwę hosta natomiast coś innego jak %/wskazać adres IP?
Izkata
1
Nie wydaje mi się Przynajmniej nigdy nie widziałem żadnych projektów dokumentów / przykładów / etc, które miałyby alternatywny schemat heirarchii dla adresów URL. Zawsze miałem wrażenie, że TBL chciał czegoś, co uczyniłoby oczywistym, że adres URL wskazuje rzeczywisty zasób (a nie dowolne dane), a użycie // sprawiło, że wszystko wyglądało wystarczająco podobnie do pliku. Każdy inny styl URN, jaki kiedykolwiek widziałem, nie ma specjalnego prefiksu w części danych. Niektóre protokoły na to pozwalają (myślę, że telnet i gopher, np.), Ale nigdy nie widziałem czegoś takiego dla http (s).
KutuluMike,
1

Chciałbym dodać do zaakceptowanej odpowiedzi Davida:

Pomimo przeprosin wynalazcy sieci, myślę, że składnia podwójnego ukośnika służyła istotnemu celowi: wizualnemu wyróżnieniu się. Podwójne ukośniki pozwoliły na łatwe wizualne rozróżnienie adresów URL w tekście bez hiperłączy. Kiedy zobaczyłeś podwójne ukośniki, od razu pomyślałeś, że można je wprowadzić w oknie przeglądarki, podobnie jak myślałem, że tekst zawiera@może być użyty do wysłania e-maila. Było to szczególnie ważne w fazie przejścia do sieci, gdzie protokoły z tamtej epoki (ftp, telnet, gopher) miały swoje własne dziwne wyobrażenie, że reprezentują adresy serwerów lub ścieżki zasobów, rzadko jedno i drugie. Większość problemów związanych z podwójnymi ukośnikami nadal istniałaby, ponieważ podwójne ukośniki są najmniej kryptograficzną częścią adresu URL, pomyśl o numerach portów, procentach kodowania i rozróżnianiu wielkości liter. Ale posiadanie adresu URL takiego jak http: coś.com można łatwo pomylić z moim przykładem tutaj: coś.com. Z drugiej strony spójrz na http: //, jak świeci jak diament. Podwójne ukośniki były ważną częścią symboliki sieciowej i uważam, że przyspieszyło to również jej tempo adopcji, nawet jeśli było to niezamierzone.

Mogły także ułatwić zadanie AmigaOS rozróżniania nazw plików i adresów URL, ponieważ AmigaOS używał składni ścieżki pliku volume:path/to/destination. :)

Sedat Kapanoglu
źródło