Pages loaded from Disk Cache, not detecting logged in

Website, Application, Performance
1

Setup: WordPress with CF

So we have some pages that for some reason loaded from disk cache. Example :

General : 
Request URL: _PAGE_1
Request Method: GET
Status Code: 200  (from disk cache)
Remote Address: XXX:443
Referrer Policy: strict-origin-when-cross-origin
---
Response :
age: 11467
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400, h3-28=":443"; ma=86400, h3-27=":443"; ma=86400
cf-apo-via: tcache
cf-cache-status: HIT
cf-edge-cache: cache,platform=wordpress

My questions are

  • What causing above page to be stored into and loaded from disk cache ? because other pages, that has same setup, is not stored into and loaded from disk cache, example
General : 
Request URL: _PAGE_2
Request Method: GET
Status Code: 200 
Remote Address: xxxxx:443
Referrer Policy: strict-origin-when-cross-origin
---
Response :
age: 12150
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400, h3-28=":443"; ma=86400, h3-27=":443"; ma=86400
cf-apo-via: tcache
cf-cache-status: HIT
cf-edge-cache: cache,platform=wordpress
  • This seem to be a reason for causing issue with login state: user logged in and then visit _PAGE_1, not showing them as logged in, because _PAGE_1 was loaded from their browser disk instead of hitting the server.
2

I don’t see a cache-control header. That might be different between the two.

3

Both doesn’t have explicit cache control header

HTTP/2 200
date: Tue, 28 Dec 2021 02:26:23 GMT
content-type: text/html; charset=UTF-8
cf-ray: 6c4757ef6fbd35c1-CGK
age: 65270
last-modified: Wed, 22 Dec 2021 05:33:42 GMT
link: <https://xxxapi/>; rel="https://api.w.org/", <https://xxx/api/wp/v2/pages/3775040>; rel="alternate"; type="application/json", <https://xxx?p=3775040>; rel=shortlink
strict-transport-security: max-age=31536000; preload
vary: Accept-Encoding
cf-cache-status: HIT
cf-apo-via: tcache
cf-edge-cache: cache,platform=wordpress
content-security-policy: default-src https: data: wss: blob: 'unsafe-eval' 'unsafe-inline'
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
server: cloudflare
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400, h3-28=":443"; ma=86400, h3-27=":443"; ma=86400

HTTP/2 200
date: Tue, 28 Dec 2021 02:26:29 GMT
content-type: text/html; charset=UTF-8
cf-ray: 6c47581939d7e483-CGK
age: 61900
last-modified: Wed, 22 Dec 2021 01:37:04 GMT
link: <https://xxx/api/>; rel="https://api.w.org/", <https://xxxx/api/wp/v2/pages/3765460>; rel="alternate"; type="application/json", <https://xxxx/?p=3765460>; rel=shortlink
strict-transport-security: max-age=31536000; preload
vary: Accept-Encoding
cf-cache-status: HIT
cf-apo-via: tcache
cf-edge-cache: cache,platform=wordpress
content-security-policy: default-src https: data: wss: blob: 'unsafe-eval' 'unsafe-inline'
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
server: cloudflare
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400, h3-28=":443"; ma=86400, h3-27=":443"; ma=86400

maybe alt-svc causing it to be cached to disk ?

4

I believe alt-svc only applies to the HTTP version that’s available.

Neither of your latest examples show as loading from disk cache.

5

the latest was using curl

here’s the output from browser i got yesterday

screenshot-newtab-2021.12.28-10_06_29
screenshot-newtab-2021.12.28-10_06_291377Ă—747 98.3 KB 

Request URL: xxx
Request Method: GET
Status Code: 200  (from disk cache) <---- 
Remote Address: xxxx:443
Referrer Policy: strict-origin-when-cross-origin
---
age: 12842
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400, h3-28=":443"; ma=86400, h3-27=":443"; ma=86400
cf-apo-via: tcache
cf-cache-status: HIT
cf-edge-cache: cache,platform=wordpress
cf-ray: 6c4257f69b7f3580-CGK
content-encoding: br
content-security-policy: default-src https: data: wss: blob: 'unsafe-eval' 'unsafe-inline'
content-type: text/html; charset=UTF-8
date: Mon, 27 Dec 2021 11:52:35 GMT
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
last-modified: Wed, 22 Dec 2021 05:33:42 GMT
link: <https://xxx>; rel="https://api.w.org/", <https://xxxxx>; rel="alternate"; type="application/json", <https://xxxx>; rel=shortlink
server: cloudflare
vary: Accept-Encoding
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block

it is inconsistent, only some pages that loaded from disk cache for some reason. and today i’m having trouble to replicate it. hence my questions still stands

  • What causing above page to be stored into and loaded from disk cache ? because other pages, that has same setup, is not stored into and loaded from disk cache
  • This seem to be a reason for causing issue with login state: user logged in and then visit _PAGE_1, not showing them as logged in, because _PAGE_1 was loaded from their browser disk instead of hitting the server. is this true ?
6

Now I’m stumped. I don’t see how the browser will know if the cached version is expired or not.

Maybe another @MVP can see something I’m missing.

7

I was able to capture another page today, that loaded from disk cache

Request URL: xxxxx
Request Method: GET
Status Code: 200  (from disk cache) <--- 
Remote Address: xxxx:443
Referrer Policy: strict-origin-when-cross-origin
----
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400, h3-28=":443"; ma=86400, h3-27=":443"; ma=86400
cache-control: max-age=3600
cf-apo-via: origin,cookie
cf-cache-status: BYPASS
cf-edge-cache: no-cache
cf-ray: 6c47b1f80b3435b6-CGK
content-security-policy: default-src https: data: wss: blob: 'unsafe-eval' 'unsafe-inline'
content-type: text/html; charset=UTF-8
date: Tue, 28 Dec 2021 03:27:52 GMT
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
expires: Tue, 28 Dec 2021 04:27:52 GMT
location: xxxxx
server: cloudflare
set-cookie: AWSALB=i/YDKEdCl+Y8wiCDok3vfmqBp38kfxvQFUo8blRjOy2LJh3Ykh7WoBXk5QKfZqxmmS1Kc5T0JTg0ZtCMiE5Ld8bfY5BLQCSJDocIOOC+KsJc14hXNHvsrdJElk+5; Expires=Tue, 04 Jan 2022 03:27:51 GMT; Path=/
set-cookie: AWSALBCORS=i/YDKEdCl+Y8wiCDok3vfmqBp38kfxvQFUo8blRjOy2LJh3Ykh7WoBXk5QKfZqxmmS1Kc5T0JTg0ZtCMiE5Ld8bfY5BLQCSJDocIOOC+KsJc14hXNHvsrdJElk+5; Expires=Tue, 04 Jan 2022 03:27:51 GMT; Path=/; SameSite=None; Secure
strict-transport-security: max-age=31536000; preload
vary: Accept-Encoding
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-redirect-by: WordPress
x-xss-protection: 1; mode=block

i can see cache-control in this one, is that the reason ?
and where it was set ? was it from CF or server ?

8

That’s one hour, so it’s not likely to be from Cloudflare, as default is 4 hours. This is set from Caching → Configuration, or a Page Rule. It can be set much lower than 4 hours, including 3600 seconds.

It’s interesting that I see AWSLB cookies in there, whereas I didn’t see those before.

9

Yeap, it could be different from previous tests. its different page, and this one triggered after login.

I still couldn’t find the persistent way to replicate it.

1 Like
10

If they visited the page before login, therefore after, they still see the cached version .html webpage.

After they hit refresh, or fire up Developer Console (F12) with feature “Disable cache”, should se the other version as “logged-in”.

If that does not happen, you might need to flush the cache frome somewhere else to get the “non-cached” version for the “logged-in” user.
I saw similar behaviour using WordPress / W3 Total Cache (Browser cache / Disk Cache) / Cloudflare (Cache Everything).

For example, I visit the homepage, open an article, go back to homepage, not being logged into WP Admin dashboard.
After that, I log into the WP Admin dashboard.
Go back to homepage and see the same cached homepage, there is no “top admin bar” shown indicating I am logged into.
I have to hit refresh or start-up Developer Console (F12) to make it appear.
Sometimes even twice.
Or there was one situation where I have had to “Purge Cache” from W3 Total Cache, so it triggered even purging Disk Cache at the server + Cloudflare Purge Everything (I saw in Audit Logs from my Cloudflare account).
Thereafter, hit F5 (refresh) and woulla, the “top admin bar” appeared.

Despite the fact, you cannot have two 100% identicaly cached versions of the webpage you are browsing, even due to Cloudflare changes the “hash” if you are using the Rocket Loader option on JS resources, etc.

  • for example, when we test WP Super Cache plugin if the disk caching is working, it just throws warning as far as it perfectly finds both of the cached versions using two test rounds, as the cached version of the “homepage” 1.html and 2.html for example, but both of them aren’t being identical due to possible usage of Proxy (Cloudflare)
x-redirect-by: WordPress

May I ask from wp-login.php to where, or something else (HTTP ↔ HTTPS, non-www ↔ www)?

Is your WordPress working over non-www or www version, also the cookies in your Web browser are being saved as for which one?

I remember, I’ve somehow even managed to get the wp-login.php page being cached and I couldn’t log into WordPress Admin dashboard.

  • which was a good way as a protection measure from bots landing directly, but …
1 Like
11

@fritex all your statement does make sense to me.
but i was just really curious why the page it self cache into browser disk ?

Status Code: 200 (from disk cache)

as you can see at samples i gave above, most of them doesn’t have cache-control header, but why browser cached it into disk ?

12

They should probably have. If the origin does not control caching, someone else might (in this case, your browser):

You may want to consider Transform Rules to add the appropriate cache-control header in case you have any difficulty implementing it at the origin.

13

Ah, those SO explains. thanks for referring it.
will try to traverse from there

1 Like
14

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.