You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Stefan <st...@telig.de> on 2007/02/12 22:36:13 UTC
Context attribute "cachingAllowed" does not work as expected. Is
this a bug?
Hello,
to continue the development of our web application it is crucial to
avoid caching of some static resources (server side) regardless of
request headers send by clients. I did not succeed nor do I have any
idea, what to try next. I start to assume either a bug/weakness of
tomcat or a weakness in my brain.
Exhaustive searches of the web (Google and tomcat mailing archives) did
not help. Answers to my posting
http://www.nabble.com/Cache-problems-with-static-resources-tf3031321.html#a8422512
did not help either. My last posting
http://www.nabble.com/Why-does-this-not-work-with-Thunderbird-1.5.0.9--%3CContext-cacheMaxSize%3D%221%22-cacheTTL%3D%221%22-cachingAllowed%3D%22false%22%3E-tf3205171.html#a8900300
did not generate any feedback. So I start to suspect, that I have some
basic misunderstanding of things.
Please could someone help to bring me on the right track?
Prerequisite:
------------
Out of the box installation of tomcat 5.5.20 on Windows (development)
and Suse Linux 9.3 (production). A hello world index.html file. The
following context configuration:
<Context cachingAllowed="false" reloadable="true">
<!-- Default set of monitored resources -->
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<Valve className="org.apache.catalina.valves.AccessLogValve"
directory="logs" prefix="localhost_access_log."
suffix=".txt"
pattern="common" resolveHosts="false"/>
</Context>
Problem reproduction:
----------------------
Just request the index.html with Firefox 2.0.0.1 and watch the access log.
127.0.0.1 - don [12/Feb/2007:20:34:08 +0100] "GET /hospi2007/index.html
HTTP/1.1" 304 -
But the status code should be 200 and not 304. Look what IE with the
standard configuration does:
127.0.0.1 - don [12/Feb/2007:20:35:04 +0100] "GET /hospi2007/index.html
HTTP/1.0" 200 388
or Firefox with Disabled Cache
127.0.0.1 - don [12/Feb/2007:20:35:04 +0100] "GET /hospi2007/index.html
HTTP/1.0" 200 388
Question:
---------
Did I understand the tomcat documentation right?
http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
"cachingAllowed: If the value of this flag is true, the cache for static
resources will be used. If not specified, the default value of the flag
is true."
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.
Is this correct?
I really would appreciate a answer which helps me to find the right
direction. I saw you solving complicated problems in this list and this
here seems so simple...I guess I have some misunderstanding but really
can't figure out what it is. I tried for days many work arounds but I
cannot believe that I have to "pollute" our application with changing
URL-postfixes/-parameters or to bother the sever with cron jobs
"touching" files to change the modification time.
By the way. This non-caching makes problems inside a XSLT servlet filter
implementation:
...
StringResponseWrapper pageResponseWrapper = new
StringResponseWrapper((HttpServletResponse) response);
chain.doFilter(request, pageResponseWrapper);
// Do nothing if browser has cached the response
if (pageResponseWrapper.toString().length() > 0) {
// Transform the response and more. The tranformation includes some
dynamic stuff.
// Assume a current time stamp for example. It's what I just use for
testing purpose.
}
...
The getWriter method inside the response wrapper is not even called by
cached responses.
So thank you in advance
Stefan
--
Stefan
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context attribute "cachingAllowed" does not work as expected.
Is this a bug?
Posted by Stefan <st...@telig.de>.
Caldarale, Charles R schrieb:
>> From: Stefan [mailto:stefan.riegel@telig.de]
>> 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context attribute "cachingAllowed" does not work as expected. Isthis a bug?
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Stefan [mailto:stefan.riegel@telig.de]
> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org