In un URL, a cosa serve //? [chiuso]

39

In genere, quando vedo //, segue di solito un prefisso di protocollo come http:o ftp:. Non l'ho mai visto collocato altrove. Per esempio,

http://www.google.com/

è un URL tipico.

Tuttavia, ho trovato le seguenti due sintassi per produrre versioni diverse dello stesso sito,

http://www.weather.com/

http://www.weather.com//

Avrei pensato che in //qualsiasi altro posto diverso dalle specifiche del protocollo non sarebbe valido. Con mia sorpresa, mi sbagliavo. Cosa c'è nel finale //che genera una versione diversa dello stesso sito?

MODIFICARE:

Qualcuno in quel sito deve aver preso il vento dell'altro perché entrambi i link ora arrivano sulla stessa pagina.

url syntax uri

— Chad Harrison
fonte

9

Se dovessi indovinare, tutto quello che stai facendo è vedere lo stesso sito due volte ma quello con l'aggiunta / alla fine sta rompendo il CSS o qualunque cosa i bambini usino in questi giorni per formattare i loro siti web. :)

— Mark Allen,

webmasters.stackexchange.com potrebbe adattarsi meglio a questa domanda.

— Mehper C. Palavuzlar,

1

@ MehperC.Palavuzlar A posteriori, sì. Ma al momento della domanda, pensavo che lo scopo fosse un po 'più ampio di quello che è.

— Chad Harrison,

@MarkAllen È interessante notare che l'utilizzo ///o ////alla fine dell'URL ha prodotto lo stesso sito in /cui // si è verificato qualcosa di diverso.

— Chad Harrison,

Nel frattempo, la doppia barra rovesciata (\\) è comunemente vista nella Convenzione sulla denominazione uniforme di Windows, ad es\\HostName[@Port]\SharedFolder\Resource

— William C

67

Il comando iniziale //fa parte della sintassi dell'URL. L'inventore del World Wide Web si è scusato per questo errore .

Davvero, se ci pensate, non ha bisogno della doppia barra. Avrei potuto progettarlo per non avere la doppia barra. - Sir Tim Berners-Lee, inventore del World Wide Web

Per quanto riguarda il finale //, non è davvero una doppia barra. La prima barra separa il nome host dal percorso. L'ultima barra è il percorso. Un web server può, se lo desidera, trattare un percorso /diverso da un percorso vuoto, e apparentemente lo fa weather.com. Per quanto riguarda se questo è accidentale o intenzionale, dovresti chiederglielo.

— David Schwartz
fonte

Ciò rende completo da allora, perché è possibile configurare un server Web per cercare un indice diverso dal solo root Web! Buon cappello, buon signore.

— Chad Harrison,

Stai dicendo che http://example.compuò essere trattato diversamente http://example.com/? Non pensavo che fosse il caso della prima barra.

— SconcertatoGoat

1

@DisgruntledGoat Si potrebbe , sì, utilizzando alcune .htaccessregole. Ma probabilmente non dovresti.

— Matteo,

1

Non è possibile trattare http://example.comdiversamente da http://example.com/in un server Web, poiché entrambi hanno un percorso vuoto. Potresti trattarli diversamente in un browser.

— David Schwartz,

3

a prescindereGET / HTTP/1.1

— dall'intestazione

19

Più di recente, si potrebbe sostenere che la doppia barra ha un ruolo. Google consiglia (per evitare di chiamare accidentalmente contenuti non sicuri da una pagina protetta, ad esempio) omettendo il protocollo da risorse incorporate (fogli di stile, js ecc.), Come questo

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

Quindi è ora evidente che un tale URL senza protocollo è un URL completo e non un URL relativo (che inizierebbe con una singola barra).

— DaveP
fonte

1

Questo stile è chiamato URL / URI "relativo al protocollo". Ci sono domande simili su SO.

— hippietrail,

1

Non più raccomandato. Vedi anche paulirish.com/2010/the-protocol-relative-url

— lorond

13

Per effettivamente rispondere alla domanda, la specificazione originale ha dato il protocollo http:(o, eventualmente ftp:, gopher:, mailto:, news:, telnet:, wais:, file:o prospero:), poi una // per indicare che la sintassi Uniform Resource Locator (URL) è stato utilizzato, quindi l'host (opzionale prefisso user:password@), allora l'indirizzo inizio corretto con un altro /. Questo è stato proposto in RFC 1738 .

Man mano che Internet si è evoluto, è http:diventato il protocollo dominante, quindi ora i browser presumono che http://debba essere aggiunto un prefisso se non è presente.

— StarNamer
fonte

3

La tua risposta sembrerebbe indicare che un punto diverso dall'URL avrebbe potuto essere utilizzato con il protocollo ad un certo punto e avrebbe usato qualcosa di diverso da quello //per indicare che era in uso ... È così?

— Izkata,

3

@Izkata Alla fine degli anni '80 e '90, quando Internet si stava avviando, c'erano diversi formati suggeriti per vari articoli. Gli URL erano / sono un sottoinsieme di URN (vedere RFC 3305) e possono avere formati diversi, ad es isbn:1-23-456789-12-3. In pratica, il http:definisce che il resto sarà un URL. Le RFC sono solo proposte e spesso consentono estensioni che non si materializzano mai. Ad un certo punto, Tim Berners-Lee ha detto che //era per una "sottorete" (ad es. http:/govnet/whitehouse.gov). Questa idea non è mai stata utilizzata, ma '//' rimane come ora tanto codice si aspetta e controlla.

— StarNamer,

1

@Izkata: probabilmente non vedresti un URN non URL utilizzato con un protocollo di comunicazione; ecco a cosa serve //. Indica che il protocollo viene utilizzato per accedere a un percorso di rete (possibilmente remoto) in cui è possibile trovare una risorsa. Ci sono molti altri URN che hanno altre parti di dati e non usano // (il tuo browser probabilmente riconosce "mailto:", per esempio). Vedi: en.wikipedia.org/wiki/URI_scheme

— KutuluMike

@MichaelEdenfield Bene, questo è quello che mi chiedo ora. C'è mai stato un punto in cui è stato destinato ad essere utilizzato in modo diverso - qualcosa di diverso che potrebbe comunicare attraverso lo stesso protocollo. A titolo di esempio, l'intenzione potrebbe essere stata per una volta sia http://www.google.com/e http:%/74.125.225.97/sia valida, e //indicare un nome host mentre qualcos'altro come %/indica un indirizzo IP?

— Izkata,

1

Io non la penso così. Almeno non ho mai visto bozze di documenti / esempi / ecc. Che abbiano uno schema di gerarchia alternativo per gli URL. La mia impressione è sempre stata che TBL volesse semplicemente qualcosa per rendere ovvio che un URL indicava una risorsa reale (e non dati arbitrari), e l'uso di // rendeva le cose sufficientemente simili a file. Ogni altro stile di URN che abbia mai visto non ha un prefisso speciale nella sua parte di dati. Alcuni protocolli lo consentono ( penso telnet e gopher, ad esempio) ma non ho mai visto nulla di simile per gli http.

— KutuluMike

1

Vorrei aggiungere alla risposta accettata di David:

Nonostante le scuse dell'inventore del web, penso che la sintassi della doppia barra abbia avuto uno scopo importante: distinguersi visivamente. Le doppie barre consentono una facile distinzione visiva degli URL in un testo senza collegamenti ipertestuali. Quando hai visto doppie barre, hai immediatamente pensato che potesse essere inserito in una finestra del browser, in modo simile a come pensavi che contenesse un testo@potrebbe essere utilizzato per inviare un'e-mail. È stato particolarmente cruciale durante la fase di transizione al web in cui i protocolli di quell'epoca (ftp, telnet, gopher) avevano la loro strana idea di rappresentare indirizzi di server o percorsi di risorse, raramente entrambi. La maggior parte dei problemi associati alle doppie barre continuerebbe a esistere, poiché le doppie barre sono la parte meno crittografica di un URL, pensa ai numeri di porta, alla codifica percentuale e alla distinzione tra maiuscole e minuscole. Ma avere un URL come http: qualcosa.com potrebbe facilmente essere confuso con il mio esempio qui: qualcosa.com. Guarda http: // d'altra parte, come brilla come un diamante. Le doppie barre sono state una parte importante del simbolismo del Web e credo che abbia accelerato anche il tasso di adozione, anche se non era intenzionale.

Potrebbero anche aver reso il lavoro di AmigaOS più facile da distinguere tra nomi di file e URL poiché AmigaOS ha usato la sintassi del percorso del file volume:path/to/destination. :)

— Sedat Kapanoglu
fonte