Dans une URL, à quoi sert //? [fermé]

39

Généralement, quand je vois //, il s’agit généralement de suivre un préfixe de protocole comme http:ou ftp:. Je ne l'ai jamais vu placé ailleurs. Par exemple,

http://www.google.com/

est une URL typique.

Cependant, j'ai trouvé que les deux syntaxes suivantes donnaient des versions différentes du même site,

http://www.weather.com/

http://www.weather.com//

J'aurais pensé que //n'importe où autre que la spécification de protocole serait invalide. À ma grande surprise, j'avais tort. Qu'y a-t-il à propos de la fin //si on crée une version différente du même site?

MODIFIER:

Quelqu'un sur ce site doit avoir attrapé le vent de l'autre parce que les deux liens se retrouvent maintenant sur la même page.

url syntax uri

— Chad Harrison
source

9

Si je devais deviner, tout ce que vous faites est de voir le même site deux fois, mais celui avec le supplément / à la fin casse le CSS ou ce que les enfants utilisent de nos jours pour formater leurs sites Web. :)

— Mark Allen

webmasters.stackexchange.com pourrait être un meilleur ajustement pour cette question.

— Mehper C. Palavuzlar

1

@ MehperC.Palavuzlar Rétrospectivement, oui. Mais au moment de la question, je pensais que la portée était un peu plus large que ce qu'elle est.

— Chad Harrison

@MarkAllen Eh bien, il est intéressant de noter que l'utilisation ///ou ////la fin de l'URL a eu pour résultat le même site que celui /qui // a abouti à quelque chose de différent.

— Chad Harrison

Pendant ce temps, la double barre oblique inversée (\\) apparaît couramment dans la convention de nommage uniforme de Windows, par exemple,\\HostName[@Port]\SharedFolder\Resource

— William C

67

Le début //fait partie de la syntaxe de l'URL. L'inventeur du World Wide Web s'est excusé pour cette erreur .

Vraiment, si vous y réfléchissez, il n'a pas besoin de la double barre oblique. J'aurais pu le concevoir pour ne pas avoir la double barre oblique. - Sir Tim Berners-Lee, inventeur du World Wide Web

Pour ce qui est de la fin //, ce n'est vraiment pas une double barre oblique. La première barre oblique sépare le nom d'hôte du chemin. La dernière barre est le chemin. Un serveur Web peut, s'il le souhaite, traiter un chemin /différent d'un chemin vide, et apparemment celui de weather.com. Quant à savoir si c'est accidentel ou intentionnel, vous devrez leur demander à ce sujet.

— David Schwartz
source

Cela est complet depuis, car vous pouvez configurer un serveur Web pour rechercher un index autre que la racine Web! Je vous tire mon chapeau, bon monsieur.

— Chad Harrison

Voulez-vous dire http://example.compeut être traité différemment de http://example.com/? Je ne pensais pas que c'était le cas avec la première barre oblique.

— DisgruntledGoat

1

@DisgruntledGoat Vous pouvez , oui, utiliser certaines .htaccessrègles. Mais vous ne devriez probablement pas.

— Matthew

1

Vous ne pouvez pas traiter http://example.comdifféremment d' http://example.com/un serveur Web, car ils ont tous deux un chemin vide. Vous pouvez les traiter différemment dans un navigateur.

— David Schwartz

3

ne jamais fermer l'en-tête de l'hôte, zéro ou un slash se traduit par la même requête http GET / HTTP/1.1:: tools.ietf.org/html/rfc2616.html#section-3.2.3

— SingleNegationElimination

19

Plus récemment, on pourrait faire valoir que la double barre oblique n'ont un rôle. Google recommande (pour éviter d'appeler accidentellement du contenu non sécurisé à partir d'une page sécurisée, par exemple) d'omettre le protocole des ressources incorporées (feuilles de style, js, etc.), comme ceci

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

Il est donc maintenant évident qu'une telle URL sans protocole est une URL pleinement qualifiée et non une URL relative (qui commencerait par une simple barre oblique).

— DaveP
source

1

Ce style s'appelle une URL / URI "relative au protocole". Il y a des questions similaires sur SO.

— hippietrail

1

Pas plus recommander. Voir aussi paulirish.com/2010/the-protocol-relative-url

— lorond

13

Pour répondre effectivement à la question, la spécification d' origine a donné le protocole http:(ou peut - être ftp:, gopher:, mailto:, news:, telnet:, wais:, file:ou prospero:) alors // pour indiquer que la syntaxe Resource Locator (URL) uniforme a été utilisé, l'hôte ( en option préfixé avec user:password@) puis adresse bon en commençant par un autre /. Cela a été proposé dans le RFC 1738 .

Au fur et à mesure qu'Internet évoluait, http:devenait le protocole dominant, les navigateurs supposent maintenant qu'un préfixe de http://devrait être ajouté s'il n'est pas présent.

— StarNamer
source

3

Votre réponse semblerait indiquer que quelque chose d'autre que l'URL aurait pu être utilisé avec le protocole à un moment donné, et aurait utilisé autre chose que //d'indiquer qu'il était utilisé ... Est-ce vrai?

— Izkata

3

@Izkata À la fin des années 80 et 90, lors du lancement d'Internet, plusieurs formats différents ont été suggérés pour différents articles. Les URL étaient / sont un sous-ensemble d'URN (voir RFC 3305) et peuvent avoir différents formats, par exemple isbn:1-23-456789-12-3. En pratique, le http:définit que le reste sera une URL. Les RFC ne sont que des propositions et permettent souvent des extensions qui ne se matérialisent jamais. Tim Berners-Lee a déclaré à un moment donné qu'il //s'agissait d'un «sous-réseau» (par exemple http:/govnet/whitehouse.gov). Cette idée n'a jamais été utilisée, mais '//' reste tel que le code attend maintenant et le vérifie.

— StarNamer

1

@Izkata: vous ne verrez probablement pas un URN sans URL utilisé avec un protocole de communication; c'est ce que le // est pour. Il indique que le protocole est utilisé pour accéder à un emplacement réseau (éventuellement distant) où une ressource doit être trouvée. Il y a beaucoup d'autres URN qui ont d'autres parties de données et n'utilisent pas // (votre navigateur reconnaît probablement "mailto:", par exemple). Voir: en.wikipedia.org/wiki/URI_scheme

— KutuluMike

@ MichaelEdenfield Eh bien, c'est ce que je me demande maintenant. Y a-t-il eu un moment où il était destiné à être utilisé différemment - quelque chose de différent pouvant communiquer via le même protocole. A titre d'exemple brut, pourrait l'intention à un moment donné ont été pour http://www.google.com/et http:%/74.125.225.97/à la fois valable et //indiquer un nom d' hôte tout autre chose comme %/indiquer une adresse IP?

— Izkata

1

Je ne pense pas. Au moins, je n'ai jamais vu de projets de documents / exemples / etc. comportant un autre schéma de hiérarchie pour les URL. Mon impression a toujours été que TBL souhaitait simplement que quelque chose indique clairement qu'une URL pointait sur une ressource réelle (et non sur des données arbitraires), et l'utilisation de // donnait l'impression que les choses ressemblaient suffisamment à des fichiers. Tous les autres styles d'URN que j'ai jamais vus n'ont pas de préfixe spécial dans leur partie data. Certains protocoles le permettent (je pense à telnet et gopher, par exemple) mais je n’ai jamais rien vu de tel pour http (s).

— KutuluMike

1

J'aimerais ajouter à la réponse acceptée de David:

Malgré les excuses de l'inventeur du Web, je pense que la syntaxe à double barre oblique avait un objectif important: se distinguer visuellement. Les doubles barres obliques permettaient une distinction visuelle facile des URL dans un texte sans hyperlien. Lorsque vous avez vu des doubles barres obliques, vous avez tout de suite pensé que vous pouviez les saisir dans une fenêtre du navigateur, comme si vous pensiez qu'un texte contenant@pourrait être utilisé pour envoyer un email. C'était particulièrement crucial pendant la phase de transition vers le Web, où les protocoles de cette époque (ftp, telnet, gopher) avaient leur propre notion étrange de représenter des adresses de serveur ou des chemins de ressources, rarement les deux. La plupart des problèmes associés aux doubles barres obliques subsisteraient toujours, car les doubles barres obliques sont la partie la moins cryptée d'une URL, pensez aux numéros de port, au pourcentage de codage et à la sensibilité à la casse. Mais avoir une URL comme http: quelque chose.com pourrait facilement être confondu avec mon exemple ici: quelque chose.com. Regardez http: // D'autre part, comment ça brille comme un diamant. Les doubles barres obliques ont été un élément important du symbolisme Web et je crois que cela a également accéléré son taux d'adoption, même si ce n'était pas intentionnel.

Ils ont peut-être également facilité la tâche du travail d'AmigaOS en matière de distinction entre les noms de fichier et les URL, car AmigaOS utilisait la syntaxe du chemin d'accès au fichier volume:path/to/destination. :)

— Sedat Kapanoglu
source