Guest page caching

Doubt it, since the issue is non-existent without guest page caching enabled. Good catch though, I'll straighten this out for him.
Yeah though depending on how cloudflare ssl is configured - flexible vs full ssl, then cloudflare will be talking to a different origin protocol wise. CF flexible ssl would talk to non-https site origin, while CF full ssl would talk to https site origin.
 
Yeah though depending on how cloudflare ssl is configured - flexible vs full ssl, then cloudflare will be talking to a different origin protocol wise. CF flexible ssl would talk to non-https site origin, while CF full ssl would talk to https site origin.

I'm bypassing CF using local hosts file for troubleshooting.
 
When guest cache is enabled it's not sending the right response code to bypass caches when logging out, it seems to be stemming from XF itself.
Any form of help from you guys? @Chris D @Brogan
 
When guest cache is enabled it's not sending the right response code to bypass caches when logging out, it seems to be stemming from XF itself.
Any form of help from you guys? @Chris D @Brogan
I think this has been disproved already via @MattW. When it happens, the page isn’t being served from the XF cache. I believe it was also said that it happens regardless of whether guest caching is enabled - ultimately, looks like it’s stemming from the server.
 
I think this has been disproved already via @MattW. When it happens, the page isn’t being served from the XF cache. I believe it was also said that it happens regardless of whether guest caching is enabled - ultimately, looks like it’s stemming from the server.

Not exactly. It ONLY happens when guest caching is enabled. Turn off guest caching and the issue immediately and consistently disappears.
 
Fair enough.

But unless the page includes the XF cache hit header, it isn’t coming from our cache.
 
Fair enough.

But unless the page includes the XF cache hit header, it isn’t coming from our cache.

Also fair enough.

When you click logout with the cache enabled the request to /logout returns a 303, followed by a 304 from the main page.

With pageCache disabled the logout still returns a 303 followed by the main page returning a 200.

That's the difference. Why would XF send different responses for the main page load immediately after a logout when that cache is enabled/disabled?

The problem here is the browser's cache being called up due to the 304. If XF would just return a 200 I bet all would be well here.
 
Also fair enough.

When you click logout with the cache enabled the request to /logout returns a 303, followed by a 304 from the main page.

With pageCache disabled the logout still returns a 303 followed by the main page returning a 200.

That's the difference. Why would XF send different responses for the main page load immediately after a logout when that cache is enabled/disabled?

The problem here is the browser's cache being called up due to the 304. If XF would just return a 200 I bet all would be well here.

Absolutely strange. I guess we'll never know!
 
Fair enough.

But unless the page includes the XF cache hit header, it isn’t coming from our cache.
My host really believe it's not a server level issue and that it's XF sending a response code of 304 that's causing the issue. It would be good if there is more light shed on this?
 
Again, if the XF-Cache-Status header is not present and set to a value of HIT then it isn't XF which is serving the response.
 
Again, if the XF-Cache-Status header is not present and set to a value of HIT then it isn't XF which is serving the response.

No one is saying it's the guest cache causing this problem directly, but indirectly. When the guest cache is enabled XF sends a different response code to the browser for some reason (304) which causes the browser's cache to serve the cached page from when you were still logged in.

Are you saying that XF has no bearing on serving said 304?
 
I didn't want to expand further until I had double-checked, but I can now confirm that XF never sends a 304 response code apart from when serving cached CSS or an attachment.

So if you're getting a 304 response AND there is no XF-Cache-Status header, it is 100% not XF serving it.
 
I didn't want to expand further until I had double-checked, but I can now confirm that XF never sends a 304 response code apart from when serving cached CSS or an attachment.

So if you're getting a 304 response AND there is no XF-Cache-Status header, it is 100% not XF serving it.

Interesting. I'm going to see if I can recreate this tomorrow if I get a chance on a different server with a base install. If I can hopefully it will aid in one of us getting to the bottom of this for @JoyFreak
 
I also have the same problem, when I enable the guest page caching logging out lets me still see the page as I am logged in and when I click on my username I get security error. I disabled the guest page caching sadly, I did not find a solution.
 
I also have the same problem, when I enable the guest page caching logging out lets me still see the page as I am logged in and when I click on my username I get security error. I disabled the guest page caching sadly, I did not find a solution.

Unfortunately I've been incredibly busy and didn't get a chance to recreate this in dev. environment but since others are facing it too it's looking less and less like a server issue. I know of 2 of our customers who have faced the issue, plus you makes 3.
 
Unfortunately I've been incredibly busy and didn't get a chance to recreate this in dev. environment but since others are facing it too it's looking less and less like a server issue. I know of 2 of our customers who have faced the issue, plus you makes 3.
Yeah, I was told at the time that "This appears to be unrelated to XenForo. I can receive a 304 response from your forum with no indication that PHP is even involved (this also isn't something the page cache would trigger). This indicates that there is caching happening (or caching responses) outside of XenForo, likely at the web server level. That should be disabled for XenForo. "

From the hosting they told me also it's not from the server as they dont have any server caching enabled so I just stopped using the cache for now. I thought it happened only to me at that time as there weren't other posts.
 
Unfortunately I've been incredibly busy and didn't get a chance to recreate this in dev. environment but since others are facing it too it's looking less and less like a server issue. I know of 2 of our customers who have faced the issue, plus you makes 3.
+1
Used both redis and memcached.
Currently disabled guest caching.
 
Top Bottom