DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8773>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8773 Enable browser caching of authenticated pages Summary: Enable browser caching of authenticated pages Product: Tomcat 4 Version: 4.0.3 Final Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I would like the ability to be able to enable browser caching of pages that are authenticated (for instance with BASIC authentication). At present, AuthenticatorBase prevents this from occurring. Why do I want this? 1. I like being able to use container based "security" (realms and security-constraints) as it makes development simpler. 2. The content of my site does not need to be truly secure, just passworded. This is a conscious decision I have made. Why I can't do this (without hacking the source)? org.apache.catalina.authenticator.AuthenticatorBase prevents this by adding headers (Pragma: No-cache, Cache-Control: no-cache, Expires: 1 (1970ish)) to the HttpResponse, disabling my ability to set expiry times and return 304 statuses (and stops the browser from caching effectively). This adds significantly to the overhead for my site (which is an electronic photoalbum where the photos are served via servlets) - most users are on modems and the imposition of 15 x 5k thumbnails is excessive and unnecessary on every page view. I've removed these lines from my TomCat, but this does not represent a viable long-term solution. I didn't even realise that caching was disabled until I went searching through to determine why expiry wasn't working. I'm sure there are others out there in this situation. Enhancement? I'm not sure. I think this behaviour should be optional (and probably on the SecurityConstraint), but I couldn't see anywhere appropriate within security-constraint dtd to put this kind of option. I believe it should also be configurable at a per servlet level, although the added security that this gives is minimal. In the meantime, I'll just have to "fix" AuthenticatorBase. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
