I think I've found a help for the Internet Explorer reload problem!
I finally dug up a network dump tool and looked at the actual communication between IE and the server. What I found was that things went roughly like this:
First request of page: 200 return code, all text, has last-modified date and cache-control which requires revalidation on every load.
HTTP/1.1 200 OK Date: Sat, 22 Mar 2003 05:40:36 GMT Server: Apache/1.3.26 (Unix) PHP/4.2.3 X-Powered-By: PHP/4.2.3 X-Accelerated-By: PHPA/1.3.3r2 -> Expires: Mon, 15 Jan 2001 00:00:00 GMT -> Cache-Control: private, must-revalidate, max-age=0 -> Last-Modified: Fri, 21 Mar 2003 16:34:52 GMT Content-language: en Keep-Alive: timeout=15, max=99 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1
Second request of page: 304 return code (not modified) -- but!
HTTP/1.1 304 Not Modified Date: Sat, 22 Mar 2003 05:40:53 GMT Server: Apache/1.3.26 (Unix) PHP/4.2.3 X-Powered-By: PHP/4.2.3 X-Accelerated-By: PHPA/1.3.3r2 -> Expires: Sat, 22 Mar 2003 08:40:53 GMT -> Cache-Control: public, max-age=10800 -> Last-Modified: Mon, 10 Feb 2003 14:03:33 GMT Keep-Alive: timeout=15, max=98 Connection: Keep-Alive Content-Type: text/html
Third request of page: didn't even bother to touch the network, because the 304 return accidentally let apache and/or php fill in generic settings for the last-modified and cache-control headers which claim it was modified when the PHP script was last updated and that it doesn't need to be revalidated for 24 hours!
I've patched OutputPage.php to include the cache-control and last-modified when sending 304s, and it's now rechecking the page on subsequent visits. (A 304 returns very quickly, so it's fast even on my modem.)
This may or may not help with the "reload doesn't actually reload" problem. Hopefully so. ;)
Next step is to add a last-touched field for pages and users to invalidate caches when links & preferences change -- see http://meta.wikipedia.org/wiki/Cache_control
-- brion vibber (brion @ pobox.com)