Pourquoi un iframe auto-référencé ne boucle-t-il pas à l’infini ma machine?

J’ai créé une page HTML simple avec un iframe dont l’atsortingbut src référence à la page contenant – autrement dit un iframe auto-référencé.

this.html

Pourquoi cela ne boucle-t-il pas à l’infini mon navigateur? En outre, pourquoi ne pas même IE se casser à cela?

(Note: Ceci est le résultat d’une discussion en équipe sur les vertus et les inconvénients de l’utilisation des iframes pour résoudre des problèmes. Vous savez, le “miroir d’un miroir”.)

Le W3C s’en est occupé en 1997 pour expliquer comment les frameworks devaient être implémentés dans ” Implémentation de frameworks HTML “:

Toute image qui tente d’atsortingbuer comme adresse SRC une URL utilisée par l’un de ses ancêtres est traitée comme si elle ne contenait aucune URL SRC (essentiellement un cadre vide).

Historique de bogue / attaque de récursion Iframe

Comme Kingdago l’a découvert et mentionné dans le commentaire ci-dessus, un navigateur qui avait manqué de mettre en place une sauvegarde était Mozilla en 1999 . Citation d’un des développeurs:

Il s’agit d’un bogue de parité (source d’embarras possible) car MSIE5 n’a pas de problème avec ce type de pages.

J’ai décidé d’en creuser davantage et il s’avère qu’en 2004, cela s’est encore produit. Cependant, cette fois-ci, JavaScript a été impliqué:

C’est le code, quelle en est la cause: </ iframe> suivi directement par un script avec cela: frames.productcatalog.location.replace (frames.productcatalog.location + location.hash);

…

Résultats réels: La fenêtre parente est chargée de manière récursive dans l’iframe, entraînant parfois un blocage.

Résultats attendus: affichez-le simplement dans Internet Explorer.

Puis à nouveau en 2008 avec Firefox 2 (cela impliquait également JavaScript).

Et encore en 2009 . La partie intéressante ici est que ce bogue est toujours ouvert et cette pièce jointe: https://bugzilla.mozilla.org/attachment.cgi?id=414035 (allez-vous limiter votre curiosité?) Va toujours planter / geler votre Firefox (je viens de testé et j’ai failli écraser la totalité d’Ubuntu). Dans Chrome, il se charge indéfiniment (probablement parce que chaque onglet vit dans un processus distinct).

Comme pour les autres navigateurs:

En 2005, Konqueror avait un bug dans sa sauvegarde qui permettait de rendre les iframes les uns dans les autres (mais il semble que d’une manière ou d’une autre il ne gèle pas ou ne plante pas l’application entière).
IE6, Opera 7.54 et Firefox 0.9.3 seraient également sensibles aux attaques basées sur la récursivité iframe.

Je voudrais append un petit quelque chose à la “Pourquoi, même pas IE IE crash à cela?” partie de la question. IE ne nous laisse pas tomber …

Si vous ajoutez un simple numéro d’itération comme chaîne de requête au src Firefox de l’iFrame nested et que d’autres s’arrêtent juste après une certaine profondeur d’itération. IE – et nous avons testé cela avec IE version 10 – se bloque simplement 🙂

this.php