i've reproduced this bug in FF 1.5, FF 2.0, IE 6 and IE 7.
bootstrap.inc adds the following cache control header to pages served to authed users:
header("Cache-Control: store, no-cache, must-revalidate");
the intent is to allow the browser to cache the page results, and return the cached page to the user if the user hits the back button, but force a reload in all other situtations.
unfortunately, the interaction between this core behavior and boost caching allows the browser to serve the stored, authed, page after a user logs out.
to reproduce:
view a page while anonymous (maybe unneccessary)
login
view the same page while logged in
logout
return to the page again - the browser will return it's cache of the authed page (you can confirm by viewing source and seeing if the boost banner displays at the bottom of the page)
why this happens:
let's say that boost has cached forum as forum.html at 13:00
you view forum while authed at 13:05
the browser caches the authed forum page with a timestamp of 13:05
you logout
you view forum again, and your browser revalidates the page with the web server
however, since you are now anon, the boost redirects go into effect, and the web server revalidates against the cached forum.html file.
there have been no changes to forum.html since 13:05, so the web server returns a 304
the browser served it's cache of the authed forum page
the only workaround i currently have for this is to change the Cache-Control header in bootstrap.inc to
header("Cache-Control: store, cache, must-revalidate");
it's hard to notice this bug unless you have a page that displays differently for anon and authed users (say, the login block, or something keyed to the user in your theme, or a node_access module that suppresses some content for anon users). for many sites, this isn't really a problem.
Comments
Comment #1
firebus CreditAttribution: firebus commentedsorry, change the Cache-Control header to:
header("Cache-Control: no-store, no-cache, must-revalidate");
Comment #2
davidwhthomas CreditAttribution: davidwhthomas commentedyes, I've noticed the same problem here.
pressing shift+refresh will force a fresh page load but it's not a good solution for alot of non-technical users.
Oddly, this still happens with mod_expires on and html set to expire in 1sec in the apache config.
Interested in a solution.
Comment #3
davidwhthomas CreditAttribution: davidwhthomas commentedOK, I take it your solution about the setting the cache-control header to 'no-store' was the solution as that's what I found in the end.
This thread helped:
http://drupal.org/node/185075
It may also be neccessary to add the 'no-store' directive to your default .htaccess file also.
Either that or change it in bootstrap.inc around line 533, though that is a core hack which should be avoided if at all possible.
P.S Totally awesome module, by the way :-)
Comment #4
GiorgosKI have similar problem but unrelated to Boost module,
I have not been able to consistently reproduce it
but it seems to be related to the browser's cache
Checking out this solution
Comment #5
bbilocura CreditAttribution: bbilocura commentedHello,
I am experiencing this same issue on Firefox 3 with the 6.x-dev version of Boost.
Some testing reveals this:
After logging in and going back to my site's home page, Firebug shows that Cache-Control is set to "store" and not "no-store." So, when I hit the logout button, I am shown a browser-cached version of the home page as if I were logged in. I am using the bootstrap.inc core hack to work around this in the meantime.
Cache-control is set to "no-store" when visiting the site as an anonymous user. It's only when logged in that Cache-Control gets set to "store."
Comment #6
mikeytown2 CreditAttribution: mikeytown2 commentedIt appears this issue is in direct conflict with this one: #185075: Only apply "do not cache" headers to files inside the the cache folder..
@bbilocura
would you mind testing the
Turn off clean url's for logged in users
setting to see if that "fixes" the problem.Comment #7
mikeytown2 CreditAttribution: mikeytown2 commenteddup found #554982: Watchdog Logging Access Denied as Anonymous for Admin Actions
Comment #8
Starminder CreditAttribution: Starminder commentedsubscribe
Comment #9
bbilocura CreditAttribution: bbilocura commentedMikeytown2,
Unfortunately, disabling clean URLs for logged in users does not fix the problem. Firefox is still showing the logged in page after I log out unless I force-refresh in the browser.
I should add that Boost works as expected out of the box with IE and Opera. I'm only having issues with Firefox.
Comment #10
Tally CreditAttribution: Tally commentedA related issue is at http://drupal.org/node/197786
This issue has been around for a while. It is not unique to the Boost module. I am getting ready to test the latest patch in comment #108.
I had previously applied the patch from comment #61, which is the same change as suggested by the OP and in comment #1 here.
Comment #11
mikeytown2 CreditAttribution: mikeytown2 commentedI'm guessing that adding this to the .htaccess file won't work then? Can someone verify?
http://www.askapache.com/htaccess/using-http-headers-with-htaccess.html#...
Comment #12
mikeytown2 CreditAttribution: mikeytown2 commentedIf you don't want to hassle with patching core, pressflow fixes this bug.
http://pressflow.org/
Comment #13
mikeytown2 CreditAttribution: mikeytown2 commentedCan I get someone to confirm that switching to pressflow fixes the issue?
Comment #14
mikeytown2 CreditAttribution: mikeytown2 commentedI need more info, to see if #11 or #12 works. I can then start to work on a fix/recommendation.
Comment #15
Tally CreditAttribution: Tally commentedUsing the patch of #10 (comment #61) and the OP gives me Access Denied when I use the back button.
I have not tried the .htaccess patch of #11.
I installed Pressflow described in #12. I navigated some authenticated user pages only and then logged out. Using the FF back button, I could see the previously viewed pages just as if I were still logged in. I added no-store, to the Cache-Control variable as noted by OP and in #10, and when I use the back button I get Access Denied, which is what I would expect.
PS: I like Pressflow. My first impression is that my shared hosting test setup seems slightly faster, but I have not measured it. Thanks for the tip.
Comment #16
mikeytown2 CreditAttribution: mikeytown2 commented@tally
so pressflow does not fix the issue correct?
The last thing to do before patching core would be #11. Can someone verify if this works?
Comment #17
dbeall CreditAttribution: dbeall commentedhad this happen Aug 30th (once) on davebeall.com(test site) with FF, almost tried #11, but can't reproduce it now.. will keep trying to reproduce. It was showing 1 cached page with View, Edit, Outline and Track tabs(was on that page, then logged out using admin_menu). Dumped the cached page with FTP manually.
I am almost sure it was Aug29th-dev, have since upgraded newer -dev.
Comment #18
mikeytown2 CreditAttribution: mikeytown2 commentedupdating title based on #197786: Some servers / browsers will cache pages even when header Cache-control: no-cache is set being marked as won't fix.
Comment #19
mikeytown2 CreditAttribution: mikeytown2 commentedwould someone who is experiencing this problem try this patch out: http://drupal.org/node/585424#comment-2073406. There's a slight chance it might fix it.
Comment #20
fawkstrot CreditAttribution: fawkstrot commentedI'm experiencing this problem using the latest dev, which appears to have the fix from http://drupal.org/node/585424#comment-2077370 commited.
Sometimes, for me anyway, this also makes the logout function sometimes not work entirely, rendering the authorized user cache page on the logout redirect. Is it possible writing authorized cookies again somewhere in the loop of things?
Comment #21
mikeytown2 CreditAttribution: mikeytown2 commentedThis might be related info. Apache sets Etags for files, which means the paths that come from boost get an etag.
#608102: Option to disable etags for static boosted files
Comment #22
dbeall CreditAttribution: dbeall commentedFirefox has been doing this to me using Boost 6.x-1.12. It's the browser cache.
I figured it was a firefox problem with 3.5.3
The logout hasn't been an issue, I am using admin_menu.
The admin_menu top bar goes away at logout, but the Drupal edit, view tabs remain until I clear the browser cache and history...
actually, I like the old version of firefox better.
Comment #23
mikeytown2 CreditAttribution: mikeytown2 commentedTry disableing etags, let me know if that fixes it.
Add this to the bottom of your htaccess file.
Comment #24
dbeall CreditAttribution: dbeall commentedInternal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Comment #25
mikeytown2 CreditAttribution: mikeytown2 commentedtry just this
Comment #26
dbeall CreditAttribution: dbeall commentedFixed..
login, edit a node(blog post) , save, logout, go back to blog node, tabs gone...
Comment #27
dbeall CreditAttribution: dbeall commentedback track to double check, remove etag none; tabs are back..
Comment #28
mikeytown2 CreditAttribution: mikeytown2 commentedCool, thanks for the testing!
Comment #29
bbilocura CreditAttribution: bbilocura commentedHello,
#25 appears to solve the problem for me.
Comment #30
mikeytown2 CreditAttribution: mikeytown2 commentedI'll make this the default, with the option to have etags on if desired.
Comment #31
dbeall CreditAttribution: dbeall commentedwe need to tell people what etags are and why they might want them on.
ie: use caution, etags can crash your server and burn your house down if used improperly!
Comment #32
mikeytown2 CreditAttribution: mikeytown2 commentedBy default no etags are given for php responses, only static files. So disabling it makes Boost even more transparent, but then the server will not return a "304 Not Modified" ever, so the site will seem slightly slower. It's a trade off, thus it should be a setting.
Would one of you mind testing the location of the etag? Place it below the
</IfModule>
tag.Comment #33
dbeall CreditAttribution: dbeall commentedI tried it,, sorry, you just can't be right every time. But most of the time is perfectly fine..
lol. no it didn't work, acts as it did without it.
Comment #34
mikeytown2 CreditAttribution: mikeytown2 commentedJust to make sure placement in the htaccess file isn't critical can you try this
Comment #35
dbeall CreditAttribution: dbeall commentednope, acts as before adding it
Comment #36
mikeytown2 CreditAttribution: mikeytown2 commentedok, lets try it after all the rewrite rules...
Comment #37
dbeall CreditAttribution: dbeall commentedsomething not right here....
That don't work either..
I checked the file after upload to be sure it went with the change.. it's there.
but it's not working... Tabs are there after an edit.
Could the server be holding an old htaccess file somehow, like a cache..
Comment #38
mikeytown2 CreditAttribution: mikeytown2 commentedput it at the end of the htaccess file. Apache may not like that inside the
<IfModule mod_rewrite.c>...</IfModule>
tagsComment #39
dbeall CreditAttribution: dbeall commentedi put it back at the end of htaccess and it still won't work..
but it was there before and it worked..
the internet has been acting weird the past half hour.. but that is probably a hop someplace
Comment #40
mikeytown2 CreditAttribution: mikeytown2 commentedno rush, let me know the results of the various placements when your server is reading the htaccess file correctly. We know it works at the end of the file.
Comment #41
bbilocura CreditAttribution: bbilocura commentedI was a bit premature in saying the ETags fix worked--now it stopped working for me too!
I'm confused, since I used the same steps to test the fix as I did now. Everything was working as expected last night, but not anymore.
FWIW, I tried placing the ETag line at the end of the file and after BOOST END. Neither works anymore. Very confusing.
Comment #42
mikeytown2 CreditAttribution: mikeytown2 commentedI think I figured part of this out. If this is effecting you mod_headers is not installed with your version of apache.
Can someone who is encountering this issue give me full headers, using firebug? Headers for each step that you do when testing for this bug. Example
Or google chrome can do it as well
Comment #43
dbeall CreditAttribution: dbeall commentedthe top bar of the admin menu is not going away now.. have not tested etag placement yet today.
anonymous view front page
admin view edit node
admin view node after save
anonymous view node after logout
Comment #44
dbeall CreditAttribution: dbeall commentednote, just catching up today.. the etag is still on server
EDIT I may not be a lot help with firebug.. I still haven't figured out all that stuff.
Comment #45
mikeytown2 CreditAttribution: mikeytown2 commentedThis issue is something that I can not programmatically fix. The no cache headers are not being sent out due to mod_headers not being installed with your version of apache.
Compare my site - anonymous view front page
To your site - anonymous view front page
One last thing to try: Setting the etag!
Give me anonymous view front page headers before and after, with the etag set.
Comment #46
dbeall CreditAttribution: dbeall commentedanon front page
logged out front page after edit a node
Comment #47
mikeytown2 CreditAttribution: mikeytown2 commentedAnd it probably didn't fix the bug either, did it... going to mark this by design. I would contact your host and ask about getting mod_headers included in apache; could be as easy as
sudo a2enmod headers
http://man.he.net/man8/a2enmod
Comment #48
mikeytown2 CreditAttribution: mikeytown2 commentedComment #49
dbeall CreditAttribution: dbeall commentednot a problem, submitted a note to the server guys.. it's their call, I made a decent case for it.
after all, it is a Drupal centric outfit.
I am sorry this cost you time.. I was going to let it go by..
I do not like wasting peoples time.
The best I can do is say Thank You
Comment #50
plan9 CreditAttribution: plan9 commentedThanks for posting the solution to this. I had exactly the same problem and it was driving me nuts as different browsers seem to behave differently in the way they cache content.
#25 and #47 solved this conclusively.
Comment #51
plan9 CreditAttribution: plan9 commentedAlso - for the benefit for others wading through this - I think it's worth clarifying that there are 2 separate - but related - issues being discussed in this thread.
1. A core problem with Drupal caching which has a workaround in #1
2. A problem with Boost and browser caching fixed with #25 and #47
In my case - because I'm running a social networking type site with content access restrictions - I needed to apply both fixes, but other situations may require only one, or neither.