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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
