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

Reply via email to