XF 1.5 Members experiencing thread caching in some browsers (since early December).

[skicomau]

Since early December members of my forum have been reporting annoying cache issues.

Mostly with threads but also caching of notification alerts and other elements.

The reports are mostly Android (Samsung) mobile running Chrome, but also some Chrome desktop on PC.

No reports from anyone with iOS using either Safari or Chrome. No reports from Mac users.

I have only been able to recreate the issue on my desktop PC since the recent major Firefox 57 update.

My personal Chrome browser does not experience the cache issue ( v 63.0.3239.132)

In all cases a forced browser refresh will return the most recent posts on a thread.

My server setup is;

Xenforo 1.5.16
UI.X 1.5.16a.0

Nginx 1.10.3
OpenSSL 1.0.2k
PHP 5.6.3
Memecache: not installed
Opcache: enabled

Using Firefox Developer tool the only clue I can find is that a 'service worker' is returning the cached page. I presume the service worker is initiating in javascript somewhere - but I'm no front end dev.

Within the screengrabs attached, you can see that a fetch is made to server and the latest thread HTML returned (with a slightly larger file size), followed by a service worker returning the cached page of some time earlier (slightly smaller file size).

I updated \Xenforo\Session.php to include 'must-revalidate' in the Cache-control headers. This had no impact on my Firefox and it continued to cache threads, however a couple of members reported improvement with notification flags but not cached threads.

This issue has got me completely stumped and is causing much concern with a subset of my regular forum members.

Nothing was changed with my server setup prior to the reports coming through. I upgraded the site to secure in September last year, so several months prior to this issue.

Any clues appreciated.

if required, I can answer any question about my nginx, secure TLS & php setup.

 

[Mike]

Are those screenshots from when it was cached? The headers don't seem to indicate that as there are different times listed in them (one of which comes from the web server itself).

I've only done some very cursory tests, though I didn't seem to replicate the behavior. The only time we've seen unexpected caching is when caching has been set outside of XF. Notable examples include caching within Nginx (FastCGI cache) or certain reverse proxies. I'm not seeing any indication of these in the response headers though.

 

[skicomau]

Thanks for your reply Mike,

Those two screenshots are a single pageload timeline from Firefox (filtered to show only document load timeline), where the page returned was a cached version instead of the latest version (which should include the two most recent posts).

I have taken one screenshot highlighting the fetch response including headers - and what you cant see is the body response there but it is the latest version of the thread.

The other screenshot is the service worker response which is the cached version - hence the different times - the body response in that line is what the browser displayed and it's the out of date cached response.

I don't understand the mechanics of what is happening here. I'm wondering if XF uses javascript worker services (as described here) for any cache management. Though I'm completely open to it being elsewhere in the network.

What is puzzling is that it's only certain browser/platform combo's and I can't see a pattern yet, other than it's not an issue with any Apple environments.

My nginx config is part of my git repo, so I can (relatively) easily identify behaviour changes with any changes in my nginx config - however my php config is not tracked in git and that is trickier to be certain of. Either way, settings for nginx or php or secure did not change around the time the issue begun getting reported.

The only other potential is that session cookies are not being read consistently for whatever reason and the browser defaults to the last cache version. This could be related to my secure setup - I have Strict-Transport-Security in place but can not find any clues on Stack Overflow etc that this may be interfering with session cookies.

Overnight, I also tried no-cache instead of must validate with session.php but no difference today, issue remains.

 

[Mike]

XF doesn't use service workers. I expect what you're seeing is more of an internal thing in Firefox, though it wasn't something I saw in the FF dev tools when I looked so I can't be positive.

Now that I know that was a single load and that the results are 7 minutes apart (I believe), that does look questionable, though I'm at a loss as to why that would happen.

 

[skicomau]

@Mike

Fixed.

I am a bear of no brain at all - I finally found the PEBKAC.

FYI - I started playing around with a simple progressive web app late one night back in early Dec. All I wanted was a smart way to 'Save to Home Screen' for mobile homepage. PWA's are only fully supported by a subset of certain browsers - hence the random experience of members.

The service worker I uploaded to the mobile homepage included an aggressive cache mechanism that operated across the whole domain not just mobile homepage.

If I was a real developer I would have joined the dots earlier, I was looking in all the wrong places - xenforo's git is separate from ski's git and I did not scope ski's git for the early dec dates I suspected the problem was - I also assumed it was a nginx or php or opcache issue.

Your assertion that Xenforo does not run any service workers led me to do some more hunting and I found this page where I discovered about:debugging#workers in Firefox -> where I found my forgotten pwa-serviceWorker.js I had uploaded.

Learnings:

a. I'm not a very good front end dev.
b. Progressive Web Apps are complicated and dangerous - leave to the xperts.
c. Don't upload scripts late at night and forget about their very existance.


Much appologies for wasting your time.