On 12/2/2012 4:54 AM, Konstantin Kolinko wrote: > 2012/11/30 Terence M. Bandoian <tere...@tmbsw.com>: >> Hi, Chuck- >> >> I don't mean to be argumentative but, with Tomcat 6.0.29, I found that >> static files from an images subdirectory of a web application were not >> cached by Internet Explorer 7. As a workaround, I created a context for the >> images subdirectory and left it nested in the web application. The files >> from that directory were then cached by IE7. The difference was that the >> following response headers were included when there was no separate context >> defined for the subdirectory: >> >> Pragma: No-cache >> Cache-Control: no-cache >> Expires: Wed, 31 Dec 1969 18:00:00 CST >> >> Something else I found unusual was that ETag and Last-Modified headers were >> provided in both configurations. Apparently, some browsers (e.g. Firefox) >> utilize that information even when the no-cache and Expires headers are >> provided. >> >> I realize this is a non-standard configuration but it worked with 6.0.29 and >> 6.0.35. >> > > The "no-cache" headers are added to resources that are protected by a > security constraint. That is for an obvious reason: if a resource is > cached locally, you cannot protect it. > > It is usually a good idea to do not protect such static files. > > > Regarding "a.war/foo/bar" vs "a#foo.war/bar", Tomcat always selects a > webapp first - one that matches the longest path. Then it selects a > resource in the selected webapp. > > It is mentioned in the Introduction section of the > "config/context.html" page of the Configuration Reference Guide. > > One example of using this rule is ROOT/admin/index.html page in Tomcat 5.5. > > When a user requests "http://localhost:8080/admin/" and the admin > webapp is not installed, the ROOT/admin/index.html page is called and > says that "no such application is here". If the admin webapp is > installed, then its welcome page (admin/index.jsp) is displayed. > > Best regards, > Konstantin Kolinko
Hi, Konstantin- That makes sense. A security constraint was indeed defined for the main application using the URL pattern "/*". However, no security constraints were defined for the subdirectory contexts and so the "no-cache" headers were eliminated. Thank you for the explanation. -Terence Bandoian --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org