12 messages in org.apache.tomcat.usersRE: Cache-Control headers not being a...| From | Sent On | Attachments |
|---|---|---|
| Zampani, Michael | Aug 16, 2011 1:42 pm | |
| Christopher Schultz | Aug 16, 2011 1:57 pm | |
| Richard Frovarp | Aug 16, 2011 2:01 pm | |
| Zampani, Michael | Aug 16, 2011 2:20 pm | |
| Mark Thomas | Aug 17, 2011 12:33 am | |
| Zampani, Michael | Aug 22, 2011 2:38 pm | |
| Christopher Schultz | Aug 23, 2011 6:47 am | |
| Zampani, Michael | Aug 23, 2011 11:08 am | |
| Christopher Schultz | Aug 23, 2011 12:10 pm | |
| Mark Thomas | Aug 23, 2011 12:48 pm | |
| Zampani, Michael | Aug 23, 2011 1:39 pm | |
| Mark Thomas | Aug 23, 2011 1:43 pm |
| Subject: | RE: Cache-Control headers not being added to secure requests | |
|---|---|---|
| From: | Zampani, Michael (zamp...@amazon.com) | |
| Date: | Aug 23, 2011 11:08:54 am | |
| List: | org.apache.tomcat.users | |
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:chr...@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-----