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]

Reply via email to