A Caching Issue in IE7 Beta 2

Articolo
06/01/2006

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: https://msdn.microsoft.com/library/default.asp?url=/workshop/author/perf/perftips.asp.

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:

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:

Unable to type in the validation code for human image proofs
Unexpectedly logged out of websites that use cookies for authentication
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:

You are not required to send pre-check and post-check to prevent caching
Both attribute values must be present, or they both will be ignored.
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

Comments

Anonymous
June 01, 2006
This "bug" (hmm, or it was a "right-understanding-of-misuderstanded-feature"? ;) is VERY annoying and can break too many PHP-based things...

Good news!
Anonymous
June 01, 2006
> and assure you that it will be resolved in the next beta.

There's going to be another beta?

-dean
Anonymous
June 01, 2006
"There's going to be another beta?"

Yes, the existance of Beta 3 was announced (or should I say, snuck in) at the bottom of this posting:

http://blogs.msdn.com/ie/archive/2006/04/24/582546.aspx
Anonymous
June 01, 2006
Just out of curiosity... Does the behavior have anything to do with how the POST data is handled?
Anonymous
June 01, 2006
Is there a way i can set IE to only have one window and force all other IE windows to open as a tab?
Anonymous
June 01, 2006
The comment has been removed
Anonymous
June 01, 2006
I can't let this go.

With this change you are actually saying that breaking a cache sensitive page (like a CAPTCHA) is better then forcing a refresh!

This is backwards. Without this change, worst case, bad code causes the page to always be pulled from the server, and they may actually spot that there is a caching problem and look at their code.

With this change (swapping the numbers, not ignoring zeros) back code works in IE and fails in any browser that follows the spec.

This is exactly the type of thing that gives IE a bad name. Following the spec means following the spec, not just when you feel like it.

And this is from a avid MS/IE user/supporter! The slashdot/OSS guys will have a ball with this.

Jorgie
Anonymous
June 01, 2006
@Eric

Thanks for letting us know & I'm glad the team's going to fix it. *** Speaking of 'caching' ***: Why does XMLHttpRequest ignore the 'no-cache' header on get requests?

http://www.enja.org/david/?p=25
http://en.wikipedia.org/wiki/XMLHTTP
Anonymous
June 01, 2006
Jorgie, which spec is Post-Check/Pre-Check a part of? It sounds like MS created them so MS can fully choose how to implement them.
Anonymous
June 01, 2006
The comment has been removed
Anonymous
June 01, 2006
The comment has been removed
Anonymous
June 01, 2006
Erik: According the the HTTP/1.1 spec, the only official value in the Pragma header is no-cache. Any other values are extensions, and are vendor-specific.

This means that the Post-Check and Pre-Check values are Microsoft-specific, and Microsoft can change how they work as they please.

It also means that if the values are not present, it should not affect caching in a negative way.
Anonymous
June 01, 2006
I'm not quite sure if they've fixed a problem or just changed a problem.
Anonymous
June 01, 2006
The comment has been removed
Anonymous
June 01, 2006
@Fiery: "Does the behavior have anything to do with how the POST data is handled?"

Nope, this solely has to do with the value of the header.

@Developer: Why would you expect the cursor to change? Other navigations don't change the cursor?

What do you consider a "reasonable" length for the dropdown list flyout? It appears to max out at 30.

Changing the behavior of the Button element is likely to cause compatibility problems.

@cooperpx: I'll look into this.
Anonymous
June 01, 2006
@Norbert: Use Tools | Internet Options | General | Tab Settings to control how windows are opened. We've fixed some bugs here over the last few weeks.
Anonymous
June 01, 2006
please in German, i can not English
Anonymous
June 01, 2006
The comment has been removed
Anonymous
June 01, 2006
The authors of IE suspect that there will be no more versions beyond 7.0, and thus notation "IE 7+" will not cause confusion.
Anonymous
June 01, 2006
The comment has been removed
Anonymous
June 01, 2006
"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)."

don't
Anonymous
June 01, 2006
I can't login to hotmail.com after I installed IE7 Beta 2. I tried to uninstall it, then login but that didn't work. I have reinstalled IE7b2.
And now it wont even work in firefox. Got any clues to what could be wrong?
Anonymous
June 02, 2006
@Mike Clevland

-->> "IE7 is perfect" <<--
Uh, yeah, ooooooookaaaay......

Let me ask you this:
Uhm, is it dark in there?

No offence dude, but if you take IE7 as the top of the heap, you obviously haven't done your homework. This Blog is here for just that reason.
Anonymous
June 02, 2006
Ok, can someone please look at the hosting for this blog?... at least 5 times in the past 24 hours, it has gone DOA when clicking a link. Which then punts you to the Community Server Blogging forum to report the error. Which is A)) Wrong, and B)) Of no help and C)) Just plain anoying, because the user has to login to submit a bug.

Can we get a link on this page (and no, not the email at the top that doesn't get looked at), that submits a Forum bug report via another (e.g. non-Community Server) page?

Thanks
Anonymous
June 02, 2006
Well I must say I'm delighted to have read that blog post, and I think it's been one of the most useful on here yet.

I started experiencing problems like that with IE7B2 almost immediately, both with logging out and my CAPTCHAs suddenly not working.

I figured it must have been a bug since all worked fine in IE6/FF so yeh it's interesting to see exactly what was causing it.

Many thanks guys for your continued hard work, I can't wait for the final IE7 :)

(Also looking forward to the CPP of Vista as I can't afford an MSDN subscription;))
Anonymous
June 02, 2006
> Changing the behavior of the Button element is likely to cause compatibility problems.

Not changing it means sticking to a bogus behaviour, practically making <button> useless.
And changing it won't be easier with IE 8 or 9. So you're actually saying it'll never get fixed, right?

Please change this policy. You are still holding back the web.
Anonymous
June 02, 2006
>> You are still holding back the web.
Somehow I doubt that you and your requirements for the "button element" consist of the entire web.

The development team can only do so much, and with the added weight of "any change could break a thousand different things", it might be nice to once in a while just say 'good job so far' instead of grumbling about something else.
Anonymous
June 02, 2006
> Somehow I doubt that you and your requirements for the "button element" consist of the entire web.

The requirement of cross-browser behaviours is out of question. This behaviours are defined by the W3C (where MS participates), not by me.

It was meant exemplary. Some hours ago I read on the IE Feedback site that <label> is not working correcly "by design" because of "compatibility" concerns. That's just another example -- I'm not saying that one particular bug holds back the entire web, but altogether this policy does.
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
Can you tell me how to unintall IE7. I WORK FOR THE STATE OF TEXAS AND IT DOES NOT RECONIZE STATE WEBSITES. IT WILL NOT LET ME UNINSTALL IT. I KEEP GETTING THE MESSAGE I HAVE TO LOGIN WITH THE USER NAME I INSTALLED IT WITH. I ONLY HAVE 2 USER NAMES AND IT WILL NOT ALLOW ME TO LOG ON AT SLANDERSON OR ADMINISTRATOR. I WANT IE7 OFF THIS PC!!
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
Henry, I'm glad you agree to me. But it's not just about fixing code. Let's not forget that IE6 will be around for some time, e.g. because IE7 won't be available for all relevant Windows systems. So the argument makes sense, kind of: If developers start using <button>, their websites won't work for IE6 users.
BUT: Shifting the fix means only shifting the problem. Instead it could be fixed now, informing the developers about the potential problems. So at least when IE6 has become obsolete someday, we could start using <button> & friends, knowing it'll work with the "good old" IE7.
Anonymous
June 02, 2006
Not sure if I should post this here or at an Office 2007 blog.....but, Is there a way for the RSS readers in Outlook and IE7 to sync up, so that when I read a feed on one the feed also shows up as read in the other. Right now if I read a feed in Outlook, IE7 still has it as unread (or if I read it in IE7 then Outllook still leaves it as Unread until I read it there). Just wanted to know if that was possible for them to sync up.

Thanks
Anonymous
June 02, 2006
Hopefully someone can confirm this, any time I go to http://www.codeproject.com/cs/miscctrl/ and scroll down, IE7 begins using between 400 and 500MB of RAM!
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
That sounds like a nice bug to fix still.
Anonymous
June 02, 2006
The comment has been removed
Anonymous
June 02, 2006
@codemastr: Do you have the Phishing Filter enabled (Tools | Internet Options | Advanced)? There were some bugs on memory use @ codeproject. If not, this might be one of the scrolling bugs we're looking at.

@Xepol: Any plugins installed?

The Windows Firewall typically drops inbound UDP packets.
Anonymous
June 03, 2006
Opened that page on a tab on both IE and Firefox... and on firefox mem usage went up 3MB and on IE went almost up 200MB but went down to 5MB a little afterwards
Anonymous
June 03, 2006
Eric: No, the phishing filter is turned off. Also, even before I scroll at all, IE jumps in PF usage by about 200MB. Scrolling definitely increases the usage, but it doesn't seem to be the root cause.
Anonymous
June 03, 2006
I really need this fixed, I have developed a captcha system for this forum software which works perfectly in IE6, Firefox, Opera and Netscape. IE7 will not display the image, is there any work around for this?
Anonymous
June 03, 2006
Guys, the only way to find an error is if something breaks--accepting buggy code will only increase the amount of buggy code.

I don't depend on buttons to do anything more than submit forms or call JavaScript functions, but it seems reasonable to expect that things should work the same way between browsers. At the very least, make it work correctly in strict mode. That's what it's there for.
Anonymous
June 03, 2006
@EricLaw - as stated in a previous message, the listening UDP port appears even when I start IE in the "no addons" mode. The only thing that might distinguish my system from an every day system is that I have Visual Studio 2005 installed. I considered the possibility that the port is involved in debugged, but I would have expected that to be by way of a plugin which would be disabled with "no addons" mode.

Again, I am using SysInternal's Process Explorer to view tcp/ip connections.
Anonymous
June 04, 2006
Please, as a web developer I can forgive caching not always being perfect because I can design my pages to be light and fast.

I implore you - fix the many serious HTML+CSS rendering bugs. Seventy (70) bugs are listed on this page:

http://www.quirksmode.org/bugreports/archives/explorer_7_beta_2/index.html
Anonymous
June 04, 2006
The comment has been removed
Anonymous
June 04, 2006
@ Xepol

All UDP ports are "waiting for incoming unsolicited datagrams". PERIOD. In this case its only for local machine IPC.

@ Eric

I have replicated his report and this udp port is bound to 127.0.0.1, occurs by default (never mind no add-on mode), but I cannot tell if it has a proper ACL. This looks a-okay in my book.
Anonymous
June 04, 2006
The comment has been removed
Anonymous
June 04, 2006
The comment has been removed
Anonymous
June 04, 2006
The comment has been removed
Anonymous
June 04, 2006
The comment has been removed
Anonymous
June 04, 2006
"Tell others that they have misunderstood, and they will quickly fix they bug in their code when thinks start breaking."

If only the real world worked like this...
Anonymous
June 05, 2006
@Rex
I sense a growing form of frustration. However, if you're going to vent, it would be nice to have proper grammar and spelling.

@IETeam
For once I actually agree with the community: don't destroy a standard to make something work. In the long run, it would probably behoove you to upgrade to the standard instead of down-playing for the broken sites.
The zoom has worked fine for me, though it could use a bit of improvement when it comes to centered content not centering.
Otherwise, keep up the good work!
Anonymous
June 05, 2006
Charis... where did you hear August from? I don't think a date for beta 3 has been set yet...
Anonymous
June 06, 2006
Does this in any way affect how data from POST is going to be processed?
Anonymous
June 06, 2006
> This "bug" (hmm, or it was a "right-understanding-of-misuderstanded-feature"? ;) is VERY annoying and can break too many PHP-based things...

Actually, PHP doesn't do this at all (the poster is incorrect.) Rather, phpBB is sending these headers - which is somewhat popular practice.

If you have PHP code, you shouldn't have to worry about it; most other PHP scripts don't send these headers. They would have to be explicitly set by the developer.

Thanks,
-[Unknown]
Anonymous
June 06, 2006
@HTMLHelper: No, IE7 sends POST data in the same way that IE6 does. We don't plan any changes here.

@UnknownW.Brackets: Nearly every PHP-based site I've encountered sends these headers.

Grep'ing the PHPBB code for "-check" and removing all instances of this still doesn't prevent these headers from being sent, leading to my assertion that this must be a part of the base framework.
Anonymous
June 06, 2006
@Eric: "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)."

This kind of "fix" is counterproductive and will lead to even more confusion. Please inform the Web masters of these sites instead of making guesses about their malformed HTTP headers.
Anonymous
June 07, 2006
"This kind of "fix" is counterproductive and will lead to even more confusion. Please inform the Web masters of these sites instead of making guesses about their malformed HTTP headers. "

YEA, What he said!

jorgie
Anonymous
June 07, 2006
Ok, this will be a bit picky, but can you not post screenshots as jpegs? That image is atrocious! even gif would be better.

Heck, why not show off your new PNG capabilities.

There is a standard rule with images... if your image contains text (e.g. screenshots), DO NOT use JPEG. It will look like crud.

SG
Anonymous
June 07, 2006
Silly gripe -- the image looks to be the same as is posted on MSDN, so my guess is that the file format was dictated by the MSDN folks back when the article was published.
Anonymous
June 07, 2006
Yup, sorry about the image; this is the image we had handy from the old documentation. We've got plenty of other things keeping us busy. :-)
Anonymous
June 12, 2006
The comment has been removed
Anonymous
June 12, 2006
Soon might be the updated version would be released with changes updated hopefully with the bugs rectified,
Anonymous
May 11, 2007
PingBack from http://www.zhangling.org/blog/20070511/lotus-connections-blog-feed-cache.html
Anonymous
January 04, 2008
PingBack from http://actors.247blogging.info/?p=4545
Anonymous
January 05, 2008
PingBack from http://boxing.247blogging.info/?p=3351
Anonymous
January 21, 2009
PingBack from http://www.keyongtech.com/1252670-file-security-warning-for-php
Anonymous
May 31, 2009
PingBack from http://hammockstandsite.info/story.php?id=892
Anonymous
June 07, 2009
PingBack from http://greenteafatburner.info/story.php?id=190
Anonymous
June 08, 2009
PingBack from http://jointpainreliefs.info/story.php?id=313
Anonymous
June 09, 2009
PingBack from http://cellulitecreamsite.info/story.php?id=4997

Condividi tramite

A Caching Issue in IE7 Beta 2

Comments

Risorse aggiuntive