atom feed12 messages in org.apache.tomcat.usersRe: Cache-Control headers not being a...
FromSent OnAttachments
Zampani, MichaelAug 16, 2011 1:42 pm 
Christopher SchultzAug 16, 2011 1:57 pm 
Richard FrovarpAug 16, 2011 2:01 pm 
Zampani, MichaelAug 16, 2011 2:20 pm 
Mark ThomasAug 17, 2011 12:33 am 
Zampani, MichaelAug 22, 2011 2:38 pm 
Christopher SchultzAug 23, 2011 6:47 am 
Zampani, MichaelAug 23, 2011 11:08 am 
Christopher SchultzAug 23, 2011 12:10 pm 
Mark ThomasAug 23, 2011 12:48 pm 
Zampani, MichaelAug 23, 2011 1:39 pm 
Mark ThomasAug 23, 2011 1:43 pm 
Subject:Re: Cache-Control headers not being added to secure requests
From:Mark Thomas (mar@apache.org)
Date:Aug 23, 2011 1:43:53 pm
List:org.apache.tomcat.users

On 23/08/2011 21:40, Zampani, Michael wrote:

Wonderful!

Should I file a bug report for this? It's only a 1 line diff.

Please do. Please also include the various references in this thread so folks coming to this later have the full info.

Mark

-----Original Message----- From: Mark Thomas [mailto:mar@apache.org] Sent: Tuesday, August 23, 2011 12:49 PM To: Tomcat Users List Subject: Re: Cache-Control headers not being added to secure requests

On 23/08/2011 19:09, Zampani, Michael wrote:

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

The isSecure() check pre-dates my involvement with the project. I did some
digging and this is the reason: http://svn.apache.org/viewvc?view=revision&revision=287690 https://issues.apache.org/bugzilla/show_bug.cgi?id=6641

It looks very much like a work-around for an IE bug, almost certainly the same
one that securePagesWithPragma is intended to fix. On that basis, I'm not
against removing the request.isSecure() check.