Hi.
Note that Cache-Control:private does not disable caching. Instead, it
disables public-caching for proxies. The browser is still free to
cache the document in certain ways.
True disabling of the cache would be to set Cache-Control to
"no-cache" or "no-store" (though no-store is usually more appropriate
for controlling proxies and not browsers).
Ok. I thought it controls browser caching.
If I add disableProxyCaching="false" to <Valve
className="org.apache.catalina.authenticator.FormAuthenticator"
characterEncoding="utf-8"/> at my context.xml the response headers
change to:
HTTP/1.1 304 Not Modified Server: Apache-Coyote/1.1 ETag:
W/"3907-1372233712661" Date: Wed, 26 Jun 2013 11:25:23 GMT and
browser in the next request doesn't asks for this image.
Is it safe to override default bahaviour via disableProxyCaching?
Or I am something missing? Or there is a best practice to place
images, css styles into another application?
What happens with dynamic resources?
The reason that cache-disabling is on by default is that having
proxies and/or browsers caching resources that were protected by
authentication is a potential security or privacy problem. From the
documentation for "disableProxyCaching":
"
Controls the caching of pages that are protected by security
constraints. Setting this to false may help work around caching issues
in some browsers but will also cause secured pages to be cached by
proxies which will almost certainly be a security issue.
securePagesWithPragma offers an alternative, secure, workaround for
browser caching issues. If not set, the default value of true will be
used.
"
Tomcat can't tell which resources are "okay" to allow the browser to
cache and which aren't.
Why we cannot tell tomcat what resources are okay?
I was playing with Expiration Filter for /common/* but with no effect.
IMO, you might want to think about using a
fronting web server to serve your static content (which will not
include any headers that would otherwise be sent by Tomcat) and map
all dynamic requests to Tomcat. There are certainly other ways to get
this done as well, but you may find that configuring your way around
this "problem" is more difficult than you imagined.
One way that I have in mind is to make second tomcat application
/myapp-static that contains static images etc. And link all images to
this context. But this is ugly.
Is there actually a /problem/ with having Cache-Control:private set on
your resources? Have you tried playing with the
"securePagesWithPragma" setting?
The problem is only the effectivity of network traffic. For one page
load the browser asks for each image, ccs all the time ( after click,
not Ctrl+R for refresh).
Why Tomcat is also responding header Expires: Thu, 01 Jan 1970 00:00:00
UTC ?
I think all this behaviour is somehow connected to form based auth. I
must prove it by more tests.
=========== My aps has these part /* - common
authenticated content /user/* - content for user /admin/* - content
for admin /common/* - common unauthenticated static content like
images, css, etc
My web.xml
<security-constraint> <web-resource-collection>
<web-resource-name>MyApp</web-resource-name>
<url-pattern>/*</url-pattern> </web-resource-collection>
<auth-constraint> <role-name>myapp-admin-role</role-name>
<role-name>myapp-user-role</role-name> </auth-constraint>
</security-constraint>
Technically, the above web-resource-collection is protected, which
includes everything on your site.
Instead of blanketing the whole site with what amounts to a black-list
and then white-listing other resources, why not do the reverse and
only use a white-list? That will avoid "protecting" resources that
need not be protected.
<security-constraint> <web-resource-collection>
<web-resource-name>MyApp</web-resource-name>
<url-pattern>/admin/*</url-pattern> </web-resource-collection>
<auth-constraint> <role-name>myapp-admin-role</role-name>
</auth-constraint> </security-constraint>
<security-constraint> <web-resource-collection>
<web-resource-name>MyApp</web-resource-name>
<url-pattern>/user/*</url-pattern>
Umm... you have the same url-pattern (/*) in two separate
web-resource-collections. Is that intentional?
I have /* allowed for admin and user roles. There are only login,
logout, j_sercurity_check pages. And after succ. login user is
redirected to his context (/user or /admin).
/admin/* is only for admin and /user/* only for user role.
And also I do not want to allow for admin accessing the /user/* pages
and vice versa.
I do not have /* twice or I don't fully understand you.
Jan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
