我创建了一个简单的HTML页面，其中iframe的src属性引用了包含它的页面——换句话说，是一个自引用的iframe。
this.html
<html>
<head></head>
<body>
<iframe src="this.html"></iframe>
</body>
</html>
为什么这不是无限循环和崩溃我的浏览器?还有，为什么连IE都不会崩溃呢?
(注意:这源于一个关于使用iframe来解决问题的优点和缺点的团队讨论。你知道，就是那种"镜中的镜"。
W3C在1997年的《实现HTML框架》中解释了框架应该如何实现:
任何试图将其祖先使用的URL分配为SRC的帧都被视为根本没有SRC URL(基本上是一个空白帧)。
Iframe递归错误/攻击历史
kingdago发现并在上面的评论中提到，有一个浏览器在1999中的Mozilla没有为此实现保护。引用一个开发人员的话:
这是自MSIE5以来的奇偶校验错误(也是可能的尴尬来源)这类页面没有问题
我决定深入研究一下，结果发现在2004中又发生了这种情况。然而，这次涉及到JavaScript:
这是代码，它的原因:
…
实际结果:父窗口被递归加载到Iframe，有时导致崩溃。
预期结果:就像在Internet Explorer中显示一样。
然后在2008使用Firefox 2(这也涉及JavaScript)。
2009。有趣的是，这个bug 仍然是打开的和这个附件:https://bugzilla.mozilla.org/attachment.cgi?id=414035(你会抑制你的好奇心吗?)仍然会崩溃/冻结你的Firefox(我刚刚测试了它，我几乎崩溃了整个Ubuntu)。在Chrome浏览器中，它只是无限加载(可能是因为每个选项卡生活在一个单独的进程)。
对于其他浏览器:
- 在2005 Konqueror有一个bug在它的保护，允许渲染iframe一个在另一个(但似乎不知何故，它并没有冻结/崩溃整个应用程序)。据报道，IE6、Opera 7.54和Firefox 0.9.3也容易受到基于iframe递归的攻击。
我想添加一点东西到"另外，为什么连IE都不会崩溃呢?"问题的一部分。IE没有让我们失望……
如果你添加一个简单的迭代数作为查询字符串到嵌套的iFrame的src Firefox和其他将在一定的迭代深度后停止。IE——我们在IE 10版本中测试了这个——只是崩溃了:)
this.php
<html>
<head></head>
<body>
<iframe src="this.php?q=<?php echo (isset($_GET['q'])?$_GET['q']:1)+1?>" />
</body>
</html>
没有脚本IE 6.0会崩溃
<iframe src="this.html?c=9"></iframe>
我不知道为什么这不会触发循环检测，也不知道它是否改变了。
编辑:知道原因了。因为它是一个本地文件，?之后的URL被忽略，所以只有this.html被标记为访问过，而不是this.html?c=9。