Chris, Doesn't the entire securePagesWithPragma flag fail the robustness principle? It's specifically there to fix caching issues with IE, similar to the issue we're now seeing.
I understand how I would create a Filter to do this, but I'm trying to understand why this behavior was removed from Tomcat itself, while other IE specific logic remains. It seems as though the kernel of logic here is that 'pages with security-constraints' should have these headers automatically added. There should be a specific reason to add the additional isSecure() check. For example, there is a clear reason the POST check was added. http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10 But I cannot find a similar argument for checking isSecure Thanks, Michael -----Original Message----- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, August 23, 2011 6:48 AM To: Tomcat Users List Subject: Re: Cache-Control headers not being added to secure requests -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael, On 8/22/2011 5:39 PM, Zampani, Michael wrote: > However, I'm still confused about >> - {request.isSecure()} means that the headers are only added if the >> request is not secure since responses from secure requests must not >> be cached > > I don't see anything regarding secure requests in RFC2616 > http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.4 or > RFC2818 http://www.ietf.org/rfc/rfc2818.txt > > Also, since the code in question is limiting the cacheability of the > response, what is the downside of sending the no-cache header on > secure requests? http://en.wikipedia.org/wiki/Robustness_principle > I ask because we're seeing problems with IE8 caching these responses > where it previously did not when the headers were being automatically > appended. > > While it may be a client problem, it seems like the change that was > removed was made to work around a similar client problem. You should be able to fix this with a simple Filter of your own design. If you need help with such a Filter, just ask. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5Tr40ACgkQ9CaO5/Lv0PAzNgCgppYy44nkb4dJ16x6D5ouq673 SE4An2eTotSm1GQ8CQH2dOAKMReNwWcJ =Gl2e -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
