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.
Comment | File | Size | Author |
---|---|---|---|
#3 | boost-509694.patch | 2.05 KB | mikeytown2 |
Comments
Comment #1
EvanDonovan CreditAttribution: EvanDonovan commentedI 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.
Comment #2
mikeytown2 CreditAttribution: mikeytown2 commentedLogged in users shouldn't be in the cache; and they shouldn't grab from the cache when they login/logout.
boost_init()
boost_user()
Webform submissions should be taken care of by boost_exit() since it is done via POST.
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']
.Comment #3
mikeytown2 CreditAttribution: mikeytown2 commentedPlease test this patch, it should fix some of the issues your having.
Comment #4
EvanDonovan CreditAttribution: EvanDonovan commentedOk, 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.
Comment #5
mikeytown2 CreditAttribution: mikeytown2 commentedComment #6
mikeytown2 CreditAttribution: mikeytown2 commentedcommitted patch, please set to active if this didn't fix the problem.