You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2021/08/20 12:31:57 UTC
[Bug 65513] New: Change in browser cache behavior introduced in
9.0.51
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.nagel@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 65513] Change in browser cache behavior introduced in 9.0.51
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65513
--- Comment #1 from Mark Thomas <ma...@apache.org> ---
Background:
http://tomcat.markmail.org/thread/33sxtlnlpgcuecx6
CONFIDENTIAL only implies private caching, not no caching.
Enabling securePagesWithPragma="true" for your authenticator may be a viable
work-around until the web application is fixed.
I'm currently leaning towards closing this as WONTFIX.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 65513] Change in browser cache behavior introduced in 9.0.51
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65513
--- Comment #8 from Christopher Schultz <ch...@christopherschultz.net> ---
I finally added this to the "Notable Changes" sections of the various migration
guides in r1895119.
Sorry this took so long to get to.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 65513] Change in browser cache behavior introduced in 9.0.51
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65513
Christopher Schultz <ch...@christopherschultz.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |WONTFIX
--- Comment #4 from Christopher Schultz <ch...@christopherschultz.net> ---
(In reply to S.T. Nagel from comment #3)
> I appreciate the suggested workaround idea of setting
> securePagesWithPragma="true". I will look into it, but I do have a strict
> requirement for "Cache-Control: private", so I'm not sure the
> securePagesWithPragma branch will satisfy my needs.
I mentioned the RewriteValve above but I think it cannot set headers for you
the way that tuckey's url-rewrite can. Consider asking on the users'
mailing-list for help with forcing an Expires header on your responses.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 65513] Change in browser cache behavior introduced in 9.0.51
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65513
Michael Osipov <mi...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |michaelo@apache.org
--- Comment #5 from Michael Osipov <mi...@apache.org> ---
We have been hit by this on 8.5.70 as well. The application runs with IE 11 and
it polls for a status resource. After the first request it serves from browser
cache and never updates. Therefore, the poll repeats forever. See attached
screenshot. The application is old. I remember similar issues with JSPs which
have been cached by IE as well years ago. Our "solution" was to add
?rnd={unixtime}.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 65513] Change in browser cache behavior introduced in 9.0.51
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65513
--- Comment #3 from scott.t.nagel@gmail.com ---
I agree that this is a legitimate and appropriate change, but I wanted to
express my concerns about the impacts of making the change in Tomcat 9. You've
acknowledged my concerns and provided background and explanation for the
change, so I'm quite satisfied. I'll have no heartache with closing WONTFIX.
I do strongly believe that this change warrants an entry on the "Notable
Changes" section of the web site (what I referred to as the migration guide
based on the URL). For me personally, I read the changelog as items of
interest, but I read the notable changes as things I may need to update in my
configuration/code when upgrading.
I understand that "CONFIDENTIAL only implies private caching, not no caching",
but Tomcat 9 has always implemented it as no caching. However, I'm moving on -
I understand that the issue has been fixed and the behavior has changed.
I appreciate the suggested workaround idea of setting
securePagesWithPragma="true". I will look into it, but I do have a strict
requirement for "Cache-Control: private", so I'm not sure the
securePagesWithPragma branch will satisfy my needs.
Thank you gentlemen for your informative and thorough responses.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 65513] Change in browser cache behavior introduced in 9.0.51
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65513
--- Comment #6 from Michael Osipov <mi...@apache.org> ---
Created attachment 38007
--> https://bz.apache.org/bugzilla/attachment.cgi?id=38007&action=edit
Debugging panel from IE 11
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 65513] Change in browser cache behavior introduced in 9.0.51
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65513
--- Comment #7 from Michael Osipov <mi...@apache.org> ---
So what I do in affected servlet is:
response.setHeader("Cache-Control", "no-cache");
This really needs to go to notable changes.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 65513] Change in browser cache behavior introduced in 9.0.51
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=65513
--- Comment #2 from Christopher Schultz <ch...@christopherschultz.net> ---
So, we can't revert the change because the reasoning behind it was legitimate
and it's an appropriate change.
On the other hand, you are right, Scott, the behavior did change in a
potentially unexpected way.
Note that Tomcat is not Debian, where absolutely nothing whatsoever is expected
to change between versions other than fixing security problems.
Behavior-causing changes are not forbidden within point-releases, here.
The changelog does contain an entry announcing the change. The changelog is the
appropriate place to go when looking for changes between releases.
There is a "Notable Changes" section on the web site which in this case did not
get an entry added. I think it would be appropriate to add an item to this
list:
http://tomcat.apache.org/migration-9.html#Tomcat_9.0.x_noteable_changes
The only way to effectively "undo" this change would be to install a
RewriteValve into the default configuration which replicated pre-9.0.51
behavior. That seems a little heavy-handed and does not help anyone who uses
their own (e.g. revision-controlled) configuration.
Finally, the "Expires" header is only part of the equation. I haven't tested
this, but if you want to prevent Google Chrome from storing your pages in the
bfcache (which isn't the disk!), you will need to use "Cache-Control: no-store"
and the "Expires" header has no effect.
I tend to agree that no further code/configuration changes should be made, but
that the documentation can certainly be improved.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org