Warum läuft ein selbstreferenzierender Iframe nicht in einer Endlosschleife und stürzt meinen Computer ab?

Question 1

Ich habe eine einfache HTML-Seite mit einem erstellt iframe Deren src -Attribut verweist auf die enthaltende Seite – mit anderen Worten auf einen selbstreferenzierenden Iframe.

diese.html

<html>
<head></head>
<body>
<iframe src="https://stackoverflow.com/questions/14223628/this.html"></iframe>
</body>
</html>

Warum läuft das nicht in einer Endlosschleife und stürzt meinen Browser ab? Außerdem, warum stürzt nicht einmal der IE dabei ab?

(Hinweis: Dies ist aus einer Teamdiskussion über die Vorzüge und Nachteile der Verwendung von Iframes zur Lösung von Problemen hervorgegangen. Sie wissen schon, die Art „Spiegel des Spiegels“.)

Question 2

Das W3C hat sich 1997 darum gekümmert und erklärt, wie Frames in implementiert werden sollten “Implementieren von HTML-Frames“:

Jeder Frame, der versucht, als seinen SRC eine URL zuzuweisen, die von einem seiner Vorfahren verwendet wird, wird so behandelt, als hätte er überhaupt keine SRC-URL (im Grunde ein leerer Frame).

Verlauf von Iframe-Rekursionsfehlern/-angriffen

Wie kingdago herausfand und im obigen Kommentar erwähnte, war ein Browser, der es versäumt hat, einen Schutz dafür zu implementieren Mozilla in 1999. Zitat von einem der Entwickler:

Dies ist ein Paritätsfehler (und eine Quelle möglicher Verlegenheit), da MSIE5 kein Problem mit dieser Art von Seiten hat.

Ich beschloss, mich eingehender damit zu beschäftigen, und es stellte sich heraus, dass dies der Fall war 2004 das ist passiert wieder. Diesmal jedoch JavaScript war beteiligt:

Dies ist der Code, der es verursacht: direkt gefolgt von einem Skript mit diesem darin: frames.productcatalog.location.replace(frames.productcatalog.location + location.hash);

…

Tatsächliche Ergebnisse: Das übergeordnete Fenster wird rekursiv in den Iframe geladen, was manchmal zu einem Absturz führt.

Erwartete Ergebnisse: Zeigen Sie es einfach wie im Internet Explorer an.

Dann wieder in 2008 mit Firefox2 (dies betraf auch JavaScript).

Und wieder in 2009. Der interessante Teil hier ist, dass dieser Fehler ist noch offen und dieser Anhang: https://bugzilla.mozilla.org/attachment.cgi?id=414035 (können Sie Ihre Neugier zügeln?) wird Ihren Firefox immer noch zum Absturz bringen/einfrieren (ich habe es gerade getestet und ich hätte fast das ganze Ubuntu zum Absturz gebracht). In Chrome wird es nur auf unbestimmte Zeit geladen (wahrscheinlich, weil jede Registerkarte in einem separaten Prozess lebt).

Bei den anderen Browsern:

Im 2005 Eroberer hatte einen Fehler in seinem Schutz, der es erlaubte, Iframes zu rendern eins im anderen (aber es scheint, dass es irgendwie nicht die ganze App eingefroren / abgestürzt hat).

IE6, Opera 7.54 und Firefox 0.9.3 sind es auch gemeldet um anfällig für Angriffe zu sein, die auf Iframe-Rekursion basieren.

Question 3

Dem möchte ich noch eine Kleinigkeit hinzufügen “Außerdem, warum stürzt nicht einmal der IE dabei ab?” Teil der Frage. IE lässt uns nicht im Stich…

Wenn Sie eine einfache Iterationsnummer als Abfragezeichenfolge zum src des verschachtelten iFrame hinzufügen, werden Firefox und andere nach einer bestimmten Iterationstiefe einfach aufhören. IE – und wir haben das mit IE Version 10 getestet – stürzt einfach ab 🙂

diese.php

<html>
<head></head>
<body>
<iframe src="https://stackoverflow.com/questions/14223628/this.php?q=<?php echo (isset($_GET["q'])?$_GET['q']:1)+1?>" />
</body>
</html>

Question 4

IE 6.0 kann ohne Skript abstürzen:

<iframe src="this.html?c=9"></iframe>

Ich bin mir nicht sicher, warum dies keine Schleifenerkennung auslöst oder ob es sich geändert hat.