Ich hätte gedacht, dass //irgendwo anders als die Protokollspezifikation ungültig wäre. Zu meiner Überraschung lag ich falsch. Worum geht es am Ende, //dass eine andere Version der gleichen Site erstellt wird?
BEARBEITEN:
Jemand an diesem Standort muss Wind vom anderen bekommen haben, da beide Links jetzt auf derselben Seite landen.
Wenn ich raten müsste, müssen Sie nur die gleiche Site zweimal sehen, aber die mit dem Zusatz / am Ende bricht das CSS oder was auch immer die Kinder heutzutage verwenden, um ihre Websites zu formatieren. :)
Mark Allen vor 11 Jahren
9
http://webmasters.stackexchange.com/ könnte für diese Frage besser geeignet sein.
Mehper C. Palavuzlar vor 11 Jahren
0
@ MehperC.Palavuzlar Im Nachhinein ja. Aber zum Zeitpunkt der Frage war ich der Meinung, dass der Geltungsbereich etwas breiter war als er war.
Chad Harrison vor 11 Jahren
1
@ MarkAllen Nun, es ist interessant zu wissen, dass die Verwendung von "///" oder "////" am Ende der URL zu derselben Site führte wie "/", wobei "//" * * zu etwas anderem führte.
Chad Harrison vor 11 Jahren
0
In der Zwischenzeit wird der doppelte Backslash (\\\) häufig in der Windows-Konvention für die Namensgebung verwendet, z. B. "\\ HostName [@Port] \ SharedFolder \ Resource"
William C vor 11 Jahren
0
Wirklich, wenn Sie darüber nachdenken, braucht es keinen doppelten Schrägstrich. Ich hätte es so gestalten können, dass es keinen doppelten Schrägstrich gibt. - Sir Tim Berners-Lee, Erfinder des World Wide Web
Was das Nachlaufen angeht //, ist es wirklich kein doppelter Schrägstrich. Der erste Schrägstrich trennt den Hostnamen vom Pfad. Der letzte Schrägstrich ist der Pfad. Ein Webserver kann, wenn er möchte, einen anderen Pfad /als einen leeren Pfad behandeln, was offensichtlich von weather.com geschieht. Ob dies zufällig oder beabsichtigt ist, müssen Sie sie danach fragen.
Das macht dies komplett, denn Sie können einen Webserver so konfigurieren, dass er nach einem anderen Index als dem Web-Root sucht. Mein Hut ist zu Ihnen gut, mein Herr.
Chad Harrison vor 11 Jahren
0
Wollen Sie damit sagen, dass "http: // example.com" anders als "http: // example.com /" behandelt werden kann? Ich glaube nicht, dass dies beim ersten Schrägstrich der Fall war.
DisgruntledGoat vor 11 Jahren
0
@DisgruntledGoat Sie könnten * ja * einige `.htaccess'-Regeln verwenden. Aber das solltest du wahrscheinlich nicht.
Matthew vor 11 Jahren
1
@Matt Das ist merkwürdig, denn wenn Sie nach der Domäne den Schrägstrich eingeben, wird der Browser sofort entfernt [Bearbeiten: Chrome / Firefox entfernen, IE tatsächlich * fügt * hinzu]. Dies bedeutet, dass ein Browser eigentlich keine Anforderung hat individuell. Auch der RFC-Link in einer anderen Antwort unten sagt, dass der Schrägstrich optional ist, was bedeutet, dass sie identisch sind.
DisgruntledGoat vor 11 Jahren
0
Sie können "http: // example.com" nicht anders als "http: // example.com /" auf einem Webserver behandeln, da beide einen leeren Pfad haben. Sie könnten sie in einem Browser anders behandeln.
David Schwartz vor 11 Jahren
1
Wenn Sie den Hostheader nicht kennen, werden null oder ein Schrägstrich in dieselbe http-Anforderung übersetzt: `GET / HTTP / 1.1`: http://tools.ietf.org/html/rfc2616.html#section-3.2.3
SingleNegationElimination vor 11 Jahren
3
17
DaveP
More recently, it could be argued that the double slash does have a role. Google recommend (to avoid accidentally calling insecure content from a secure page, for example) omitting the protocol from embedded resources (stylesheets, js etc), like this
So it is now apparent that such a protocol-less URL is a fully qualified URL and not a relative URL (which would begin with a single slash).
Dieser Stil wird als "relatives Protokoll" URL / URI bezeichnet. Es gibt ähnliche Fragen zu SO.
hippietrail vor 11 Jahren
1
+1 Danke, das wusste ich nicht und hätte es nie versucht.
Alberto vor 11 Jahren
0
Nicht mehr zu empfehlen. Siehe auch https://www.paulirish.com/2010/the-protocol-relative-url/
lorond vor 7 Jahren
1
12
StarNamer
Um tatsächlich die Frage zu beantworten, gab die ursprüngliche Spezifikation das Protokoll http:(oder möglicherweise ftp:, gopher:, mailto:, news:, telnet:, wais:, file:oder prospero:), dann ein, // um anzuzeigen, dass die Uniform Resource Locator (URL) Syntax verwendet wurde, dann wird die Host (optional mit dem Präfix user:password@) dann auf Adress richtig mit einem anderen beginnen /. Dies wurde in RFC 1738 vorgeschlagen .
Als das Internet sich entwickelte, http:wurde es zum dominanten Protokoll, sodass Browser jetzt davon ausgehen, dass ein Präfix von http://hinzugefügt werden sollte, wenn es nicht vorhanden ist.
Ihre Antwort scheint darauf hinzudeuten, dass an einer Stelle etwas anderes als URL mit dem Protokoll verwendet werden konnte und etwas anderes als "//" verwendet hätte, um anzuzeigen, dass es verwendet wurde ... Ist das so?
Izkata vor 11 Jahren
3
@Izkata In den späten 80er und 90er Jahren, als das Internet startete, wurden verschiedene Formate für verschiedene Elemente vorgeschlagen. URLs waren / sind eine Teilmenge von URNs (siehe RFC 3305) und diese können unterschiedliche Formate haben, z. B. `isbn: 1-23-456789-12-3`. In der Praxis definiert das `http:`, dass der Rest eine URL sein wird. RFCs sind nur Vorschläge und lassen oft Erweiterungen zu, die nie zum Tragen kommen. An einem Punkt sagte Tim Berners-Lee, dass das "//" für ein "Subnetz" war (zB "http: / govnet / whitehouse.gov"). Diese Idee wurde nie verwendet, aber '//' bleibt erhalten, da jetzt so viel Code erwartet und darauf geprüft wird.
StarNamer vor 11 Jahren
2
@Izkata: Sie sehen wahrscheinlich keine URN ohne URL, die mit einem Kommunikationsprotokoll verwendet wird. dafür ist das //. Es gibt an, dass das Protokoll für den Zugriff auf einen (möglicherweise entfernten) Netzwerkstandort verwendet wird, an dem eine Ressource gefunden werden soll. Es gibt * viele * andere URNs, die andere Datenteile haben und // nicht verwenden (Ihr Browser erkennt wahrscheinlich "mailto:", zum Beispiel). Siehe: http://en.wikipedia.org/wiki/URI_scheme
KutuluMike vor 11 Jahren
1
@MichaelEdenfield Nun, das frage ich mich jetzt. Gab es jemals einen Punkt, an dem _intended_ anders verwendet werden sollte - etwas anderes, das über dasselbe Protokoll kommunizieren kann. Als grobes Beispiel könnte die Absicht _at one_ für 'http: // www.google.com / `und` http:% / 74.125.225.97 / `gültig sein und` // `einen Hostnamen angeben während etwas anderes wie% / eine IP-Adresse angibt?
Izkata vor 11 Jahren
0
Ich glaube nicht Zumindest habe ich noch nie Entwürfe von Dokumenten / Beispielen / etc gesehen, die ein alternatives URL-Schema haben. Mein Eindruck war immer, dass TBL nur etwas wollte, um deutlich zu machen, dass eine URL auf eine tatsächliche * Ressource * (und keine willkürlichen Daten) verweist und die Verwendung von // dazu führt, dass die Dinge ausreichend dateiartig aussehen. Jeder andere URN-Stil, den ich je gesehen habe, hat in seinem Datenteil * kein * ein besonderes Präfix. Einige Protokolle erlauben das (ich glaube * zB Telnet und Gopher), aber so etwas habe ich noch nie für http (s) gesehen.
KutuluMike vor 11 Jahren
1
0
Sedat Kapanoglu
I'd like to add to David's accepted answer:
Despite the apology of inventor of the web I think the double-slash syntax served an important purpose: to visually stand out. Double-slashes allowed easy visual distinction of URLs in a text without hyperlinks. When you saw double slashes you immediately thought it could be entered in a browser window, similar to how you thought a text containing @ could be used to send an email. It was especially crucial during the transition phase to web where protocols of that era (ftp, telnet, gopher) had their own weird notion to represent server addresses or resource paths, rarely both. Most of the problems associated with double-slashes would still exist, because double slashes are the least cryptical part of a URL, think about port numbers, percent encoding and case-sensitivity. But having a URL like http:something.com could easily be confused with my example here:something.com. Look at http:// on the other hand, how it shines like a diamond. Double-slashes have been an important part of Web symbolism and I believe it accelerated it's adoption rate too, even if it was unintentional.
They also might have made AmigaOS's job easier to differentiate between file names and URLs since AmigaOS used the file path syntax volume:path/to/destination. :)