Caldarale, Charles R schrieb:
From: Stefan [mailto:[EMAIL PROTECTED] Subject: Context attribute "cachingAllowed" does not work as expected. Isthis a bug?

That means once set to false, that tomcat will not cache any static
resources like the index.html page regardless which headers the client
sends. So tomcat should not send the status code 304.

I'm not completely sure about this, but I think you're confusing server
caching with client caching.  If the client requests content with a last
modified timestamp, the server will check if the content has changed
since then and either send the updated content with a 200 or just return
the 304 and let the client use what it already has.  The cachingAllowed
attribute of <Context> only controls whether or not Tomcat's
DefaultServlet keeps a copy in Tomcat's memory of what it reads from the
file system; it does not set the response headers to indicate to the
client that the information should not be cached at the client end.  To
do that, you'll need to use your own filter.

You might want to use Ethereal or any of the browser header monitoring
tools to look at the complete set of headers being used.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Hi Chuck,

yes it makes sense what You said. But something is very strange. First of all I tried a thousands of variations to set response headers in the filter. See here, for some variations, I tried all mentioned in this thread:
http://www.nabble.com/Cache-problems-with-static-resources-tf3031321.html#a8422512

I am completely confused. My Mozilla Plugin shows the following response header for the index.html. Obvious the 200 OK is wrong. tomcat returned 304.

Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 01:00:00 GMT+01:00
Etag: W/"388-1169076375500"
Last-Modified: Wed, 17 Jan 2007 23:26:15 GMT
Content-Type: text/html
Content-Length: 388
Date: Mon, 12 Feb 2007 23:02:29 GMT
200 OK

and the corresponding request

user-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
accept-language: de,en;q=0.7,en-us;q=0.3
accept-encoding: gzip,deflate
accept-charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
keep-alive: 300
connection: keep-alive
cookie: JSESSIONID=05A42BA6580697E19E4DF8EC46288F49
if-modified-since: Thu, 01 Jan 1970 00:00:00 GMT
if-none-match: W/"1055-1171218303453"
authorization: Basic ZG9uOmVzdGViYW4=

by the way. Requesting a jsp always works but it is no option. See the index.jsp response

Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 01:00:00 GMT+01:00
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 238
Date: Mon, 12 Feb 2007 23:12:39 GMT
200 OK

I suspected the etag but setting the etag to blank (no way to delete headers, or is their a way?) does not help either.

--
Stefan


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to