it-swarm.com.de

Ist es zulässig, http: // durch // in einem <script src = "http: // ..."> zu ersetzen?

Ich habe folgendes Element:

<script type="text/javascript" src="https://cdn.example.com/js_file.js"></script>

In diesem Fall ist die Site HTTPS, die Site kann jedoch auch nur HTTP sein. (Die JS-Datei befindet sich in einer anderen Domäne.) Ich frage mich, ob es der Einfachheit halber zulässig ist, Folgendes zu tun:

<script type="text/javascript" src="//cdn.example.com/js_file.js"></script>

Ich frage mich, ob es gültig ist, den http: oder https: zu entfernen?

Es scheint überall zu funktionieren, wo ich getestet habe, aber gibt es Fälle, in denen es nicht funktioniert?

448
Darryl Hein

Eine relative URL ohne Schema (http: oder https :) ist gültig, per RFC 3986: "Uniform Resource Identifier (URI): Generische Syntax", Abschnitt 4.2 . Wenn ein Client daran drosselt, liegt es an dem Client, dass er nicht der im RFC angegebenen URI-Syntax entspricht.

Ihr Beispiel ist gültig und sollte funktionieren. Ich habe diese relative URL-Methode selbst auf stark frequentierten Websites verwendet und hatte keine Beschwerden. Außerdem testen wir unsere Websites in Firefox, Safari, IE6, IE7 und Opera. Diese Browser verstehen alle dieses URL-Format.

379
Jeff

Es funktioniert garantiert in jedem Mainstream-Browser (Browser mit einem Marktanteil von weniger als 0,05% werden nicht berücksichtigt). Heck, es funktioniert in Internet Explorer 3.0.

RFC 3986 definiert einen URI, der sich aus folgenden Teilen zusammensetzt:

     foo://example.com:8042/over/there?name=ferret#nose
     \_/   \______________/\_________/ \_________/ \__/
      |           |            |            |        |
   scheme     authority       path        query   fragment

Bei der Definition relativer URIs ( Abschnitt 5.2 ) können Sie jeden dieser Abschnitte auslassen, immer von links aus. Im Pseudocode sieht das so aus:

 result = ""

  if defined(scheme) then
     append scheme to result;
     append ":" to result;
  endif;

  if defined(authority) then
     append "//" to result;
     append authority to result;
  endif;

  append path to result;

  if defined(query) then
     append "?" to result;
     append query to result;
  endif;

  if defined(fragment) then
     append "#" to result;
     append fragment to result;
  endif;

  return result;

Der von Ihnen beschriebene URI ist ein schemasloser relativer URI.

149
Andrew Moore

gibt es Fälle, in denen es nicht funktioniert?

Wenn die übergeordnete Seite von file:// geladen wurde, funktioniert sie wahrscheinlich nicht (es wird versucht, file://cdn.example.com/js_file.js zu erhalten, den Sie natürlich auch lokal angeben könnten).

77
Thilo

Viele Leute nennen dies eine Protocol Relative URL.

Es verursacht einen doppelten Download von CSS-Dateien in IE 7 & 8 .

40
SLaks

Hier dupliziere ich die Antwort in Versteckte Funktionen von HTML :

Verwendung eines protokollunabhängigen absoluten Pfad:

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

Wenn der Browser eine Seite in .__ anzeigt. SSL über HTTPS, dann wird .__ angefordert. dieses Asset mit dem https-Protokoll, Andernfalls wird es mit HTTP angefordert.

Dadurch wird verhindert, dass die Fehlermeldung "Diese Seite Enthält sowohl sichere als auch nicht sichere Elemente" im IE angezeigt wird alle Ihre Asset-Anfragen in der gleiches Protokoll.

Vorbehalt: Bei Verwendung für einen <link> oder @import für ein Stylesheet, IE7 und IE8 zweimal die Datei herunterladen . Alle Anderen Verwendungen sind jedoch gut.

23
kennytm

Es ist absolut zulässig, das Protokoll zu verlassen. Die URL-Spezifikation ist seit Jahren sehr klar, und ich muss noch einen Browser finden, der sie nicht versteht. Ich weiß nicht, warum diese Technik nicht besser bekannt ist. Es ist die perfekte Lösung für das heikle Problem der Überschreitung von HTTP/HTTPS-Grenzen. Mehr hier: HTTP-https-Übergänge und relative URLs

16
Ned Batchelder

gibt es Fälle, in denen es nicht funktioniert?

Um dies einfach in den Mix zu werfen, funktioniert es möglicherweise nicht, wenn Sie auf einem lokalen Server entwickeln. Sie müssen ein Schema angeben, andernfalls geht der Browser möglicherweise davon aus, dass src="//cdn.example.com/js_file.js"src="file://cdn.example.com/js_file.js" ist. Dies kann zu Fehlern führen, da Sie diese Ressource nicht lokal hosten.

Microsoft Internet Explorer scheint besonders empfindlich zu sein, siehe diese 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 Modifikationen funktioniert.

Die von HTML5Boilerplate verwendete Lösung besteht darin, einen Fallback auszuführen, wenn die Ressource nicht korrekt geladen wird. Dies funktioniert jedoch nur, wenn Sie eine Prüfung durchführen:

<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>

UPDATE: HTML5Boilerplate verwendet jetzt <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js, nachdem beschlossen wurde, protokollrelevante URLs abzulehnen, siehe [hier] [3].

5
bg17aw

Nach der Referenz des Gnud sagt der RFC 3986 Abschnitt 5.2 :

Wenn die Schemakomponente definiert ist, wird angegeben, dass die Referenz Beginnt mit einem Schemanamen, dann wird die Referenz als .__ interpretiert. absolute URI und wir sind fertig. Andernfalls das Schema der Referenz-URI wird von der Schemakomponente des Basis-URIs vererbt .

// stimmt also :-)

3

Bei Verwendung von //somedomain.com als Verweise auf JS-Dateien werden in unseren Protokollen 404 Fehler angezeigt. 

Die Referenzen, die die 404er verursachen, sehen folgendermaßen aus: Ref:

<script src="//somedomain.com/somescript.js" />

404 Anfrage:

http://mydomain.com//somedomain.com/somescript.js

Da diese regelmäßig in unseren Webserver-Protokollen angezeigt werden, können Sie mit Sicherheit sagen: Alle Browser und Bots NICHT - RFC 3986, Abschnitt 4.2. Am sichersten ist es, wenn immer möglich das Protokoll einzubeziehen.

2
Lemiarty

Ja, dies ist in RFC 3986 , Abschnitt 5.2 dokumentiert:

(edit: Ups, meine RFC-Referenz war veraltet).

2
gnud

Es ist in der Tat richtig, wie andere Antworten angegeben haben. Beachten Sie jedoch, dass einige Webcrawler 404s für diese aktivieren, indem Sie sie auf Ihrem Server wie eine lokale URL anfordern. (Sie ignorieren den doppelten Schrägstrich und behandeln ihn als einen einfachen Schrägstrich).

Sie können eine Regel auf Ihrem Webserver einrichten, um diese abzufangen und umzuleiten.

Mit Nginx würden Sie beispielsweise Folgendes hinzufügen:

location ~* /(?<redirect_domain>((([a-z]|[0-9]|\-)+)\.)+([a-z])+)/(?<redirect_path>.*) {
  return 301 $scheme:/$redirect_domain/$redirect_path;
}

Beachten Sie jedoch, dass Sie, wenn Sie Punkte in Ihren URIs verwenden, die Spezifität erhöhen müssen. Andernfalls werden diese Seiten an nicht vorhandene Domänen weitergeleitet.

Dies ist auch ein ziemlich massiver Regex für jede Abfrage. Meiner Meinung nach ist es lohnenswert, nicht kompatible Browser mit 404s zu bestrafen, wenn die Mehrheit der kompatiblen Browser einen (geringen) Performance-Treffer aufweist.

2
jlovison

Das Muster, das ich auf html5-boilerplate sehe, lautet:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.10.2.min.js"><\/script>')</script>

Es läuft problemlos auf verschiedenen Schemata wie http, https, file.

1
neurite

Wenn Sie beispielsweise HTTPS verwenden, sollten Sie überprüfen, ob die externe Domäne auch für SSL eingerichtet ist. Andernfalls werden Ihren Benutzern möglicherweise SSL-Fehler und/oder 404-Fehler angezeigt (z. B. ältere Versionen von Plesk speichern HTTP und HTTPS in separaten Ordnern). Für CDNs sollte dies kein Problem sein, aber für jede andere Website könnte es sein.

Nebenbei bemerkt, eine alte Website aktualisiert und funktioniert auch im url = Teil einer META REFRESH.

0
user2246924

1. Zusammenfassung

Antwort für 2019: Sie können weiterhin protokollrelevante URLs verwenden, aber diese Technikein Antimuster .

Ebenfalls:

  1. Möglicherweise haben Sie Probleme bei der Entwicklung.
  2. Einige Tools von Drittanbietern unterstützen sie möglicherweise nicht.

Die Migration von protokollrelevanten URLs zu https:// wäre Nizza.


2. Relevanz

Diese Antwort ist für Januar 2019 relevant. In Zukunft können die Daten dieser Antwort veraltet sein.


3. Anti-Muster

3.1. Argumentation

Paul Irish - Front-End-Ingenieur und Entwickleranwalt für Google Chrome - schreiben im Dezember 2014 :

Nun, da SSL für alle ermutigt ist und hat keine Performance-Bedenken , , ist diese Technik nun ein Anti-Pattern. Wenn das von Ihnen benötigte Asset für SSL verfügbar ist, verwenden Sie immer das Asset https://.

Wenn das Snippet über HTTP abgerufen werden kann, wird die Tür für Angriffe wie der GitHub-Man-on-the-Side-Angriff Recent geöffnet. Es ist immer sicher, HTTPS-Assets anzufordern, selbst wenn sich Ihre Site auf HTTP befindet. Das umgekehrte ist jedoch nicht wahr .

3.2. Weitere Links

3.3. Beispiele


4. Entwicklungsprozess

Zum Beispiel versuche ich, clean-console zu verwenden.

  • Beispieldatei KiraCleanConsole__cdn_links_demo.html:
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>clean-console without protocol demonstration</title>
    <!-- Really dead link -->
    <script src="https://unpkg.com/[email protected]/bowser.min.js"></script>
    <!-- Package exists; link without “https:” -->
    <script src="//cdn.jsdelivr.net/npm/[email protected]/dist/jquery.min.js"></script>
    <!-- Package exists: link with “https:” -->
    <script src="https://cdn.jsdelivr.net/npm/gemini-scrollbar/index.js"></script>
</head>
<body>
    Kira Goddess!
</body>
</html>
  • ausgabe:
D:\SashaDebugging>clean-console -i KiraCleanConsole__cdn_links_demo.html
checking KiraCleanConsole__cdn_links_demo.html
phantomjs: opening page KiraCleanConsole__cdn_links_demo.html

phantomjs: Unable to load resource (#3URL:file://cdn.jsdelivr.net/npm/[email protected]/dist/jquery.min.js)


phantomjs:   phantomjs://code/runner.js:30 in onResourceError
Error code: 203. Description: Error opening //cdn.jsdelivr.net/npm/[email protected]/dist/jquery.min.js: The network path was not found.

  phantomjs://code/runner.js:31 in onResourceError

phantomjs: Unable to load resource (#5URL:https://unpkg.com/[email protected]/bowser.min.js)


phantomjs:   phantomjs://code/runner.js:30 in onResourceError
Error code: 203. Description: Error downloading https://unpkg.com/[email protected]/bowser.min.js - server replied: Not Found

  phantomjs://code/runner.js:31 in onResourceError

phantomjs: Checking errors after sleeping for 1000ms
2 error(s) on KiraCleanConsole__cdn_links_demo.html

phantomjs process exited with code 2

Link //cdn.jsdelivr.net/npm/[email protected]/dist/jquery.min.js ist gültig, aber ich bekomme eine Fehlermeldung.

Achten Sie auf file://cdn.jsdelivr.net/npm/[email protected]/dist/jquery.min.js und lesen Sie Thilo und bg17aw antwortet über file://.

Ich wusste nichts über dieses Verhalten und konnte nicht verstehen, warum ich Probleme wie this für Pageres habe.


5. Tools von Drittanbietern

Ich benutze Clickable URLs Sublime Text package. Verwenden Sie es, ich kann Links in meinem Texteditor einfach im Browser öffnen.

CSS links examples

Beide Links im Beispiel sind gültig. Aber der erste Link, den ich erfolgreich im Browser öffnen kann, kann anklickbare URLs verwenden, der zweite Link - nein. Dies ist möglicherweise nicht sehr bequem.


6. Schlussfolgerung

Ja:

  1. Wenn Sie Probleme mit Developing process item haben, können Sie Ihren Entwicklungsworkflow einstellen.
  2. Ansonsten haben Sie Probleme wie in Third-party tools item, Sie können Werkzeuge hinzufügen.

Aber Sie brauchen diese zusätzlichen Probleme nicht. Informationen über Links in Anti-pattern item lesen: Protokollrelevante URLs sind veraltet.