Gibt es einen Nachteil bei der Verwendung eines führenden doppelten Schrägstrichs, um das Protokoll in einer URL zu erben? dh src = "// domain.com"


148

Ich habe ein Stylesheet, das Bilder von einer externen Domain lädt, und ich brauche es, um von https: // von sicheren Bestellseiten und http: // von anderen Seiten basierend auf der aktuellen URL zu laden. Ich habe festgestellt, dass das Starten der URL mit einem doppelten Schrägstrich das aktuelle Protokoll erbt. Unterstützen alle Browser diese Technik?

html ex:

<img src="//cdn.domain.com/logo.png" />

CSS-Beispiel:

.class { background: url(//cdn.domain.com/logo.png); }

1
verlangsamt dies die Seite ???
TheBlackBenzKid

2
Es gibt keinen Grund, warum dies Auswirkungen auf die Leistung haben sollte, außer in den Fällen, die Meder unten in ihrer Antwort aufgeführt hat.
Rob Volk

Sieht so aus, als hätte ich etwas vor. Vor einigen Monaten haben Google Entwickler begonnen, diese Konvention auf ihrer Seite für gehostete Javascript-Bibliotheken zu verwenden. Developers.google.com/speed/libraries/devguide
Rob Volk

10
Was ist, wenn eine solche HTML-Datei lokal geladen wird (direkt mit dem Browser geöffnet)? Es sieht so aus, als würde Firefox (in diesem Fall 28) die Remote-Ressource dann nicht laden. Sinnvoll, denn dann ist HTTP nicht das übergeordnete Protokoll. Aber das wäre meiner Meinung nach ein Nachteil.
Dr. Jan-Philip Gehrcke

Antworten:


86

Wenn der Browser RFC 1808 Abschnitt 4 , RFC 2396 Abschnitt 5.2 oder RFC 3986 Abschnitt 5.2 unterstützt , verwendet er tatsächlich das Schema der Seiten-URL für Verweise, die mit "//" beginnen.


8
Wird dies von allen gängigen Browsern unterstützt? (IE7, IE8, FF, Chrome, Safari)
Rob Volk

22
In Anbetracht der Tatsache, dass der erste RFC, der ihn beschreibt, RFC 1808, vor 15 Jahren geschrieben wurde und URL-Verweise der Schlüssel zur Funktionalität der Website sind, kann man mit Sicherheit sagen, dass dies mittlerweile von so ziemlich allen gängigen Browsern unterstützt wird. Aber der einzige Weg, um sicher zu wissen, ist, es einfach selbst zu versuchen und zu sehen, was passiert.
Remy Lebeau

2
Diese Frage wurde von jemandem verlinkt, der eine ähnliche Frage gestellt hat, und ich habe sie im Jahr zuvor in RFC 1630 gefunden (anders angegeben, aber das fragliche Format immer noch zulässig). Es könnte durchaus in der einen oder anderen Form des Dokuments vorliegen, das ftp://info.cern.ch/pub/www/doc/http-spec.txt1991 begann, sollte jemand eine Archivkopie haben.
Jon Hanna

4
"2014.12.17: Jetzt, da SSL für alle empfohlen wird und keine Leistungsprobleme mehr besteht, ist diese Technik jetzt ein Anti-Pattern. Wenn das benötigte Asset über SSL verfügbar ist, verwenden Sie immer das https: // Asset." (Zitat zitiert aus stackoverflow.com/a/27999789 )
joonas.fi

@ joonas.fi Diese Argumentation ist sophomorisch. SSL hat immer noch Auswirkungen auf die Leistung und wird in einer Vielzahl von Anwendungen nicht benötigt. Ich bevorzuge es natürlich, es zu verwenden, aber ich möchte nicht, dass dies beispielsweise in Code erzwungen wird, den ich bereitstelle.
Otheus

64

Bei Verwendung auf einem linkoder @importlädt IE7 / IE8 die Datei zweimal unter http://paulirish.com/2010/the-protocol-relative-url/ herunter.

Update von 2014:

Jetzt, da SSL für alle empfohlen wird und keine Leistungsbedenken hat , ist diese Technik jetzt ein Anti-Pattern . Wenn das Asset Sie auf SSL verfügbar ist, dann immer die Verwendung https://Vermögenswert.


18
In IE9, FWIW behoben.
EricLaw

@EricLaw ist das in IE9 unabhängig vom Rendering-Modus oder nur im Standard-Modus behoben und im Quirks-Modus immer noch defekt?
Scunliffe

Ich bin mir fast sicher, dass dies in allen Modi des Lookahead-Scanners behoben wurde. Hast du irgendwo anders gesehen?
EricLaw

SSL sicher hat Auswirkungen auf die Leistung haben. Der EFF schreibt keine Server-Server-Schnittstellen, und diese andere Site verfügt über wenig technisches Fachwissen. Ferner ist es ein Anti-Muster anzunehmen, dass der Anbieter einer Website solche Einschränkungen durchsetzen wird. Daher sollten Benutzer CSS schreiben, und Javascript-Anwendungen sollten sich nicht auf die Protokollfrage verlassen.
Otheus

63

Ein Nachteil tritt auf, wenn Ihre URLs außerhalb des Kontexts einer Webseite angezeigt werden. Beispielsweise hat eine E-Mail-Nachricht in einem E-Mail-Client (z. B. Outlook) effektiv keine URL, und wenn Sie eine Nachricht mit einer protokollbezogenen URL anzeigen, gibt es überhaupt keinen offensichtlichen Protokollkontext (die Nachricht selbst ist unabhängig des Protokolls, das zum Abrufen verwendet wird, unabhängig davon, ob es sich um POP3, IMAP, Exchange, uucp oder was auch immer handelt), sodass die URL kein Protokoll enthält, zu dem sie relativ sein kann. Ich habe die Kompatibilität mit E-Mail-Clients nicht untersucht, um zu sehen, was sie tun, wenn ein fehlender Protokollhandler angezeigt wird. Ich vermute, dass die meisten unter http raten werden. Apple Mail verweigert die Eingabe einer URL ohne Protokoll. Es ist analog zu der Art und Weise, wie relative URLs in E-Mails aufgrund eines ähnlich fehlenden Kontexts nicht funktionieren.

Ähnliche Probleme können in anderen Nicht-HTTP-Kontexten auftreten, z. B. in Tweets, SMS-Nachrichten, Word-Dokumenten usw.

Die allgemeinere Erklärung ist, dass anonyme Protokoll-URLs nicht isoliert arbeiten können. Es muss einen relevanten Kontext geben. Auf einer typischen Webseite ist es daher in Ordnung, eine Skriptbibliothek auf diese Weise abzurufen. Externe Links sollten jedoch immer ein Protokoll angeben. Ich habe einen einfachen Test ausprobiert: //stackoverflow.comKarten file:///stackoverflow.comin allen Browsern, in denen ich es ausprobiert habe, damit sie wirklich nicht von alleine funktionieren.


5
Das ist ein wirklich guter Punkt, ich habe tatsächlich darüber nachgedacht, als ich letzte Nacht eingeschlafen bin. Ein weiteres Problem ist, dass die Version httpsoder httpmöglicherweise nicht verfügbar ist. Sie können nicht immer davon ausgehen, dass dies der Fall ist.
Wesley Murch

1
Außerhalb eines Browsers sind Sie sozusagen auf sich allein gestellt. Es gibt kein Wort darüber, ob die E-Mail oder ein anderer Client etwas über Javascript oder CSS usw. weiß. Das ist also so ziemlich ein strittiger Punkt über relative URLs?
chris

Kein strittiger Punkt. Viele E-Mail-Clients unterstützen JS und Browser können dies sicherlich beim Laden von file://. Es ist ein kleiner Anwendungsfall, aber wenn es auftaucht, ist es wichtig.
Jun-Dai Bates-Kobashigawa

Ich wünschte , es eine Möglichkeit zu geben war Gebrauch http es sei denn , die aktuelle URL https ist, wobei in diesem Fall der Verwendung https statt Angabe Verwendung das gleiche Protokoll , dass die aktuellen Seiten mit geladen wurden , die effektiv ist , was //ist.
Jun-Dai Bates-Kobashigawa

2
Wenn Sie ein zB angeben <base href="https://www.google.com">, können Sie den Inhalt außerhalb der Webseite anzeigen. entweder <img src="//www.google.com/images/srpr/logo11w.png">oder<img src="images/srpr/logo11w.png">
Zick

3

Der Grund könnte sein, tragbare Webseiten bereitzustellen. Wenn die äußere Seite nicht verschlüsselt transportiert wird (http), warum sollten die verknüpften Skripte verschlüsselt werden? Dies scheint ein unnötiger Leistungsverlust zu sein. Falls die äußere Seite sicher verschlüsselt (https) transportiert wird, sollte auch der verknüpfte Inhalt verschlüsselt werden. Wenn die Seite verschlüsselt ist und der verknüpfte Inhalt nicht, scheint der IE eine Warnung zu gemischtem Inhalt auszugeben. Der Grund ist, dass ein Angreifer die Skripte unterwegs manipulieren kann. Siehe http://ie.microsoft.com/testdrive/Browser/MixedContent/Default.html?o=1Eine längere Diskussion finden .

Die HTTPS Everywhere- Kampagne des EFF schlägt vor, wann immer möglich https zu verwenden. Wir haben heutzutage die Serverkapazität, um Webseiten immer verschlüsselt bereitzustellen.



-2

Es scheint jetzt eine ziemlich verbreitete Technik zu sein. Es gibt keinen Nachteil, es hilft nur, das Protokoll für alle Assets auf der Seite zu vereinheitlichen, und sollte daher nach Möglichkeit verwendet werden.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.