Justin, Have a read of http://www.mnot.net/cache_docs/
If you have access to the apache config then you should be able to add a header like the ones below using mod_headers Cache-Control: max-age=60, must-revalidate to expire content after 60 seconds or use Cache-Control: no-cache to force revalidation of the content on each request. PJ On Fri, 2004-10-08 at 04:53, Justin Ruthenbeck wrote: > Wade, > > Thanks for your comments. > > By adding the <META> expires tag, it sounds like you setting the system > up to schedule the upgrade. By this, I mean that you know you're gonna > upgrade a week from today, so you configure Apache to suggest that all > content should expire at that time. Sounds reasonable. > > In our situation, we have our webapps installed offsite in clients' > facilities, so all/most of the upgrade process needs to be fool-proof... > reconfiguring Apache 1 week (or whatever) before the upgrade isn't really > an option. Aside from this, any more idea about how to handle this? > > Thanks, > justin > > > >For static web pages you can use a tag like this: > ><META HTTP-EQUIV="EXPIRES" CONTENT="TUE, 2 OCT 1998 12:42:00 GMT"> > > > >If the browsers still have a problem you might be able to configure > >Apache to output a header will all content called EXPIRES. I think you > >can if I remember right from some docs I read. You will have to look at > >Apache for that. I'm not sure about tomcat being able to handle that or > >not, but the apache bit should prepend the header I believe. The only > >other way would be to output all images and static pages from a servlet > >of some kind and add the header yourself to the request. Browsers > >should honor that tag or header for all images down the line from your > >html or jsp pages, but may not. > > > >Some browsers may be able to be set to ignore this all together > >though. Sometimes it is even worse than that. I have seen ISP's who > >think they are slick who install a cache in their systems, and they > >basically become a proxy for the users. If they are ignoring such > >things your users would have to contact them. I have seen some who do > >this for different protocols even http and https differently. That one > >irked me pretty good. > > > >Anyways, I use expires in all my jsp and html files. I haven't ever > >tried the other stuff for the headers from Apache, but think I remember > >reading about it in the Apache docs. I have output that header from > >servlets and ISAPI dlls before. > > > >Someone else may be able to offer more help. > > > >Wade > > > At 11:21 AM 10/7/2004, you wrote: > >Justin Ruthenbeck wrote: > > > >>I'm looking for some advice about how to handle the following situation. > >>(1) Apache 2.x in front of Tomcat 5.x > >>(2) Deploy new web application. Bunch of servlets, bunch of jsps, > >>bunch of static content (mainly js, css). > >>(3) Many users use the application, during which time their browsers > >>cache lots of static content > >>(4) We do a major version upgrade of the webapp, including (almost) all > >>new static content, but URLs stay the same (to alleviate > >>bookmark-maintenance requirements). > >>The problem arises when the browsers continue to use their cached > >>version of the static content. Now, the browsers eventually get > >>updated, but immediately after deployment there are huge numbers of > >>graphical and functional (js files) problems. It seems like behavior > >>in this area is widely different amongst browsers and/or their settings. > >>I have only come up with the following option: > >>(1) Play with URLs. New deployments can be deployed under > >> a different url domain like: > >> http://www.server.com/myapp/v1/main.css > >> http://www.server.com/myapp/v2/main.css > >> This would force browsers to get new content since the > >> content appears as totally new content to the browser. > >>Aside from disabling static content caching, are there any other > >>options out there? > >>Much thanks for the help! > >>justin > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
