I'm using boost successfully on a high traffic website, with just one minor glitch. As I understand it, Boost applies to anonymous users only, and should have no effect on logged in users? I find that even when logged in, it still serves up the cached version of the front page, rather than the current one.

The problem is that the frontpage appears to show that I am not logged in, when in fact I am. When I browse to any other part of the site, it does revert to the correct behaviour- so this problem effects only the front page.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

chrism2671’s picture

I should point out that boost has given us at least 3x the traffic capacity on the same server, and rising- what a great plugin!

drupdrips’s picture

I second your enthusiasm about using boost .. it is so good for that initial first impression for a new visitor and also so important for the home/front page to show up under 2 secs. Not to mention of the additional load it helps to shave off from php processing except for those logged in users / and query string pages.

However I have found this module needs some careful consideration of your user's anticipated behaviors and you have to test for each of those cases and tweak in some places to get desired results.

For the problem you mention, I want you to try the following and let me know the results.

If you go to the page where you normally login, do this :

1) use firefox
2) go to the login page (without actually logging in yet), and pull up the cookie information from FF browser menu Tools->options->Privacy-> Show cookies.
3) Do you see a cookie from your domain.com ?

If the answer to 3 is no, then I know what it is. otherwise I'd say check your htaccess rules and make sure you are following the installation document for this. I am using lighttpd for my webserver so I am not using htaccess rules, but it should work if you have set it up as mentioned in the document.

chrism2671’s picture

There are cookies there. However, attempting to log out does not actually seem to allow me to logout (and redisplay the login screen) on the front page- rather, it displays the 'logged in' page, and on other pages is displays the 'logged out' page. navigating back to the front page still displays the 'logged in' page, and you have to click Log out at least one more time to achieve the desired effect.

Very strange!

drupdrips’s picture

A few more quick things to check :

(1) Check that you are not generating a logout.html in your cache/domain.com/0/ folder.
If you are, and I was too, - go to domain.com/admin/settings/performance/boost and put "logout" without any quotes as one of the pages not to cache.

(2) check that you are setting appropriate Response Headers in the browser
with - no-store, no-cache, must-revalidate, post-check=0, pre-check=0. Verify from firebug.

(3) Also in the above post when I asked you to try and see if you have a cookie to begin with, make sure you CLEAR your browser cache, before you land on your first page with the login block (if this page was generated as a cache page earlier). The reason: Your true anonymous visitor visiting first time will not have a cookie from this domain to begin with when he lands on your cached front page or another cached page that has the login block. (If the logon block was generated as a page after going to "/user" path then you get a cookie since /user path follows php invocation and will not serve a cached page, but otherwise when the login block is part of a cached page and this is the first page that the visitor comes to try and login, make sure to clear your prior cookies for true test results). The first login in this case is bound to fail - as a result of a drupal core behavior that should not be overridden such as by hacking session.inc.

Let me know what you find.

wwwoliondorcom’s picture

Thanks, I have the same issue and will test also.

gawrion’s picture

Subsribing too! The same problem with my site.

"I find that even when logged in, it still serves up the cached version of the front page, rather than the current one."

I know that my session is active (going deeper result in right displayed pages) and i only see logged out state of front page after logging in, but its annoying form me and ununderstandable for not smart users. After some time passes by, the front page displays right..

My .htaccess file:

# BOOST START

Header add Expires "Sun, 19 Nov 1978 05:00:00 GMT"
Header add Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"


AddCharset utf-8 .html

RewriteCond %{REQUEST_METHOD} ^GET$
RewriteCond %{REQUEST_URI} ^/$
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{HTTP_COOKIE} !DRUPAL_UID
RewriteCond %{DOCUMENT_ROOT}/cache/%{SERVER_NAME}/0/index.html -f
RewriteRule ^(.*)$ cache/%{SERVER_NAME}/0/index.html [L]
RewriteCond %{REQUEST_METHOD} ^GET$
RewriteCond %{REQUEST_URI} !^/cache
RewriteCond %{REQUEST_URI} !^/user/login
RewriteCond %{REQUEST_URI} !^/admin
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{HTTP_COOKIE} !DRUPAL_UID
RewriteCond %{DOCUMENT_ROOT}/cache/%{SERVER_NAME}/0%{REQUEST_URI} -d
RewriteCond %{DOCUMENT_ROOT}/cache/%{SERVER_NAME}/0%{REQUEST_URI}/index.html -f
RewriteRule ^(.*)$ cache/%{SERVER_NAME}/0/$1/index.html [L]
RewriteCond %{REQUEST_METHOD} ^GET$
RewriteCond %{REQUEST_URI} !^/cache
RewriteCond %{REQUEST_URI} !^/user/login
RewriteCond %{REQUEST_URI} !^/admin
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{HTTP_COOKIE} !DRUPAL_UID
RewriteCond %{DOCUMENT_ROOT}/cache/%{SERVER_NAME}/0%{REQUEST_URI}.html -f
RewriteRule ^(.*)$ cache/%{SERVER_NAME}/0/$1.html [L]
# BOOST END

lelizondo’s picture

Version: 5.x-1.0 » 6.x-1.13

I'm having the same problem, I'll move the version to the one I'm using. Steps to reproduce:

1. Make sure boost it's caching the frontpage and other pages and it's active. Then
2. Login in the frontpage
3. Logout immediately

You won't see the page as a anonymous user but as the user you used to login. If you move to other page you'll know you're an anonymous user, if you try to access /logout you'll get a 404.

Don't know if this is related to http://drupal.org/node/197786, I've tried a couple of the solutions in that post, #61 and #129 but I'm still having the same problems.

mikeytown2’s picture

@lelizondob
2 Questions:
ETags?
Is mod_headers enabled on your host?

lelizondo’s picture

OK, that was fast.

mod_headers IS enabled
ETags: Do Nothing

mikeytown2’s picture

@lelizondob
Try setting it to None; I got the location wrong so manually edit the htaccess file like so

### BOOST START ###
  AddDefaultCharset utf-8
  FileETag None
  <FilesMatch "(\.html|\.html\.gz)$">
...

Place FileETag None Above FilesMatch.

lelizondo’s picture

No, that didn't work. I'm just uploaded a video to show you exactly what the problem is, the video is less than 30 secs.

http://www.screencast.com/t/GkDwTqgB

Thanks

mikeytown2’s picture

Cool vid!
Just wondering what happens when you hit the logout button that is on the admin menu top bar?

lelizondo’s picture

it's the same behavior. I should have done that in the video.

mikeytown2’s picture

Do you have something that you can check what cookies are set? The cookie to look for is DRUPAL_UID.

lelizondo’s picture

I'm using Firefox's webdeveloper add-on to inspect the cookies and I'm seeing 8 cookies just after I hit logout, if I refresh the page I know I'll get rid of the admin_menu and the login block will show up again.

If I refresh I see the same cookies. If I login now I see:

Name	DRUPAL_UID
Value	1
Host	.iiiepe.edu.mx
Path	/
Secure	No
Expires	Sun, 22 Nov 2009 20:43:59 GMT
mikeytown2’s picture

Throughout the login logout process what happens to the DRUPAL_UID cookie?

lelizondo’s picture

Don't know exactly what you mean but If I login I get a cookie (actually 2, one with www.mydomain.com and another with domain.com) if I logout I don't.

mikeytown2’s picture

The DRUPAL_UID cookie controls if you hit the Boost cache. Seems like it's still set and doesn't get removed until the next page load.

/**
 * Implementation of hook_user(). Acts on user account actions.
 */
function boost_user($op, &$edit, &$account, $category = NULL) {
  if (!BOOST_ENABLED) return;

  global $user;
  switch ($op) {
    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;
    case 'delete':
      // Expire the relevant user page from the static page cache to prevent serving stale content:
      if (!empty($account->uid)) {
        if (BOOST_NO_DATABASE) {
          $paths[] = 'user/' . $account->uid;
          $flushed = boost_cache_expire_derivative($paths, TRUE);
        }
        else {
          $data[] = array('base_dir' => BOOST_FILE_PATH, 'page_callback' => 'user', 'page_id' => $account->uid);
          $flushed = boost_cache_expire_router($data, TRUE, TRUE);
        }
        if (BOOST_VERBOSE >= 7) {
          watchdog('boost', 'Debug: boost_user() <br />User !uid was deleted resulting in !flushed pages being expired from the cache',  array('!uid' => $account->uid, '!flushed' => $flushed));
        }
      }
      break;
  }
}
/**
 * Sets a special cookie preventing authenticated users getting served pages
 * from the static page cache.
 *
 * @param $user
 *   User Object
 * @param $expires
 *   Expiration time
 */
function boost_set_cookie($user, $expires = NULL) {
  if (!$expires) {
    $expires = ini_get('session.cookie_lifetime');
    $expires = (!empty($expires) && is_numeric($expires)) ? BOOST_TIME + (int)$expires : 0;
    setcookie(BOOST_COOKIE, $user->uid, $expires, ini_get('session.cookie_path'), ini_get('session.cookie_domain'), ini_get('session.cookie_secure') == '1');
  }
  else {
    setcookie(BOOST_COOKIE, FALSE, $expires, ini_get('session.cookie_path'), ini_get('session.cookie_domain'), ini_get('session.cookie_secure') == '1');
  }
  $GLOBALS['_boost_cache_this'] = FALSE;
}
mikeytown2’s picture

Status: Active » Needs review
FileSize
727 bytes

Try this, sets the cookie to way back...

lelizondo’s picture

Status: Needs review » Active

I applied the code, ran update.php, cleared the cache (both drupal and boost) but still having the same problem.

mikeytown2’s picture

Can I get a play by play of that cookies status?

Example:
Logged out - No Cookie
Logged in - Cookie
Logged in - Cookie
Logged in - Cookie
Logout button pressed - Cookie
Logged out - Cookie
Next page after logged out - No Cookie

lelizondo’s picture

Logged Out - No cookie
Logged in - Cookie
Logout button pressed - NO cookie
Refresh after logout button pressed - No cookie
node/x after I hit refresh - No cookie

mikeytown2’s picture

So at this stage
Logout button pressed - NO cookie
It appears like your still logged in.

OK so the cookie is getting cleared. For some reason then, your browser is caching the logged in page. You tried the solution in the other issue and it still doesn't work correctly. What happens when you use a different browser?

lelizondo’s picture

I've used firefox on ubuntu, firefox on mac, safari on mac and chrome on mac and I get the same behavior. I also hacked drupal with no result.

mikeytown2’s picture

Is it possible there is some sort of network cache involved? Try enabling this setting under boost:
Turn off clean URLs for logged in users.

Makes the URL's for logged in vs logged out be completely different.

lelizondo’s picture

No, that didn't work, maybe because the frontpage has the same value for both, but doing it with other pages didn't work either.

mikeytown2’s picture

Status: Active » Needs review
FileSize
900 bytes

This code might be related to the issue

/**
 * Implementation of hook_exit(). Performs cleanup tasks.
 *
 * For POST requests by anonymous visitors, this adds a dummy query string
 * to any URL being redirected to using drupal_goto().
 *
 * This is pretty much a hack that assumes a bit too much familiarity with
 * what happens under the hood of the Drupal core function drupal_goto().
 *
 * It's necessary, though, in order for any session messages set on form
 * submission to actually show up on the next page if that page has been
 * cached by Boost.
 */
function boost_exit($destination = NULL) {
  // Check that hook_exit() was invoked by drupal_goto() for a POST request:
  if (!empty($destination) && $_SERVER['REQUEST_METHOD'] == 'POST') {

    // Check that we're dealing with an anonymous visitor. and that some
    // session messages have actually been set during this page request:
    global $user;
    if (empty($user->uid) && ($messages = drupal_set_message())) {
      // FIXME: call any remaining exit hooks since we're about to terminate?

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

      // Rebuild the URL with the new query string.  Do not use url() since
      // destination has presumably already been run through url().
      $destination = boost_glue_url($query_parts);

      // Do what drupal_goto() would do if we were to return to it:
      exit(header('Location: ' . $destination));
    }
  }
}

Try this patch

mikeytown2’s picture

FileSize
1.81 KB

Another patch that shouldn't be so destructive to the cache

lelizondo’s picture

Status: Needs review » Active

Tried the patch and didn't work. I left the code from #18 and #19 on, don't know if I have to remove them before I apply the last patch.

mikeytown2’s picture

Status: Active » Needs review
FileSize
2.44 KB

Try this patch... don't put it into production its more of a "see if I'm barking up the right tree" kind of patch

lelizondo’s picture

Status: Needs review » Active

Sorry to take that long, somehow my Linux Server just crashed, I don't want to point fingers to boost but it was enabled. Anyway, I applied the patch to HEAD and now IT WORKS! I will confirm this with other users and other browsers but I think it's a step forward.

Thanks for all your help.

mikeytown2’s picture

@lelizondob
So the above patch "Fixes" the issue correct?

Can you verify that the cache is being generated and served with this hack? I'll start to work on a cleaner solution then what I have here. I'm glad we found the root of this bug!

mikeytown2’s picture

Title: Caching of front page » boost_exit(), user logout, destination/nocache & browser caching front page
lelizondo’s picture

No, the problem is still there, I just didn't know until a few hours latter.

I just created a video that will explain better, but basically I logout when I hit submit and I see the login block, but if I click on two or more pages and then go back to the frontpage I see myself logged in, if I click logout I get Access Denied because I was logged out.

http://www.screencast.com/t/u7KIuv52YiI

mikeytown2’s picture

When you see the login block after logging out, is that page in the cache? Is there the boost code at the bottom of the html? Good video btw!

mikeytown2’s picture

Plan B is to do a client side forced refresh on logout using javascript most likely; I'm assuming that reloading the page makes the problem go away correct?

So on user logout, inject javascript into that html that takes advantage of the reload() function inside the window.location object. I can probably just call location.reload(); and it will work. If I can put it in the head and have this work then that would be ideal, user sees a flash.

lelizondo’s picture

No, just when I logout that page isn't in the cache. I forgot to mention that. When I start navigating in the site those pages are in the cache. I'll try the javascript option on monday, but I'll will configure another site in a few more hours with boost and see how it goes.

mikeytown2’s picture

Can you try this without the patch I gave you?
Login
Logout
Press F5 (force refresh)

After the forced refresh, does the page have the admin bar at the top?

lelizondo’s picture

I tried and the page after the refresh does not have the admin bar and the page it's being generated by boost since I can see the boost print at the bottom of the source code.

mikeytown2’s picture

K cool, that means the javascript trick has a good chance of working.

mikeytown2’s picture

Status: Active » Needs review
FileSize
6 KB

Give this a spin... hopefully it works

mikeytown2’s picture

Issue tags: +Release blocker

I would really like to get this fix in 1.14; tagging as a release blocker for now.

lelizondo’s picture

I've just installed boost on another site that I'm launching this next Monday and it's working great, I'm using 1.13 and I don't have any problem at all.

I'm worried about this because now I don't know if the problem is boost or the drupal cache. I'll try the patch in #41 tomorrow in the site with the problem (the one in the video).

mikeytown2’s picture

Boost fixes issues with core sometimes because it effects how the cache works.

lelizondo’s picture

Wait a minute, forget what I've said about not having problems in this new site. I'm having the same problems, even worst. After I click logout I still see the page as if I were logged in (with the admin menu) and the page is not being generated by boost. If I hit refresh the page gets generated by boost and the admin menu goes away.

I'll try the patch in and I'll post the result in a few minutes. I'll do this with the following settings:

Drupal Cache: Disabled
Minimum cache lifetime: None
Block cache: Disabled
Optimize CSS files: Enabled
Optimize JS files: Enabled

Boost - HTML - Default minimum cache lifetime: 10 min
Servers URL or Name: %{SERVER_NAME}
Document Root: %{DOCUMENT_ROOT}
ETag Settings: Do Nothing

I tell you this because I want to make sure I have boost configured correctly and this will not affect the result of the patch.

lelizondo’s picture

btw, I have a simple question. does 'drush cache clear' also clears boost cache?

mikeytown2’s picture

Don't think it does.

lelizondo’s picture

Status: Needs review » Needs work

No, drush does not clear the boost cache.

I'm trying this in another site but it's not working, after I hit logout I still see the admin menu as I were logged in and boost and there's not 'boost print' on the source code. If I hit refresh the admin menu does not go away, if I hit logout I get 404. Now there's no way to get rid of the admin menu even thought I'm logged out, refreshing the page does not work at all.

mikeytown2’s picture

Status: Needs work » Needs review
FileSize
6.19 KB

Drush can if you set the Ignore cache flushes to disabled, but then you will be loosing the cache a lot more often then one might like.

So my little hack doesn't do the trick then. Try this patch. If this doesn't work I can try Plan C... which has the potential to be unstable if done incorrectly.

lelizondo’s picture

Status: Needs review » Needs work

One more thing before I try the patch. If I hit logout when I am in admin/* I get redirected to the frontpage (as I should) and the admin_menu goes away and the page it's generated by boost, the problem is when I hit logout on the frontpage or any other node.

mikeytown2’s picture

Cool. Plan C is to use the trick I recently learned from this thread #619934: CRON generates a "Page not Found" error...
In short if $_SERVER['REDIRECT_STATUS'] == 302 && Referrer == logout then inject the reload javascript. I have a feeling the javascript is being put in the 302 redirect that one gets after using the logout button.

lelizondo’s picture

Status: Needs work » Needs review

Haven't tried the patch but I changed the status. My mistake, I'm testing right now.

lelizondo’s picture

I just tried the patch and it doesn't work, the bad news is that when refreshing the frontpage doesn't give me the cached page, I still see the admin menu.

If I logout from admin/* I'm redirected to the frontpage with www.domain.com/?nocache=1. Then if I visit another page boost gives me the cached page, then if I go back to the frontpage now it's only www.domain.com and the admin_menu it's still there as if I were logged in.

One important thing about this site I'm patching right now is that I use panels in the frontpage but it isn't cached by panels. Don't know if that's actually important.

lelizondo’s picture

I've just discovered that I'm using poormanscron 1.x and according to my status page I should be using the 2.x branch. I don't think that's a problem but it's getting late and I don't want to discover that it was just a stupid thing I was doing so I better inform you about this.

lelizondo’s picture

I'm also using memcache and the memcache module, it's correctly configured. I read that it is possible to have both installed, am I right?

mikeytown2’s picture

Yeah memcache should work & I don't think poormans will effect this.

lelizondo’s picture

Status: Needs review » Needs work

just changing status

mikeytown2’s picture

Title: boost_exit(), user logout, destination/nocache & browser caching front page » user logout, destination, 302 redirect & browser caching front page

I don't think it would be that important. Plan D is to set a cookie on logout that then gets checked on the client side, if it exists then kill cookie and refresh page... after that I'm starting to run out of ideas. Anyway patch for Plan C will arrive in the next day or so; got other things to do.

After looking at this I think Plan C will work.
http://api.drupal.org/api/function/user_logout/6
http://api.drupal.org/api/function/drupal_goto/6
'HTTP_REFERER' == logout && 'REDIRECT_STATUS' == 302 will be the trigger for the javascript refresh injection. Fairly sure the javascript was pointless (in it's current form) after looking at drupal_goto & user_logout.

mikeytown2’s picture

Status: Needs work » Needs review
FileSize
7.41 KB

Local testing and Plan C will not work...

which leaves me with the plan D. I think adding a url variable called boost-logout set to 1 and then using javascript to see if that exits & if it does, redirect to the homepage. Hopefully this does it. If not, I'm out of ideas on how to fix this... well I could try a mod of this (use a cookie instead and don't inject any url variables) but hopefully this works.

Got 1 more idea, set a meta tag to prevent the browser from caching the front page.
http://www.pacificnet.net/~johnr/meta.html
hook_preprocess_page() $variables['head']

mikeytown2’s picture

FileSize
3.68 KB

Using the meta tag way, which I like a lot better.

mikeytown2’s picture

FileSize
3.68 KB
mikeytown2’s picture

Title: user logout, destination, 302 redirect & browser caching front page » user logout, Header unset ETag & browser caching front page
Status: Needs review » Closed (won't fix)

Heads up I am able to reproduce this bug finally after adding these lines to the bottom of my htaccess file

Header unset ETag

Bad idea, don't use Header unset ETag.

mikeytown2’s picture

lelizondo’s picture

I just came back and I'm lost, don't know now if I should apply the patch in #550488: Turn off mod_expires for all .php files or the ones in #59, #60 and #61

mikeytown2’s picture

lelizondo’s picture

cool. it seems like the problem is solved when I applied the patch in #550488: Turn off mod_expires for all .php files thanks for all your support

tg’s picture

Version: 6.x-1.13 » 6.x-1.16
Category: support » bug
Status: Closed (won't fix) » Patch (to be ported)
FileSize
1.5 KB

this patch you mentioned didn't fix it for me:
#550488: Turn off mod_expires for all .php files

however, I was able to fix it, see my patch

basically what it does: don't remove the cookie immediately, set it 0, then at the following request remove it.
this way the browser doesn't show the cached still logged in page, as before.

mikeytown2’s picture

Status: Patch (to be ported) » Needs review
FileSize
2.1 KB

did some tweaks to this that should make it better... in short if the cookie exists but your not logged in, remove the cookie; should fix the rare occurrence of the cookie getting stuck as well as this bug.

mikeytown2’s picture

FileSize
3.14 KB

changed the API for boost_set_cookie, takes UID instead of user object; makes the way this works easier to understand.

mikeytown2’s picture

Status: Needs review » Fixed

committed

Status: Fixed » Closed (fixed)

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

lelizondo’s picture

Status: Closed (fixed) » Active

is this really working? I just updated to the latest version and the pages are not being generated by boost (I don't see the boost tags) but maybe is just some misconfiguration. Can anyone confirm please?

Note: I updated the .htaccess with the new configuration boost provided and also with the patch in #550488: Turn off mod_expires for all .php files

mikeytown2’s picture

@lelizondob
Can you describe in more detail what is wrong? Best way to test boost is to use a different browser; although with the new version of boost, it's fairly aggressive when it comes to getting rid of the boost cookie. Also be aware that one of the settings does allow you to turn off the boost tags now; sets a http header instead (this is not the default in case you where wondering).

Stating that you just updated to the latest version of boost, was boost working before? If yes how old was your previous version of boost?

lelizondo’s picture

Version: 6.x-1.16 » 6.x-1.17

There's nothing wrong besides the fact that I don't see the boost tag at the end of the source code. I'm aware of the new option and I double checked that it is configured properly.

The only doubt I have is how to configure the Etag Settings, currently it's configured to "Set FileETag 'None' - Do not send an etag"

The version I was using before was 1.0-rc2 (with the patch inf #69), didn't realize it was that old till now that you ask.

I don't want to make a big deal of this since I updated in a mirror site, not the production one, but it has the settings from the live site and it's also running the Secure Site module, this could be affecting boost, I'm aware of that.

I'll update the production site in a few hours and let you know if there's a problem, if not, I'll be more than glad to close this issue myself.

mikeytown2’s picture

One thing to be aware of is the 'gz' directory has been nuked in the latest version of the rules. In your case I highly recommend getting the rules from the boost-rules page and not from htaccess1.txt. The generated rules will work in your case then.

lelizondo’s picture

I'm getting the rules from the boost page.

lelizondo’s picture

Status: Active » Closed (fixed)

It works great. Thanks. I'm closing this.