There's a page called /start on my site which seems to be getting cached for users incorrectly. I thought this was because of the issue I referenced in #509562: Cache-Control rules for Lighttpd (so Boost pages don't get cached in the browser cache), but that didn't seem to fix it after all.

Here's what's happening: When I log in to the site, I can visit the /start page and see it as I would see it when logged-in. But then when I log out, it will still show up as if I were logged in. When I view the source it will say "Page cached by Boost" - which I don't understand at all, since the page shouldn't be getting cached at all when a user is logged in.

This doesn't seem to be happening on other pages, so I've just added that page to the cache exclude list. But I wish I knew why it was happening, and I'm concerned it might be happening on other pages, so I marked this as critical.

I also noticed that the responses to valid Webform submissions (using Webform module) get cached if you use query string caching. This is not ideal, so for now I'm just excluding those pages from caching too.

Possibly relevant data:

  • I have modified the .htaccess rewrite rules to make it so Boost does not cache pages when the HTTP_REFERER is from certain sites.
  • I am using Lighty to serve the Boost .html files, as described in my previous issue.
  • I am using the Admin module to display an admin menu at the top of the page for administrative users, such as myself.
  • I have created a Rule (using Rules module) on my site to redirect users to /start when they log in. Maybe this is bypassing something that Boost needs to do in hook_init, like set the DRUPAL_UID cookie.

Anyway, thanks for all your work on this module recently. Overall, the new beta is a great improvement over the alpha I was using previously.

CommentFileSizeAuthor
#3 boost-509694.patch2.05 KBmikeytown2
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

EvanDonovan’s picture

I just bumped the version number on #253932: Logged-in-users get logged-out erratically since I think it might be related. I suspect something is going wrong with how .htaccess is checking the DRUPAL_UID cookie, but I'm not sure at the moment how to debug.

mikeytown2’s picture

Logged in users shouldn't be in the cache; and they shouldn't grab from the cache when they login/logout.

boost_init()

  // For authenticated users, set a special cookie to prevent them
  // inadvertently getting served pages from the static page cache.
  if (!empty($user->uid)) {
    boost_set_cookie($user);
  }

boost_user()

    case 'login':
      // Set a special cookie to prevent authenticated users getting served
      // pages from the static page cache.
      boost_set_cookie($user);
      break;
    case 'logout':
      boost_set_cookie($user, BOOST_TIME - 86400);
      break;

Webform submissions should be taken care of by boost_exit() since it is done via POST.

      // Add a nocache parameter to query. Such pages will never be cached
      $query_parts['query'] .= (empty($query_parts['query']) ? '' : '&') . 'nocache=1';



Looking over the code, I can see that some pages might still be cached because _boost_ob_handler() was already invoked. Adding another $GLOBALS['boost_*'] variable is probably whats needed, so one can tell boost to not cache that page via php; much like core with $GLOBALS['conf']['cache'].

mikeytown2’s picture

FileSize
2.05 KB

Please test this patch, it should fix some of the issues your having.

EvanDonovan’s picture

Ok, thanks. I haven't been experiencing this error as much in the past few days - I think there were some other things going on also. But I'll try to test your patch before the end of the workweek.

mikeytown2’s picture

Status: Active » Needs review
mikeytown2’s picture

Status: Needs review » Fixed

committed patch, please set to active if this didn't fix the problem.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.