Pragma and cache-control don’t apply to this plugin — or at least, they shouldn’t, so long as everyone is coding responsibly. And if one of your plugin or theme developers isn’t coding responsibly, you should not be using a persistent object cache.
This plugin is a replacement to WordPress’ built-in object cache, and with the exception of transients and bad code, nothing should get stored which isn’t automatically cleared when the original object changes. For instance, let’s say a WP_Post object is stored. When that post changes by way of a core function or method, the post is removed from the object cache. That’s all baked right into WordPress.
Exception #1: Transients may work a little differently. Depending on the code implementing a transient, it may have an expiration and it may not clear when the contents update. That’s up to the developer using the transient, and it would similarly be up to that developer to bypass the cache if pragma or cache-control headers request that the response not be cached. However, this plugin has no impact on that, because transients are guaranteed to persist. If you don’t use a persistent object cache, transients are stored in the database.
Exception #2: If a plugin or theme is updating objects using raw SQL, and not updating by way of core functions, then an object can persist in cache indefinitely. Pragma and cache-control headers have little relevance here, because if your application is bypassing core functions, a persistent object cache is simply not for you.
Specifically addressing your point, “Developer can’t easily refresh the cache contents,” if your developers aren’t seeing fresh content while using this plugin, and they are when not using this plugin, you should not use a persistent object cache at all in your application.
Two final points for posterity:
First, pragma and cache-control headers are mainly relevant for full-page caching, which this plugin doesn’t do. However, this plugin can be used alongside a plugin like Batcache to drive full-page caching. In that case, Batcache (or whichever plugin is implementing the full-page cache) can choose to respect those headers or not.
Second,
This might allow easier DOS of site, but I don’t think it’s that big of a problem.
Not true. Doing what you did in your fork would actually be a huge problem in terms of DOS vulnerability. When a persistent object cache is present, WordPress core’s basic non-persistent object cache doesn’t load. This means that all objects are fetched fresh, all the time. Consider this: if you call get_post( $post_id ) on the same post five times in the same request, it’s going to query mysql all 5 times (which will equate to, I think, 15 total database queries — 1 for the post, 1 for terms, and 1 for postmeta). This may not seem that significant, but that happens a lot — WordPress will probably have to do at least 100x more work to generate a page than it would out-of-the-box.
I hope this helps you out!
