A Caching Issue in IE7 Beta 2

IEBlog

Internet Explorer Team Blog

A Caching Issue in IE7 Beta 2

  • Comments 77

Hello, Eric Lawrence here from the IE Networking team.  I’ve seen a few bug reports and blog comments regarding an observed change in IE7 Beta 2’s caching behavior, and I wanted to post a quick explanation about the situation and assure you that it will be resolved in the next beta.

In IE7 Beta 2, we made a change our handling of the Post-Check and Pre-Check extensions in the HTTP Cache-Control header.  If you’re not familiar with these extensions, you can get a quick overview here: http://msdn.microsoft.com/library/default.asp?url=/workshop/author/perf/perftips.asp.  

Cache Control Post-Check and Pre-Check Extensions

The Post-Check extension enables you to force background validation of a cached item after it is displayed, and the Pre-Check extension is functionally pretty similar to the Max-Age token.  Post-Check enables background caching scenarios: the cached copy of a resource is immediately displayed, but after a specified interval it is revalidated in the background (after the page has finished downloading) to ensure that the content is fresh for the next page view.

First, a bit of history: When these extensions were introduced back in IE5, there was a significant outcry because developers thought that they were required to set these new extensions to 0 to prevent IE from caching content.  This is not the case, and setting both values to 0 had absolutely no effect in IE5 or IE6.  Unfortunately, this misunderstanding spread far and wide, and it’s become common in frameworks like PHP, which sends the following header to prevent caching:

Cache-Control: no-store, no-cache, must-revalidate, Post-Check=0, Pre-Check=0

In previous versions of IE, if the Post-Check value was greater than the Pre-Check value, the values were ignored as illegal.  The IE7 Beta 2 behavior change was pretty trivial, and simply swapped the Post-Check value and the Pre-Check value if the developer had specified them backwards (we had seen this mistake “in the wild” a few times).

Unfortunately, this had a very undesirable side-effect when both values are set to 0.  Because Pre-Check was now allowed to equal Post-Check, IE7B2 respects the Post-Check=0 directive.  Hence, as soon as IE determines that it has an idle network connection, it will cause background revalidation (redownload) of the resource. 

As you can imagine, this can lead to a significant waste of bandwidth, but there’s a much more insidious problem.  The change in behavior leads to great consternation when trying to post to message boards which have “human proving images” (sometimes called CAPTCHA TM) used to prevent spam-bots. 

You know the type:

Captcha image

Every time this file is requested, it generates a random key string and stores it in the server, and renders the string to the client in the form of an image.

As you can imagine, it’s really important that these images not be cached, because if the image is cached, the server key won’t match what the user types in.  So these HTTP responses set lots of headers to do their best to make sure nothing caches the image.  For instance, here are the headers on a standard PHPBB response:

HTTP/1.1 200 OK
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Date: Wed, 05 Apr 2006 06:07:50 GMT
Content-Type: image/png
Server: Microsoft-IIS/6.0
Cache-Control: no-store, no-cache, must-revalidate, Post-Check=0, Pre-Check=0
Pragma: no-cache
X-Powered-By: PHP/4.4.1

Unfortunately, the system also totally breaks if IE decides to redownload the file in the background, because the server-side session variable will no longer match the image that’s being displayed to the user.

Some symptoms you may spot when experiencing this problem:

  1. Unable to type in the validation code for human image proofs
  2. Unexpectedly logged out of websites that use cookies for authentication
  3. Unexpected Network traffic spotted when using the Fiddler HTTP Debugger

In light of the aforementioned problems, we’ve taken a fix for IE7 Beta 3 to ignore both extensions if either is set equal to zero. 

A few additional bits of Pre-Check / Post-Check arcana:

  1. You are not required to send pre-check and post-check to prevent caching
  2. Both attribute values must be present, or they both will be ignored.
  3. Pre-Check is functionally identical to Max-Age, except max-age is calculated as a delta from the Age header, if present

I hope you enjoy using Beta 2, and thanks for all the feedback!

-Eric

  • Loading...