IE9只有_sometimes_忽略< base href> [英] IE9 only _sometimes_ ignores <base href>
问题描述
我们正在开发一个大量使用< base href> 的站点（这是TYPO3站点的典型特征）。该网站是在一个子目录中开发的，稍后将重新定位到顶级目录，因此我们不能轻易删除< base href> 。
我们的客户告诉我们，有时当她浏览新页面时，她会得到没有应用布局的页面内容。我们对此进行了调试：它只发生在IE9中。查看日志，我们发现当错误发生时，IE9会尝试从错误的位置加载CSS，JS和所有图像：相对于当前URL，而不是相对于BASE HREF ...进一步检查日志显示我们IE8用户也受到影响，包括一些愚蠢的网络蜘蛛（对于我们来说没有问题，后者，谁在乎？）。
我们已经知道IE8投机下载/超前解析器： http://blogs.msdn.com/b/ieinternals/archive/2009/07/27/bugs-in-the-ie8-lookahead-downloader.aspx
我确定我们没有遇到过描述的错误：所有页面元素（包括第一个头元素）都从错误的位置加载。这个错误描述了页眉中仅有第二个和以后的元素受到影响。我们可以通过在发生问题时观察访问日志来证明这一点。
简单的重新加载解决了这个问题，将页面源代码与发生的错误进行比较，绝对没有区别。
< head> 标记。我们尝试了所有可能的解决方案，没有任何帮助似乎是一个IE错误。
任何其他人遇到此问题并找到解决办法？我们还有其他几个站点使用< base href> ，我们无法在测试系统中重现这种行为 - 所以可能会引发或解决此错误。但我分析了这些网站的日志，并可以看到有些访问者使用IE8甚至会遇到该错误。
正如评论中所要求的，这里是一个混淆的html示例head：
<？xml version =1.0encoding =utf-8？>
<！DOCTYPE html
PUBLIC - // W3C // DTD XHTML 1.0 Transitional // EN
http://www.w3.org/TR/xhtml1/DTD/的xhtml1-transitional.dtd>
< html xml：lang =enlang =enxmlns =http://www.w3.org/1999/xhtml>
< head>
< base href =http://client.site/cms//>
< meta http-equiv =Content-Typecontent =text / html; charset = utf-8/>
<！ -
本网站由TYPO3驱动 - 鼓舞人心的分享！
TYPO3是一个免费的开源内容管理框架，最初由Kasper Skaarhoj创建，并在GNU / GPL下授权。
TYPO3是Kasper Skaarhoj版权1998-2011。扩展程序是其各自所有者的版权。
http://typo3.com/和http://typo3.org/
的信息和贡献 - >
< meta name =generatorcontent =TYPO3 4.5 CMS/>
< link rel =stylesheettype =text / csshref =typo3temp / stylesheet_fad97d0aa7.css？1312295592media =all/>
< link rel =stylesheettype =text / csshref =fileadmin / css / styles.css？1319535102media =screentitle =Standardstyles/>
< link rel =stylesheettype =text / csshref =fileadmin / js / fancybox / jquery.fancybox-1.3.4.css？1310653643media =all/>
< link rel =stylesheettype =text / csshref =fileadmin / js / jqtransformplugin / jqtransform.css？1312810052media =all/>
< script src =fileadmin / js / jquery-1.6.2.min.js？1310979164type =text / javascript>< / script>
< script src =fileadmin / js / jqtransformplugin / jquery.jqtransform.js？1312460310type =text / javascript>< / script>
< script src =typo3temp / javascript_93553eae97.js？1312462864type =text / javascript>< / script>
< link href =fileadmin / css / print.css =stylesheetmedia =printtype =text / css/>
< script src =/ tools / formmailer.jstype =text / javascriptcharset =utf-8>< / script>< title>页面的一些标题< / title> ;
< / head>
我们发现它：Internet Explorer各种有趣从服务器返回的HTML文件包含UTF-8 BOM时的情况。我们仍然认为这是一个IE错误，但至少我们发现了一个工作。
背景信息：在初始页面生成期间，一些PHP文件包含哪些不包含在连续请求中（因为大多数生成的内容现在被缓存，并且这些文件不需要运行）。其中一些包括PHP文件包括一个UTF-8 BOM。由于BOM在开头的PHP标签之前，它被流出到PHP的输出。
我们通过比较fiddler中的输出和文件大小的不同，错误发生时为3,6或9个字节。在输出上运行差异显示BOM标题，在大多数Windows编辑器中进行比较并未显示，因为这些编辑器知道BOM。所以问题隐藏了。谢谢IE浏览器2.5天无用的工作！
We are developing a site which makes heavy use of <base href> (which is typical for TYPO3 sites). The site is developed in a sub directory and will later be relocated to the top directory so we can not easily remove <base href>.
Our client told us that sometimes when she browses the new pages she gets the page content without layout applied. We debugged this: It happens only in IE9. Looking at the logs we find that when the error happens, IE9 tries to load CSS, JS and all images consequently from the wrong location: relative to the current URL, not relative to the BASE HREF... Further inspection of the logs show us that IE8 users are also affected, including some dumb web spiders (no problem for us with the latter ones, who cares?).
We already know about IE8 speculative downloader / lookahead parser: http://blogs.msdn.com/b/ieinternals/archive/2009/07/27/bugs-in-the-ie8-lookahead-downloader.aspx
I'm sure we are NOT facing bugs described THERE: All page elements (including first header element) are loaded from the wrong location. This bug describe that only second and later elements from the page header are affected. We can prove this by watching the access logs when the problem occurs.
A simple reload fixes the issue, comparing the page source code with the bug occurring and without it occurring shows absolutely no difference. Only IE is affected, all other browsers are fine.
The <base href> tag is the first in the <head> tag. We tried every possible solution, nothing helped. Seems to be an IE bug.
Anyone else experiencing this and found a work around? We have several other sites using <base href> where we cannot reproduce such behavior in our test systems - so something is probably triggering or working around this bug. But I analyzed the logs of these sites and can see that some visitors using IE8 even there experience that bug.
As requested in the comments, here's an obfuscated example of my html head:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xml:lang="en" lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
<base href="http://client.site/cms/" />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<!--
This website is powered by TYPO3 - inspiring people to share!
TYPO3 is a free open source Content Management Framework initially created by Kasper Skaarhoj and licensed under GNU/GPL.
TYPO3 is copyright 1998-2011 of Kasper Skaarhoj. Extensions are copyright of their respective owners.
Information and contribution at http://typo3.com/ and http://typo3.org/
-->
<meta name="generator" content="TYPO3 4.5 CMS" />
<link rel="stylesheet" type="text/css" href="typo3temp/stylesheet_fad97d0aa7.css?1312295592" media="all" />
<link rel="stylesheet" type="text/css" href="fileadmin/css/styles.css?1319535102" media="screen" title="Standardstyles" />
<link rel="stylesheet" type="text/css" href="fileadmin/js/fancybox/jquery.fancybox-1.3.4.css?1310653643" media="all" />
<link rel="stylesheet" type="text/css" href="fileadmin/js/jqtransformplugin/jqtransform.css?1312810052" media="all" />
<script src="fileadmin/js/jquery-1.6.2.min.js?1310979164" type="text/javascript"></script>
<script src="fileadmin/js/jqtransformplugin/jquery.jqtransform.js?1312460310" type="text/javascript"></script>
<script src="typo3temp/javascript_93553eae97.js?1312462864" type="text/javascript"></script>
<link href="fileadmin/css/print.css" rel="stylesheet" media="print" type="text/css" />
<script src="/tools/formmailer.js" type="text/javascript" charset="utf-8"></script><title>Some title for the page</title>
</head>
We found it: Internet Explorer does all sorts of funny things when the HTML file returned from the server contains a UTF-8 BOM. We still consider this a IE bug but at least we found a work around.
Background info: During initial page generation some PHP files where included which are not included for successive requests (because most generated content is cached now and these files do not need to be run). Some of such included PHP files included a UTF-8 BOM. Because the BOM comes before the opening PHP tag, it is streamed out to the output of PHP.
We figured it out by comparing outputs in fiddler and the file sizes differed by 3, 6 or 9 bytes when the error occured. Running a diff over the outputs showed the BOM header, comparing in most Windows editors didn't show it because these editors know about a BOM. So the problem was hidden. Thank you IE for 2.5 days of useless work!
这篇关于IE9只有_sometimes_忽略< base href>的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
