Kann ich alle meine http: // Links auf nur // ändern?

Dave Ward sagt:

Es ist nicht gerade leicht zu lesen, aber Abschnitt 4.2 von RFC 3986 enthält vollständig qualifizierte URLs, bei denen das Protokoll (HTTP oder HTTPS) insgesamt weggelassen wird. Wenn das Protokoll einer URL weggelassen wird, verwendet der Browser stattdessen das Protokoll des zugrunde liegenden Dokuments.

Einfach ausgedrückt, ermöglichen diese "protokolllosen" URLs, dass eine solche Referenz in jedem Browser funktioniert, in dem Sie sie ausprobieren:

//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js

Auf den ersten Blick sieht es seltsam aus, aber diese "protokolllose" URL ist der beste Weg, um auf Inhalte von Drittanbietern zu verweisen, die sowohl über HTTP als auch über HTTPS verfügbar sind.

Dies würde sicherlich eine Reihe von Fehlern mit gemischtem Inhalt lösen, die auf HTTP-Seiten auftreten - vorausgesetzt, unsere Assets sind sowohl über HTTP als auch über HTTPS verfügbar.

Ist das vollständig browserübergreifend kompatibel? Gibt es noch andere Einschränkungen?

Ich habe es vor der Veröffentlichung gründlich getestet. Von allen Browsern, die zum Testen auf Browsershots verfügbar sind , konnte ich nur einen finden, der die relative URL des Protokolls nicht korrekt handhabte: einen obskuren * nix-Browser namens Dillo .

Es gibt zwei Nachteile, zu denen ich Feedback erhalten habe:

1. Protokolllose URLs funktionieren möglicherweise nicht wie erwartet, wenn Sie eine lokale Datei in Ihrem Browser "öffnen", da das Basisprotokoll der Seite file: /// ist. Insbesondere, wenn Sie die protokolllose URL für eine externe Ressource wie ein von CDN gehostetes Asset verwenden. Die Verwendung eines lokalen Webservers wie Apache oder IIS zum Testen anhand von http: // localhost- Adressen funktioniert jedoch einwandfrei.
2. Anscheinend gibt es mindestens eine iPhone-Feed-Reader-App, die die protokolllosen URLs nicht korrekt verarbeitet. Mir ist nicht bekannt, wer das Problem hat oder wie beliebt es ist. Das Hosten einer JavaScript-Datei ist kein großes Problem, da RSS-Reader JavaScript-Inhalte normalerweise sowieso ignorieren. Es kann jedoch ein Problem sein, wenn Sie diese URLs für Medien wie Bilder in Inhalten verwenden, die über RSS syndiziert werden müssen (obwohl diese App mit einem einzigen Leser auf einer einzigen Plattform wahrscheinlich nur eine sehr geringe Anzahl von Lesern ausmacht).

Die Frage, ob man alle ihre Links so ändern könnte , dass sie protokollbezogen sind, kann strittig sein, wenn man bedenkt, ob man dies tun sollte . Laut Paul Irish :

2014.12.17: Jetzt, da SSL für alle empfohlen wird und keine Leistungsbedenken hat, ist diese Technik jetzt ein Anti-Pattern. Wenn das von Ihnen benötigte Asset über SSL verfügbar ist, verwenden Sie immer das Asset https: // .

Wenn Sie zum Laden von Stylesheets protokolllose URLs verwenden, werden diese von IE 7 und 8 zweimal heruntergeladen: http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/

Dies ist für CSS zu vermeiden, wenn Sie eine gute Leistung wünschen.

Ja, Netzwerkpfadreferenzen wurden bereits in RFC 1808 angegeben und sollten mit allen Browsern funktionieren.

Ist das vollständig browserübergreifend kompatibel? Gibt es noch andere Einschränkungen?

Nur um dies in den Mix zu werfen, wenn Sie auf einem lokalen Server entwickeln, funktioniert es möglicherweise nicht. Sie benötigen ein Programm angeben, sonst wird der Browser davon ausgehen kann , dass src="//cdn.example.com/js_file.js"ist src="file://cdn.example.com/js_file.js", was zu brechen , da Sie nicht auf diese Ressource lokal Hosting.

Microsoft Internet Explorer scheint hierfür besonders sensibel zu sein. Siehe folgende Frage: jQuery kann nicht in Internet Explorer auf localhost (WAMP) geladen werden.

Sie würden wahrscheinlich immer versuchen, eine Lösung zu finden, die in all Ihren Umgebungen mit den geringsten erforderlichen Änderungen funktioniert.

Die von HTML5Boilerplate verwendete Lösung besteht darin, einen Fallback zu haben, wenn die Ressource nicht korrekt geladen ist. Dies funktioniert jedoch nur, wenn Sie eine Prüfung einbinden :

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<!-- If jQuery is not defined, something went wrong and we'll load the local file -->
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.10.2.min.js"><\/script>')</script>

Ich habe diese Antwort auch hier gepostet .

UPDATE: HTML5Boilerplate wird jetzt verwendet, <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js">nachdem entschieden wurde, protokollbezogene URLs zu verwerfen (siehe hier) .

Ich hatte diese Probleme bei der Verwendung von: //domain.com nicht - aber Sie müssen den Doppelpunkt am Anfang hinzufügen. Yoast hatte vor einiger Zeit einen guten Bericht darüber. Aber es ist in seinem Stapel von Blog-Posts verloren.

Wenn Sie sicherstellen möchten, dass alle Anforderungen auf ein sicheres Protokoll aktualisiert werden, gibt es eine einfache Option, um die Header für die Aktualisierung der Inhaltssicherheitsrichtlinie zu verwenden

Content-Security-Policy: upgrade-insecure-requests;

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests