Just a word of warning: your mileage might vary with SSL/APR. We deployed our app using tomcat 5.5 with the following valve implemented in the context: <Valve className="org.apache.catalina.authenticator.SSLAuthenticator" securePagesWithPragma="false" /> and found that every page was being marked no-cache. Therefore the browser kept going back to the server for every image (really annoying when using image-based menus). Not exactly sure what caused this to happen, the valve or the connector itself. We ended up deploying a filter in the app that manipulated the Cache-Control header so images and other static content got cached for a bit. (Our URL references are deployed sans protocol specification in the response sent to the browser, i.e. no mixed-mode pages). Haven't deployed Tomcat 6 yet, so I don't know if this is still required. Jeff
-----Original Message----- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Friday, August 14, 2009 9:16 AM To: Tomcat Users List Subject: Re: caching query André, On 8/13/2009 6:39 PM, André Warnier wrote: > vik111 wrote: >> Hi. I am developing a website where on the homepage there will be 50+ >> images >> displayed, hence performance of my app is imperative. I have read about >> browser caching and was wondering is there any configuration required to >> enable this in tomcat 6? Also part of my app is form authenticated and I >> would like browser caching to be enabled for this also > > Hi. It's too late for me to look it up precisely, but to save you a lot > of looking around, as far as I remember all that stuff is enabled by > default, as well in the browser as in Tomcat (at least for static > content, like your images are if they are just files on the disk, served > by Tomcat). +1 Your web browser should be pretty lazy about images, CSS files, etc. You should use a protocol sniffer like LiveHttpHeaders or IEFiddler to watch the requests being sent from your browser. Or, you could even enable the AccessLogValve and see what the server is seeing. My experience with Firefox 3.5 has been that it will only re-load images and CSS files from the server if you actually press the RELOAD button (instead of just going to the URL bar and entering the same URL again). Web browsers ought to send HEAD requests for things it thinks are static content. Or, requests sent with special headers that tell the server what "version" of the file they already have, so the server can say "oh, yeah: you've already got the latest version so I'm not going to bother to send you what I've got". > It's more work usually when you don't want caching to happen. Absolutely. Tomcat's DefaultServlet handles all this stuff for you, so if you're serving static content in the "normal" way (that is, just putting your static content in your webapp's directory (or in a subdirectory(ies) that isn't special like META-INF or WEB-INF) and allowing the DefaultServlet to serve that content) then you shouldn't have to do anything at all. > Of course the browser is an element which you do not control. The user > does. If they decide to turn caching off, or set a low limit for their > local cache space, you're doomed anyway. Yes, but then that particular user ends up with a crappy experience on your site. They kind of get what they deserve. On the other hand, they are stealing bandwidth and server cycles from other visitors. You might consider throttling requests from certain remote users when the frequency of requests for large static files increases beyond a certain threshold. - -chris ******************************* NOTICE ********************************* This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone (call us collect at 512-343-9100) and immediately delete this message and all its attachments.
