IE9 only _sometimes_ ignores <base href>

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>

回答1:

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!

回答2:

If you ever run into such a problem again, consider removing the base tag with config.baseURL > and render all links with an absolute URL:

Either use config.absRefPrefix = http://www.example.org/mysubfolder/ (most save variant) or use config.absRefPrefix = /.

回答3:

i suspect you're not using an absolute path in the tag. IE is allowed to ignore your tag since its not specified correctly. See http://www.w3schools.com/tags/tag_base.asp