Mark Leone wrote:
It's a silly problem. I ran in to it a while back, and it really
mystified me until I found the bug write-up. Tomcat is doing the right
thing, but MS has declared that IE is working "as designed" in this.
FWIW, the HTTP spec is clear that the no-cache behavior applies to
HTTP intermediaries, not user agents.
"the HTTP spec is clear that the no-cache behavior applies to HTTP
intermediaries, not user agents."
Are you really sure ?
I have always understood the HTTP 1.1, "Cache-Control no-cache" response
header to be able to control both intermediaries and user agent caching
activities.
The specification does not talk in terms of user agent caches and
intermediary caches it only talks in terms of caching operations (for
the large part) with a few additional directives to target shared-public
and/or private cache behaviour.
As there is no differenciation between shared-public and private caches
when it comes to the "no-cache" directive, all caches must revalidate
the request before subsequent reuse, this means an If-Modified-Since is
an allowed type of request to the server, but since most non-static
Tomcat/Perl/CGI/WhateverTechnology do not handle If-Modified-Since
request directives anyway. A new page is generated and a 200 response
given, the net effect is no observable caching effect. The important
point of "no-cache" is your HTTP client must ask the server before you
re-use your cached object, its upto the server to then say "No! Here
use this instead".
This does not help you with your IE problem thats just bad handling of
the response.
Darryl
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]