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

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