When caching for Logged-In Users is enabled, Comet Cache will do its best to ensure that the user's cache does not become outdated, i.e., that they do not get served a cache file that represents out-of-date content. The only way for Comet Cache to do this is to monitor certain events, such as when the user does something that POSTs data to your server (which occurs during events like logging in or out, posting a new comment, etc.), and clear the users cache when such an event occurs.

Any POST from a user is the user submitting something to your site in one way or another. This implies that your server is receiving this data and performing some action on the server side. Thus, it is relatively safe to assume that something is most likely changing for that user. Whether it be with their profile, with stats that you keep, or with the page they receive as output from that POST submission. It's very difficult for Comet Cache to predict what might be taking place on any given site when a POST occurs, so to play it safe (i.e., to avoid the risk of serving stale and outdated cache files), Comet Cache clears any cache files for that user whenever they do something that results in a POST.

The number of times that a user does a POST request is generally very low when compared to the number of pages they visit while logged-in. For instance, consider a social networking site (e.g., a site running BuddyPress). Lots of user-specific page views on a site like that, with very few POST requests (unless they're posting a lot of comments, or doing something else that results in content changing). When a POST does occur, the cache must be cleared, as any form submission could have an impact on output generated by a theme.

Let's use an example to see why it's important for Comet Cache to clear the user's cache whenever a POST occurs:

  1. User logs into site (this generates a POST submission, as the user's login details are POSTed to the server for validation).
  2. Upon logging in, the number of logins is determined to be 5, and the user is redirected to a page that renders content based on the total number of logins they have. This is actually a feature in the s2Member plugin for WordPress, where special offers are introduced after X number of logins. Conditionals in any content on the site, whether it be on a stand-alone page or in some other dynamic element on the site that is adjusted based on data associated with the current user. This data may or may not consider properties that change when the user logs in. I don't see any choice but to assume that the cache needs to be cleared in a scenario like this.
    • There is also the potential for some other theme/plugin to serve widget content that changes based on the number of logins. Or, on the user's current IP address that is actually recorded only during the login POST request.

A note about logging out

Keep in mind that logging out of a site is not something that every user does. For those that do, when they return to the site and log in again, the cache will be reset. However, there is a large percentage of users that will not be logging in/out all of the time. They can close their browser, leave for two days, return later, and they are still logged in, and the cache remains from 2 days prior.

Preserving the user cache on Login and Logout

While not recommended, it is possible to prevent Comet Cache from clearing the user's cache upon Login and Logout. See this article for details.