Welche Vorteile bietet die Verwendung von // anstelle von http:// (adaptives https)?

//Standardprotokoll

/Die Verwendung des Standardprotokolls bedeutet, dass das Ressourcenzugriffsprotokoll mit der aktuellen Seite übereinstimmt. Wenn die aktuelle Seite http ist, wird für den Zugriff das http-Protokoll verwendet. Wenn es https ist, wird für den Zugriff das https-Protokoll verwendet. Auf diese Weise muss der Code nicht geändert werden, egal ob er http ist oder auf https aktualisiert wird. Viele CDN-Ressourcen werden jetzt auf diese Weise referenziert. Es wird im Allgemeinen in internen Links verwendet, da der Protokollheader externer Links unsicher ist.

Was bedeutet //?

// ist das Standardprotokoll, beispielsweise

//jb51.net/css/

Standardprotokoll verwendet standardmäßig das aktuelle Protokoll

Wenn die aktuelle Seite HTTP ist, entspricht dies

http://jb51.net/css/

Wenn die aktuelle Seite HTTPS verwendet, wird das Äquivalent

https://jb51.net/css/

Welche Bedingungen und Vorteile bietet die Verwendung von // anstelle von http://?

Die aktuelle Seite und die Zielressource unterstützen sowohl HTTP als auch HTTPS. Upgrade von http auf https

Dies hat den Vorteil, dass das Ressourcenanforderungsprotokoll adaptiv ausgewählt werden kann, je nachdem, wie der Benutzer die Seite öffnet.

Für den Inhalt von https-Seiten organisiert der Browser standardmäßig Nicht-https-Inhalte, wodurch diese Situation vermieden werden kann

// Mangel

Wenn Sie eine lokale Datei direkt zum Debuggen öffnen, wird das Dateiprotokoll (file://) verwendet.

Zu diesem Zeitpunkt wird das Protokoll zu file://jb51.net/css/, was offensichtlich nicht existiert.

Bleiben Sie mit dem Protokoll der aktuellen Website konsistent, veröffentlichen Sie schnell eine Version, die Ihrem aktuellen Protokoll entspricht, und reduzieren Sie die Bereitstellungskosten von SSL oder anderen Protokollversionen. Entwickler müssen sich nicht darum kümmern, welches Protokoll die Server-Cloud bereitstellt, sie müssen lediglich //-Symbole verwenden, um die am besten geeigneten Übereinstimmungen darzustellen, was mit der Denkweise von nodeJS übereinstimmt.

Die Vorteile sind wie folgt:

Da viele Websites http auf https aktualisiert haben, kann dies verhindern, dass unsere Website entführt wird. Um Fehler während des Konvertierungsprozesses zu vermeiden, haben wir im Frühstadium keinen Sprung erzwungen. Das heißt, wenn Benutzer auf http oder https zugreifen, können sie normal darauf zugreifen, aber die darin enthaltenen js, Bilder, Links usw. können https oder http nicht verwenden. Was ist also die Lösung? Die Lösung besteht darin, // ohne http: und https zu verwenden.

//Diese Schreibweise fügt automatisch das Protokoll basierend auf dem von Ihnen angeforderten Protokoll hinzu. Beispiel: Wenn Ihre Website das HTTP-Protokoll verwendet, besuchen Sie tatsächlich http://xxxx. Wenn Ihre Website das HTTPS-Protokoll verwendet, lautet die angeforderte Adresse https://xxxx. Sie sollten wissen, dass Sie, wenn Sie http://xxx schreiben, möglicherweise eine Sicherheitswarnung erhalten, und einige Browser können die Seite möglicherweise nicht normal laden. Wenn Sie es direkt als https schreiben, sollten Sie wissen, dass die lokale Entwicklung http ist ...

Im Folgenden finden Sie einige klassische Antworten von Zhihu

Viele haben auf die Frage nach den Vorteilen geantwortet. Am deutlichsten wird dieser Vorteil natürlich durch ein https-Upgrade. Ich möchte lediglich einen Grund angeben, warum die Leute zuvor es nicht so geschrieben haben. Natürlich gibt es tatsächlich viele Front-End-Entwickler, die nicht wissen, wie man das schreibt. Aber selbst wenn Sie das wissen, können Sie es wahrscheinlich nicht so schreiben. Da viele frühere Versionen des UC-Browsers diese Schreibweise nicht unterstützen, verstehen sie //ab/ direkt als /ab/. Das heißt, wenn Sie die Adresse //example-cdn.net/static-file auf die Seite http://example.com schreiben, greift UC tatsächlich auf http://example.com/example-cdn.net/static-file zu. Jeder kennt den bisherigen Marktanteil von UC. Also……

Ich erkenne auf den ersten Blick, dass Sie kein „vollständiges HTTPS-Upgrade der Site“ durchgeführt haben. Als ich die gesamte Site auf HTTPS aktualisiert habe, wollte ich am liebsten jeden umbringen, der http:// geschrieben hat. Insbesondere die Links in der Datenbank und die in JS zusammengefügten URLs. Dabei kamen verschiedene reguläre Ausdrücke zum Einsatz und es war zudem eine manuelle Überprüfung erforderlich. Leider gibt es zu viele Programmierer, die http:// schreiben, daher muss ich aufgeben. Jemand hat in den Kommentaren nach dem Grund gefragt. Der Grund ist, dass ich, wenn ich alles mit // schreibe, die Daten und den Quellcode in der Datenbank nicht ändern muss, sondern https direkt aktualisieren kann. Sie sagen vielleicht, dass HTTPS-Konvertierungen selten vorkommen. Zufälligerweise bin ich sowohl bei Tencent als auch bei Alibaba auf HTTPS-Konvertierungen gestoßen. Als ich bei Alibaba war, war ich für die Frontend-Code-Konvertierung der gesamten 1688-Website verantwortlich (einzelne Abteilungen konvertierten sie selbst) (nicht nur HTML, sondern auch CSS, JS, Velocity-Vorlagen usw.! Es war wirklich eine schmutzige und anstrengende Arbeit, warum zum Teufel sollte ich diesen Job annehmen?). Raten Sie mal, wie oft ich die Leute beschimpft habe, die http:// geschrieben haben? Einige Frontend-Entwickler schreiben http sogar direkt in JS. Werden Sie sterben, wenn Sie das Protokoll der aktuellen Seite verwenden?

Einige Frontends akzeptieren nur http:// und https://, aber nicht //, wenn sie reguläre Ausdrücke zur Beurteilung von URLs verwenden. Das ist wirklich ein Mangel an gesundem Menschenverstand. Zu viele Programmierer, zu dumm. Oder vielleicht haben sie einfach noch nie von HTTPS gehört. Wenn Sie es immer noch nicht verstehen, lassen Sie mich Ihnen ein paar Fragen stellen: Wenn Sie http:// verwenden, gehen Sie davon aus, dass die aktuelle Seite das http-Protokoll verwendet. Wie können Sie als Front-End-Entwickler das Protokoll der aktuellen Seite bestimmen? Wussten Sie nicht, dass HTTP-Links auf HTTPS-Seiten Fehler melden? Sie sollten das Protokoll der aktuellen Seite verwenden, also müssen Sie // schreiben. Wenn Sie https:// verwenden, tritt das gleiche Problem auf. Woher wissen Sie, ob es in drei Jahren ein https:// geben wird? Werden Sie dann alle auf https:// umstellen? Machen Sie keine Annahmen, die offensichtlich falsch sind! Sie wissen nicht einmal, mit welchem ​​Protokoll die aktuelle Seite geöffnet wird! Sie müssen also //! verwenden. Es gibt viele ähnliche Fehlannahmen. Viele chinesische Programmierer glauben beispielsweise, dass Telefonnummern nur aus Zahlen und Klammern bestehen, nicht aus Buchstaben. Ist das wirklich der Fall?

Manche meinen, ein globaler Austausch sei ausreichend? Angenommen, Taobao wird auf https umstellen, also ersetzen Sie alle http:// durch //. Der erste Fehler: Sie haben <a href="http://tmail.com"> durch <a href="//tmail.com"> ersetzt, aber http://tmail.com unterstützte zu diesem Zeitpunkt kein https, also haben Sie die Domänennamen innerhalb eines bestimmten Bereichs ersetzt, http://(taobao|taobao2|taobao3).com durch //$1.com. Der zweite Fehler: Manche JS werden folgendermaßen geschrieben: url = "http://" + location.hostname + '/' + path, und manche JS werden folgendermaßen geschrieben: /^http:\/\//.test(input). Sie sagten, dass hierfür keine regulären Ausdrücke verwendet werden können. Suchen Sie einfach global in allen JS nach http und überprüfen Sie es dann manuell. Wissen Sie, wie viele JS-Dateien Taobao hat? Und diese Dateien werden zehn Jahre lang zwischengespeichert. Selbst wenn Sie sie ändern, werden sie möglicherweise nicht aktualisiert. Und wenn Sie einen Fehler machen und die Bestellungen der Benutzer beeinträchtigen, können Sie es sich leisten, Jack Ma für einen Verlust von 100 Millionen zu entschädigen? Der dritte Fehler: Manche Daten stehen gar nicht im Code, sondern in der Datenbank. Beispielsweise beginnt der Wert von user.image mit http. Sie schreiben also user.image als user.image.replace('http://', ​​​​'//') oder ändern die Daten direkt in der Datenbank (bei großen Datenmengen ist dies grundsätzlich unmöglich). Der vierte Fehler: Sie haben vergessen, den Domänennamen in nginx und crossdomain zu ändern. Der fünfte Fehler: Sie haben vergessen, die Basis-URL im Konfigurationssystem zu ändern. Der sechste Fehler: Ihre https-Seite bettet ein externes http-Iframe ein ... Weinen Sie einfach, das ist schwer zu lösen. Wenn Sie Glück haben, ändern Sie es einfach in // (externe Unterstützung für https). Wenn Sie Pech haben, müssen Sie die Seitenlogik ändern. Der N-te Fehler ... HTTPS-Upgrades sind eine schmutzige und ermüdende Arbeit. Sie sagen, es sei einfach und Sie machen es, aber wenn Sie erst einmal damit anfangen, werden Sie wissen, wie viele Dinge damit verbunden sind. Die beste Lösung besteht darin, das Protokoll leicht änderbar zu machen, z. B. indem man der aktuellen Seite folgt oder Variablen verwendet. Es ist auf jeden Fall keine gute Idee, http:// fest zu codieren. Manche Programmierer wissen, dass HTTPS existiert, versuchen aber beim Schreiben des Codes nicht, es kompatibel zu machen. Sie denken sich: „Ich verlasse die Firma in zwei Jahren, und HTTPS wird es noch mindestens drei Jahre lang geben“, und dann schreiben sie Müllcode.

Immer mehr Entwickler verwenden // statt http:// beim Verknüpfen von Dateien. Beispielsweise wird < a href="http://jb51.net... im Allgemeinen als < a href = " //http://jb51.net... geschrieben. Was ist der Unterschied zum herkömmlichen http?

Ursprünglich war Ihre Website http, und alle srcs begannen mit http. Sie dachten, sie sei von einem miesen Betreiber gekapert worden, und Ihre Seiten waren mit einer Menge Inhalt gefüllt, der nicht für Kinder geeignet ist und reine Werbung darstellt. Jemand hat Ihnen gesagt, dass das Ersetzen von https dieses Problem beheben kann. An diesem Punkt werden Sie wissen, wie klug es war, // statt http:// in die vorherigen srcs und Ajaxs zu schreiben. . .

Zhulang CMS Offizieller

Mit dem Aufkommen von immer mehr Open Source- und Cloud-Plattformen und der weit verbreiteten Einführung des SSL-Protokolls (beispielsweise hat Zhulang CMS die vollständige Unterstützung des SSL-Protokolls aktiviert) müssen sich die Leute bei der Entwicklung mit der Auswahl und Identifizierung des http-Protokolls auseinandersetzen. Wie wir alle wissen, können zu viele SSL-Referenzen die Effizienz normaler Sites beeinträchtigen. Wir können jedoch zu diesem Zweck keine reine SSL-Version neu entwerfen. Was Open-Source-Bibliotheken betrifft, bieten allgemeine Plattformen sowohl SSL- als auch Nicht-SSL-Versionen. Wie diese beiden Bibliotheken: https://code.z01.com/js/jquery-3.2.1.slim.min.jshttp://code.z01.com/js/jquery-3.2.1.slim.min.js, ihre Referenzeffekte sind konsistent. Daher verwenden Entwickler direkt die Methode „//URL/Datei“, um das vorherige Protokoll zu ersetzen, sodass es automatisch erkannt werden kann. Das heißt, unabhängig davon, ob es sich um das SSL-Protokoll oder das normale http-Protokoll handelt, muss der Browser es automatisch erkennen und automatisch mit der aktuellen Site abgleichen, um die sicherste Anforderung und die effizienteste Lademethode zu erreichen. Kurz gesagt handelt es sich hierbei um eine Entwicklungsmethode und ein Entwicklungsdenken. Die Web- und Mobilentwicklung im Cloud-Computing wird von Tag zu Tag stärker.