By jaybee1001 on

I've been trying to get to the bottom of a seemingly very common problem with Drupal Page Caching. There are countless threads on the subject (sorry to start another...), and many attempts at a 'fix' but none seem to work for all the major browsers. I've created this thread in the hope that the very LATEST thinking can be brought to the surface.

Here is my experience:

No Page Caching:
No problems (except for a v slow site...)

With Page Caching (normal) turned on:
1. FIREFOX 3.5
1a. Using vanilla Drupal 6.15 (no hacks etc.): displays the classic 'logout' problem - logging out returns the user to the home page, but the login block still shows the user as logged in. Refreshing the page with shift+F5 displays the page correctly.
1b. Using vanilla Drupal 6.15 (no hacks etc.): after logging in, additional menu items are then displayed as access control is used. Browsing back to the site home page displays a cached version of the home page, minus the additional menu items (as it was cached prior to login).

2 IE8
No problems. All seemed to work OK

2. HACKED bootstrap.inc
As discussed extensively in http://drupal.org/node/197786, hacking bootstrap.inc line 638 to read "Cache-Control: no-store, no-cache, must-revalidate" seems to partially fix both 1a and 1b in Firefox.

3. Drupal 6.15 already includes the proposed fix from http://drupal.org/node/550488.

4. In http://drupal.org/node/197786#comment-2031310, Damien Tournoud states that this is not a Drupal issue and will not be fixed...

5. Applying the hack in http://drupal.org/node/197786#comment-1817644 results in inconsistent behaviour in Firefox 3.5. Some previously cached pages (prior to login) display correct menus and login/logout context while others display incorrect menus and incorrect login/logout context. In IE, any previously cached pages (prior to login) are displayed with incorrect menus and login/logout context, whilst pages not visited previously are displayed with correct menu and login/logout context.

CONCLUSIONS:
It seems to me that there is something wrong with the approach to caching used by Drupal 6.x, as this issue affects multiple browsers (ruling out a browser issue?)
Should authenticated sessions use the page cache at all? Perhaps they should use their own cache?
In this way, there would be no risk of the two separate states mixing cached content and screwing up the browsing context.

Is there a solution anywhere out there? Page caching is really crucial, and I am surprised that there are so many reports of problems and seemingly little acknowledgement of the issue from the Drupal team.

Anyone with experiences/ideas/solutions - BRING THEM ON!

Thanks.

⋅ Categories: Drupal 6.x

Comments

bsenftner’s picture

bsenftner commented

just subscribing to keep tabs on this issue.

-Blake
www.BlakeSenftner.com www.3D-Avatar-Store.com

robmoffat’s picture

robmoffat commented

I've just upgraded to Firefox 3.5, and I'm seeing this (1a and 1b) issue today. subscribing

hapydoyzer’s picture

hapydoyzer commented

This is issue with Drupal AND with parent caching proxy. (#197786: Some servers / browsers will cache pages even when header Cache-control: no-cache is set)
Try this testcases: http://test.kv-plata.ru and say which of them worked for you.

apodic’s picture

apodic commented

+1

curtaindog’s picture

curtaindog commented

Thanks for the links jaybee1001, however there are two separate issues here. One relates to the HTTP headers that Drupal sends back that instructs the browser how to cache the page (i.e. the caching is client side). As far as I know there is no way to configure how Drupal controls this. To be honest, I would like to see Drupal disable browser caching for any non-static file. In this day and age there's not going to be a hell of a lot of difference between serving up a 304 or the rendered HTML again (it's mostly a bandwidth saving device). The other is the Drupal 'Page Cache', which lives server side, and stores the rendered version of a page rather than rebuilding it from scratch every time (this is mostly a CPU saving device and as such is much more important). This is the one you can turn on and off - although pages for authenticated users are never cached in this manner. WRT this form of caching, I don't really know when the page cache is invoked and how it interacts with all the other caches (block, theme, menu, views).

thepayislousy’s picture

thepayislousy commented

Thanks for the excellent summary!

A significant # of my users see the 1a & 1b problems, irrespective of browser. For others (and me), everything works flawlessly.

I have all caching OFF! I'm using Go Daddy grid hosting, and the no-store bootstrap.inc hack (no effect, as I would expect). I've tried .htaccess and settings.php hacks to explicitly set the cookiedomain -- no effect.

This is maddening. My CiviCRM-on-Drupal system works perfectly otherwise -- but this never-ending Drupal login problem is a dealbuster, and I'm forced to look for another solution next year.

My conclusion from spending hours reading Drupal bug reports: the authentication/caching system is broken and needs a total rewrite. Blinding speed is good -- but not at the expense of usability.

david.a.king’s picture

david.a.king commented

subscribe

I have serious problems with logging in and out and other page altering with firefox (and partially chrome) no matter what cache or bootstrap.inc settings I have.. I don't need to flush anything to see changes to bootstrap.inc or something do I?