[MAGNOLIA-2280] Incorrect handling of Last-Modified/If-Modified-Since/304 leads to incorrect caching of docroot files Created: 23/Jul/08  Updated: 23/Jan/13  Resolved: 29/Jul/08

Status: Closed
Project: Magnolia
Component/s: cache
Affects Version/s: 3.6 RC4, 3.6
Fix Version/s: 3.6.1

Type: Bug Priority: Critical
Reporter: Jan Haderka Assignee: Magnolia International
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

As reported in user list, some docroot files are sometimes not served properly.
This issue is to collect the evidence of the problem and to triage the source of it.

::edit:: see comments for explanations of this issue.



 Comments   
Comment by Fabrizio Giustina [ 23/Jul/08 ]

I can confirm this on 3.6 rc4: sometime, when the cache module is active, all the css are not serve properly (both admin and public css).
It seems to work properly for a while, than any css suddendly disappear. I still couldn't debug the cause.

Comment by Magnolia International [ 23/Jul/08 ]

Note that all 3.6Mx versions had wrong configurations, so replacing the jars would not have been enough to have a clean one, since classifiers in version numbers are completely ignored by the update mechanism.

Comment by Magnolia International [ 25/Jul/08 ]

Ok, I think we found how this is happening - it would only be the case for "docroot" files or other documents served from the filesystem, where the cms filter is bypassed and thus Tomcat's DefaultServlet serves the content.

  • Request #1 from client A (no if-modified-since header since it's its first request for this document)
    • Cache filter says "Store".
    • Css gets served by Tomcat's DefaultServlet.
    • Css gets cached correctly.
    • Client gets the css and displays it.

– here, for some reason, the cache entry expires.

  • Request #2 from client A : Has if-modified-since header.
    • Cache filter says "Store".
    • Tomcat's DefaultServlet sees the if-modified-since header, sees that the file (on the filesystem) has not been modified since then, just serves a 304
    • 304 gets cached.
    • Client has the css in his cache and displays it.

– here, for some reason, the browser's cache was emptied or this specific entry expired from it.

  • Request #3 from client A : even if no if-modified-since header, cache filter will serve the cached content. If there was no if-modified-since header in the request, it means the browser doesn't have that file in its cache, so it can't do much else than display a blank page.
Comment by Magnolia International [ 28/Jul/08 ]

So the issue is that we cache 304 responses, but not the corresponding original document's Last-Modified timestamp.

304 should not be cached: instead we'll cache the Last-Modified header value properly (i.e cache whatever value's been set by a filter or servlet further down the chain) and serve that.

Comment by Magnolia International [ 29/Jul/08 ]

fix will be available with 3.6.1

Generated at Mon Feb 12 03:35:10 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.