All bugs mentioned in this post are now fixed.
IE8 Bugs and their impact
Unfortunately, since shipping IE8, we've discovered two problems in the lookahead downloader code that cause Internet Explorer to make speculative requests for incorrect URLs. Generally this has no direct impact on the visitor's experience, because when the parser actually reaches a tag that requires a subdownload, if the speculative downloader has not already requested the proper resource, the main parser will at that time request download of the proper resource. If your page encounters one of these two problems, typically:
- The visitor will not notice any problems like script errors, etc
- The visitor will have a slightly slower experience when rendering the page because the speculative requests all "miss"
- Your IIS/Apache logs will note requests for non-existent or incorrect resources
If your server is configured to respond in some unusual way (e.g. logging the user out) upon request of a non-existent URL, the impact on your user-experience may be more severe.
The BASE Bug
Update: The BASE bug is now fixed.
The first problem is that the speculative downloader "loses" the <BASE> element after its first use. This means that if your page at URL A contains a tag sequence as follows:
<html><head><base href=B><script src=relC><script src=relD><script src=relE><body>
At present, there is no simple workaround for this issue. Technically, the following syntax will result in proper behavior:
<html><head><base href=B><script src=relC><base href=B><script src=relD><base href=B><script src=relE><body>
...but this is not standards-compliant and is not recommended. If the page removes its reliance upon the BASE tag, the problem will no longer occur.
Remember: The BASE bug is now fixed.
The Missing 4k Bug
Update: The 4k bug is now fixed.
The second problem is significantly more obscure, although a number of web developers have noticed it and filed a bug on Connect. Basically, the problem here is that there are a number of tags which will cause the parser and lookahead downloader to restart scanning of the page from the beginning. One such tag is the META HTTP-EQUIV Content-Type tag which contains a CHARSET directive. Since the CHARSET specified in this tag defines what encoding is used for the page, the parser must restart to ensure that is parsing the bytes of the page in the encoding intended by the author. Unfortunately, IE8 has a bug where the restart of the parser may cause incorrect behavior in the Lookahead downloader, depending on certain timing and network conditions.
As with the previous bug, end users will not typically notice this problem, but examination of the IIS logs will show the issue.
For many instances of this bug, a workaround is available-- the problem only appears to occur when the parser restarts, so by avoiding parser restarts, you can avoid the bug. By declaring the CHARSET of the page using the HTTP Content-Type header rather than specifying it within the page, you can remove one cause of parser restarts.
So, rather than putting
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
In your HEAD tag, instead, send the following HTTP response header:
Content-Type: text/html; charset=utf-8
Note that specification of the charset in the HTTP header results in improved performance in all browsers, because the browser's parsers need not restart parsing from the beginning upon encountering the character set declaration. Furthermore, using the HTTP header helps mitigate certain XSS attack vectors.
Unfortunately, however, suspension of the parser (e.g. when it encounters an XML Namespace declaration) can also result in this problem, and it's not feasible for a web developer to avoid suspension of the parser.
But, remember: The 4k bug is now fixed.
The IE team will continue our investigation into these bugs and, as with any reported issues, may choose to make available an IE8 update to resolve the issues.
Remember: All bugs mentioned in this post are now fixed.
Apologies for the inconvenience, and thanks for reading!