DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=34560>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED ANDĀ· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=34560 ------- Additional Comments From [EMAIL PROTECTED] 2006-09-24 13:33 ------- (In reply to comment #11) > The servlet spec does not specify caching behaviour for CONFIDENTIAL. Because https transport has nothing to do with caching... You are mixing attributes of layer 6 (presentation/encryption) and layer 7 (application/http) of the OSI protocol stack (higher layers being merely the payload of the lower layers, i.e. the russian dolls metaphor). http://www.webopedia.com/quick_ref/OSI_Layers.asp If you want to discuss caching (and authentication), you must locate yourself at the layer 7. Therefore the transport choice is irrelevant and the http spec prevails: caching headers aren't mandatory and so are added as an explicit choice by the servers/proxies. As it stands, tomcat disregards that choice and requires extra configuration to remove http headers. > Given the meaning of confidential it is arguable that it should > not be cached it in order to keep it private. This is a browser-side privacy issue, a user preference, not a server issue. You can assert the concepts exposed here with anyone with a bachelor degree in computer science (or electrical engineering with networking speciality). Maybe http and servlets don't sound very OSI, but they do partition communication roles. I don't know what else I can give you to help you understand how CONFIDENTIAL transport is not related to caching. But in the end, the fact that both use-case are legitimate enforces the fact that caching of unauthenticated confidential resources must be configurable. My point is to provide the performant alternative, not the slower one and force users to cope with extraneous hits, server load and exra servlet filters and config. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]