https://bz.apache.org/bugzilla/show_bug.cgi?id=65513

            Bug ID: 65513
           Summary: Change in browser cache behavior introduced in 9.0.51
           Product: Tomcat 9
           Version: 9.0.52
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Catalina
          Assignee: dev@tomcat.apache.org
          Reporter: scott.t.na...@gmail.com
  Target Milestone: -----

My web application uses a transport-guarantee of CONFIDENTIAL in the web.xml
security-constraint.  When using Tomcat 9.0.43, the response headers include
"Expires: Jan 1, 1970" and user browsers will not cache any of the pages from
my application.  After upgrading to Tomcat 9.0.52, the "Expires" header is no
longer present and user browsers are suddenly caching pages.  This unexpected
change in behavior is leading to breakage in my web application.

The change in behavior appears to be related to this changelog message:
> Fix: To avoid unnecessary cache revalidation, do not add an HTTP Expires 
> header when setting adding an HTTP header of CacheControl: private. (markt) 
The commit message associated with the change seems to be focused on the
behavior of proxy caches and it's not clear that the behavior of browser caches
was taken into account.

Admittedly, my web application should be more robust in regards to explicitly
setting Cache-Control and Expires headers on pages where caching cannot be
tolerated.  However, mine is unlikely to be the only web application that is
inadvertently and unknowingly relying on the pre-9.0.51 behavior that
automagically disabled browsers from caching web application pages when
security constraints are present.

I think this breaking change should be reverted from Tomcat 9.x. The behavior
has existed for the entire lifecycle of Tomcat 9 and the change does not appear
to have been driven by a bug report (at least not one that I could find or one
that was referenced in the commit), so the adage "if it ain't broke, don't fix
it" may be applicable. The optimization is a good improvement, but is probably
more appropriate for Tomcat 10 where the the change in behavior is acceptable
as part of a major version upgrade.  If the change remains in Tomcat 9, it
should be documented in the migration guide since users may need to update
configuration and/or code to account for the change in behavior.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to