[MAGNOLIA-2478] SetExpirationHeaders fails to disable browser caching for Firefox 3 Created: 19/Nov/08  Updated: 23/Jan/13  Resolved: 22/Jan/09

Status: Closed
Project: Magnolia
Component/s: cache
Affects Version/s: 3.6.4
Fix Version/s: 4.0, 3.6.4, 3.6.5

Type: Bug Priority: Minor
Reporter: Philippe Marschall Assignee: Magnolia International
Resolution: Fixed Votes: 0
Labels: browser, cache
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File CACHING under Magnolia 3.6.3.pdf     Text File CacheHeadersFilter.patch     Text File SetExpirationHeaders.patch    
Issue Links:
relation
is related to MAGNOLIA-2675 "Pragma: no-cache" header's case is w... Closed
Template:
Patch included:
Yes
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
Testcase included:
Yes
Date of First Response:

 Description   

If we use the BrowserCachePolicy Never Firefox 3 still caches the page for a short amount of time. If we add "no-store" value for the Cache-Control header Firefox does no longer cache the page.

Our code looks like this:

  public void processCacheRequest(HttpServletRequest request,
      HttpServletResponse response,
      FilterChain chain,
      Cache cache,
      CachePolicyResult cachePolicyResult) throws IOException, ServletException {

    BrowserCachePolicy browserCachePolicy = this.getCacheConfiguration().getBrowserCachePolicy();
    BrowserCachePolicyResult clientCacheResult = browserCachePolicy.canCacheOnClient(cachePolicyResult);

    if (clientCacheResult.getExpirationDate() < 0) {
      response.setHeader("Pragma", "no-cache");
      response.setHeader("Cache-Control", "no-cache, no-store");
      response.setDateHeader("Expires", 0L);
    } else {
      final long maxAgeSeconds = (clientCacheResult.getExpirationDate() - System.currentTimeMillis()) / 1000;
      response.setHeader("Pragma", "");
      response.setHeader("Cache-Control", "max-age=" + maxAgeSeconds + ", public");
      response.setDateHeader("Expires", clientCacheResult.getExpirationDate());
    }

  }

We haven't yet tested with other browsers.

There are some other issues we have with SetExpirationHeaders:

  • it tests for BrowserCachePolicyResult identity instead of using the return value of #getExpirationDate
  • it sets the Expires header twice, to two different values

I'll attach a patch later this day.



 Comments   
Comment by Philippe Marschall [ 19/Nov/08 ]

patch attached

Comment by Philippe Marschall [ 19/Nov/08 ]

patch and test added

Comment by Philippe Marschall [ 19/Nov/08 ]

There is a similar issue in CacheHeadersFilter. Patch and fix attached.

Comment by Magnolia International [ 19/Nov/08 ]

thanks, will apply asap !

Comment by Magnolia International [ 21/Nov/08 ]

Patch applied to both trunk and 3.6 branch except for the if () statement in SetExpirationHeaders - any specific reason for not using the constant ?

Comment by Magnolia International [ 22/Jan/09 ]

Philippe, if there was any concern about using the NO_CACHE constant, please re-open, but as far as I know, as far as custom BrowserCachePolicy implementations also use it, it should be fine.

Comment by Matteo Pelucco [ 01/Apr/09 ]

If we use the BrowserCachePolicy Never Firefox 3 still caches the page for a short amount of time. If we add "no-store" value for the Cache-Control header Firefox does no longer cache the page.

The same happens on IE6 / IE7. Only a CTRL + F5 (Cache-Control: no-cache on HTTP Request Headers) forces server to send fresh page.

I'll attach a little docs about it.

Comment by Matteo Pelucco [ 01/Apr/09 ]

Different HTTP Header (Req vs. Resp) regarding Cache-Control

Comment by Magnolia International [ 02/Apr/09 ]

Pragma: no-cache capitalization fixed by MAGNOLIA-2675.

Comment by Matteo Pelucco [ 02/Apr/09 ]

Just to better explain my pdf.
On our project, we started to serve pages on public instances with server cache disabled. Yes, we know the issues on that, but there have been so much trouble here and initially our templates behaved in a strange ways with cache enabled.

Anyway, few days ago we have reintroduced server-side caching, with excellent results (from 2 / 2.5 seconds per page --> to 100 ms), flush on every minute (tested and working). Here all internal editors uses IE6.

From that moment a lot of internal editors (we have more than 70) started to say: "Hey, why homepage is not up-to-date?" Only using CTRL + F5 (or emptying browser cache + restart of browser) solved that issue.
I started to work around HTTP Headers and I've found that with cache disabled no caching info are sent to the browser and that forces IE6 to reload the fresh content.
With browser cache enabled, right HTTP Headers are sent BUT IE6 caches all with normal F5 or Refresh button, even after several days.

I've reproduced locally the issue and implemented another version of setExpirationHeaders, taken from Magnolia 3.6.5, with these changes:

        if (clientCacheResult == BrowserCachePolicyResult.NO_CACHE) {
//            response.setHeader("Pragma", "no-cache");
//        	response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate, max-age=0");
//            response.setDateHeader("Expires", 0L);
            System.out.println("NO_CACHE, no headers sent");
        } else {
            final long maxAgeSeconds = (clientCacheResult.getExpirationDate() - System.currentTimeMillis()) / 1000L;
            response.setHeader("Pragma", "");
            response.setHeader("Cache-Control", "max-age=" + maxAgeSeconds + ", public");
            response.setDateHeader("Expires", clientCacheResult.getExpirationDate());
            System.out.println("cached");
        }

and doing that I managed to have IE6 working well, with server-side caching enabled.

But as you may know, in this project there are a lot of problems... so I've not found until now enough time to test this behaviour in dept.
That's it!

Comment by Philippe Marschall [ 02/Apr/09 ]

Matteo are you sure you don't suffer from MAGNOLIA-2448?

Comment by Matteo Pelucco [ 02/Apr/09 ]

I can not exclude, Philippe, thanks!
I'll have a check on a parallel 3.6.5 to see what happen..

Comment by Matteo Pelucco [ 02/Apr/09 ]

Done some tests, it seems to go better on 3.6.5.
The system behaves as expected with cache refresh: the If-modified-since header is not present anymore (still rpesent on 3.6.3), IE6 refresh everytime the content. As I said, everytime, even when expiration policy is set to be 30 minutes.

Strange..

But tomorrow I will investigate better and let you know.

Comment by Magnolia International [ 03/Apr/09 ]

Thanks for the details, Matteo. Looking forward for your further investigation details

Comment by Magnolia International [ 24/Apr/09 ]

Any news to share, Matteo ?

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