Dans une URL, à quoi sert //?
Généralement, lorsque 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,
J'aurais pensé que // n'importe où autre que la spécification de protocole serait invalide. À ma grande surprise, j'avais tort. Qu'en est-il de la fin //qui donne une version différente du même site?
EDIT:
Quelqu'un sur ce site doit avoir attrapé le vent de l'autre parce que les deux liens atterrissent maintenant sur la même page.
Le // initial 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, elle 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
En ce qui concerne le // final, il ne s’agit vraiment pas d’une double barre oblique. La première barre oblique sépare le nom d'hôte du chemin. La dernière barre oblique est le chemin. Un serveur Web peut, s'il le souhaite, traiter un chemin d'accès de / 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.
Plus récemment, on pourrait affirmer que la double barre oblique a un rôle . recommande Google (pour éviter d'appeler accidentellement du contenu non sécurisé à partir d'une page sécurisée, par exemple) en omettant 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 seule barre oblique).
Pour répondre réellement à la question, la spécification d'origine donnait au protocole http: (ou éventuellement ftp:, Gopher:, mailto:, news:, telnet:, wais:, file: ou prospero:) puis un // pour indiquer que la syntaxe Uniform Resource Loc (URL) était utilisée, puis l'hôte (éventuellement avec le préfixe user:password@), puis l'adresse correcte en commençant par un autre /. Cela a été proposé dans RFC 1738 .
Au fur et à mesure qu'Internet a évolué, http: est devenu le protocole dominant, de sorte que les navigateurs supposent maintenant qu'un préfixe de http:// devrait être ajouté s'il n'était pas présent.
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 immédiatement pensé que vous pouviez les saisir dans une fenêtre de navigateur, comme si vous pensiez qu'un texte contenant @ pourrait être utilisé pour envoyer un courrier électronique. 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é une partie importante du symbolisme Web et je crois que cela a également accéléré son taux d'adoption, même si c'était involontaire.
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. :)