@sitebastion,

Please use the latest version (V7.6.3) of the wpDiscuz plugin. Once the plugin is updated, delete all kinds of caches and check again. 

Let us know if you still see the issue. 

I am still facing this issue even after 6.3 and deleting all my caches. It's exactly as the OP said where the cookies are invalidating the caching.

Hi Asti,

I posted some fairly specific information about the cause of this issue and now another user has commented they have the same issue. Your caching security fix broke server level caching.

The site I have this running on gets between 2.5M and 3M pageviews a month and this problem renders the server unusable. Constant misses of the server cache cause all of the viewers to hit the main server - not the edge caching servers - which brings our site to a halt.

So until you can tell me that your team has verified that the problem exists and that the devs had fixed and verified the fix, WPDiscuz stays deactivated on my server.

I'm not going to do your testing for you on a site that is this busy...

Kim

@asti

NO RESPONSE IN TWO WEEKS???

What is going on here?

This is a huge problem for any server that relies on caching because your 7.6.2 update BROKE NGINX caching and you guys are just not responding. I get that this could be a complex issue to deal with as the reason you broke caching was to resolve a security bug. I understand the development process, really I do. But you have to give me something to work with here.

I've explained why I can't just turn the plugins back on and "try" and see if 7.6.3 works (and you even have another user who says they have the same issue and 7.6.3 did not help).

PLEASE - Look at the screen captures I sent, it illustrates the issue, shows you the cookie name that is causing NGINX to break. PLEASE elevate this issue to your devs and at least let me know that you're working on it.

Or let me know that you're not going to look at it and I can remove your software from my server and let our readers know that the features they know and love are gone forever.

Either way, please don't ignore the issue.

@asti

Thank you for the update.

I did try the new 7.6.4 plugin but the set-cookie was still present in the header. Hopefully this will be fixed in 7.6.5?

The relevant info on NGINX caching is here:
https://www.nginx.com/blog/nginx-caching-guide/

And specifically:

How Does NGINX Determine Whether or Not to Cache Something?

NGINX caches a response only if the origin server includes either the Expires header with a date and time in the future, or the Cache-Control header with the max-age directive set to a non‑zero value.

By default, NGINX respects other directives in the Cache-Control header: it does not cache responses when the header includes the Private, No-Cache, or No-Store directive. It also doesn’t cache responses with the Set-Cookie header. Further, it only caches responses to GET and HEAD requests. You can override these defaults as described in the answers below.

NGINX does not cache responses if proxy_buffering is set to off. It is on by default.

While there are ways to make this work, it would require modification to all NGINX servers with WPDiscuz installed - that seems unlikely as a solution.

I noted increased PHP response time and cache misses - but I also flushed ALL of my caches, server, Cloudflare and WPDiscuz. So some slowness and misses were expected.

Unfortunately, I will have to disable WPDiscuz again until the set-cookie parameter can be removed from the header or an option to turn that function off is added. Hopefully that will be coming soon.

Best,
Kim

Thanks @asti I will give it a try.

Kim