On 6/27/2013 9:37 AM, Jan Vávra wrote: > 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.
Hi, Jan- If you're packaging the app as a WAR, it means two instead of one - and the work that goes along with generating, maintaining and distributing the extra WAR. It does add complexity. -Terence Bandoian > >> >> 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
