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)
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)