我创建了一个简单的HTML页面iframe ，其src属性引用包含页-换句话说自引用iframe中。
this.html
<html>
<head></head>
<body>
<iframe src="this.html"></iframe>
</body>
</html>
为什么这个不是无限循环和系统崩溃我的浏览器？ 另外，为什么在这个甚至没有IE浏览器崩溃？
（注：这从美德和使用的iframe解决问题的缺点团队讨论催生你知道，那种“一镜走的镜子”。）
Answer 1:
W3C照顾的是，在1997年解释如何帧应在“实施实现HTML框架 ”：
试图分配作为其SRC通过任何祖先中使用的URL的任何帧被视为好像它在所有没有SRC URL（基本上是一个空白帧）。
IFRAME递归错误/攻击历史
作为kingdago发现了，在上面的评论中提及，错过实现此一保障一个浏览器是Mozilla的 1999年 。 从开发商之一报价：
这是一个奇偶校验错误（和可能embarrasment的来源），因为MSIE5不会有问题与这些类型的网页。
我决定去挖掘一些更进这一点，事实证明，在2004年这发生了一次 。 不过，这一次JavaScript的参与：
这是代码，什么原因造成的：<IFRAME名称= “productcatalog” ID = “productcatalog” SRC = “page2.htm”> </ IFRAME>随后直接在它与下面的脚本：frames.productcatalog.location.replace （frames.productcatalog.location +的location.hash）;
...
实际结果：父窗口被递归地装入的IFRAME，在碰撞有时导致。
预期结果：就显示它像在Internet Explorer中。
然后又在2008年与Firefox 2（这也参与的JavaScript）。
并再次在2009年 。 这里最有意思的是，这个错误仍然是开放的 ，这个附件： https://bugzilla.mozilla.org/attachment.cgi?id=414035 （？你会限制你的好奇心）仍然会崩溃/冻结你的Firefox（我只是测试它，我几乎崩溃了整个Ubuntu的）。 在Chrome中，它只是加载无限（可能是因为每个标签住在一个单独的进程）。
至于其他浏览器：
- 在2005年 的Konqueror有它的保障，允许渲染iFrame的错误一个在另一个内部 （但似乎不知它没有冻结/崩溃整个应用程序）。
- IE6，歌剧7.54和Firefox 0.9.3也报道易受立足于iframe的递归攻击。
Answer 2:
我想一点东西添加到“而且，为什么在这个连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>
文章来源: Why does a self-referencing iframe not infinitely loop and crash my machine?
