[drupal-devel] [bug] Clicking on Home after login brings up browser-cached non-logged-in version of home page

moshe weitzman drupal-devel at drupal.org
Fri Feb 11 01:47:45 UTC 2005

 Project:      Drupal
 Version:      cvs
 Component:    user system
 Category:     bug reports
 Priority:     critical
 Assigned to:  mathias
 Reported by:  christianlong at christianlong.com
 Updated by:   moshe weitzman
 Status:       patch

i think this is a small, worthwhile patch. this bug plagues drupal.org
as well.

moshe weitzman

Previous comments:

February 16, 2004 - 15:44 : christianlong at christianlong.com

Attachment: http://drupal.org/files/issues/f_040214_01.txt (6.33 KB)

This bug has been discussed before, but not resolved.
One suggestion was to change the browser settings.  That means I have
to tell all my users to change their browser cache settings. Not a
great way to run a site.
Instead, the login should just work with default browser settings. 
Currently, login does not work, as described below.
I log in to my drupal site, feingold.christianlong.com, and the
logged-in home page appears, with my user name. OK.
The address bar shows
In the site menu, the "Home" link links to
Here's the problem: when I click on the "Home" link, the browser takes
me to the un-logged-in version of http://feingold.christianlong.com/,
which was cached when I was not logged in.
When I hit refresh, I do get the logged-in version of the page.
So, to restate
Start at home page of site, not logged in
Log in - this works, and brings up a logged-in version of the page
Click "Home" - this is where the problem is. I get the cached version
of the home page (from when I was not logged in)
Refresh browser - now I see the correct, logged-in version of the home
It looks like I am logging in OK, but that Drupal is not telling my
browser that there is a new version of the home page that it needs to
check for
Maybe the original (non-logged-in) version of the page is not marked
for no-cache, and so when I click on the "Home" link, I get the cached
(non-logged-in) version
Browsers: MSIE 6 (happens a lot) and Firebird (happens sometimes).
Also happens with christianlong.com
Attached, find an annotated record of the HTTP header traffic.


February 16, 2004 - 15:48 : christianlong at christianlong.com

Forum discussion is here


March 4, 2004 - 12:49 : moshe weitzman

I am seing this same behavior at http://www.nshp.org [1]. To see for
yourself, login using the box on the home page while using IE (Firefox
doesn't have a problem).
user: mwtest8
pass: testpass
Here is the php config of the server [2].
Note that IE is set to "Check for newer pages: automatically" in
Options -> Temporary Internet Files -> Settings
Thoughts on how to resolve this are welcome.
[1] http://www.nshp.org/phpinfo.php
[2] http://www.nshp.org/phpinfo.php


June 15, 2004 - 21:38 : duztin

I had this problem, fix the date on your pc, mine was a month ahead and
my cookies were expiring too soon.


July 27, 2004 - 15:18 : killes at www.drop.org

Setting to cvs. Is the fix proposed by duztin a real fix? if not: what
else could we do?


October 16, 2004 - 16:45 : mathias

Attachment: http://drupal.org/files/issues/browser_caching.patch (644 bytes)

I'm moving this to critical because in some cases this bug causes the
hidden $edit['destination'] value of the login form to be set to
'logout', and to the user it appears they can't login since they are
immediately logged out again. Very frustrating.
The other side effect of this browser caching bug are, as stated above,
the authenticated user will receive stale pages and if you have the
login block enabled it will look as though they're were unexplicably
logged out.
It all depends on your browser and its settings, but to attempt to
1. Login to your site.
2. Next, Click the homepage link. If you are served a stale copy of the
page, you've hit the bug. This seems to happen more with IE and Safari
than Firefox.
A potential patch is to have Drupal issue the following header:

header('Cache-Control: no-store, no-cache, must-revalidate');

It works, but I don't know the implications this has on other Drupal
components such as RSS conditional GETS and gzip page serving.


October 21, 2004 - 13:30 : mathias

Attachment: http://drupal.org/files/issues/browser_caching_0.patch (593 bytes)

Thanks to Ethereal [3] and LiveHTTPHeaders [4], I was able to trace
this problem to the Cache-Control header being sent by Mac OS X server.
On this OS, mod_expires [5] is enabled by default for Apache which sets
the Cache-Control time to 60 seconds for dynamically rendered pages.

The implications of this action are that once you login, re-visiting
any page on the site will result in stale, locally-cached versions if
you viewed that page within 60 seconds of logging in. Since you weren't
logged in on those pages, the system will have appeared to logged you
out. It will keep doing this unless you wait 60 seconds to login. Thus,
users perceive this as a failure to successfully log in.

This new patch doesn't tweak bootstrap.inc. Instead it uses .htaccess
to test if mod_expires is enabled and resets the caching time to 1
second for dynamically rendered content. The benefit of this approach
is that it doesn't interfere with other types of caching that may be in
place for images, pdf files, etc.

# Overload mod_expires variables.
<IfModule mod_expires.c>
  # Reduce the time dynamically generated HTML pages are cache-able.
  ExpiresDefault A1

Down the road it may also be wise to consider sending our own caching
headers to maintain control of our caching environment. I reviewed the
following pieces of software, all of which intentionally disable
caching by the client browser or proxy caches. I just grabbed the ones
I thought were most popular.

Plone (Cache-Control parameter is configurable)
Wordpress (except for RSS feeds)

And if you're so inclined, here's the relevent code snippets [6] for
each piece of software.
[3] http://www.ethereal.com/
[4] http://livehttpheaders.mozdev.org/
[5] http://httpd.apache.org/docs/mod/mod_expires.html
[6] http://asitis.org/tmp/cms_cache_review.txt


October 21, 2004 - 13:39 : moshe weitzman

I'v seen this bug on drupal.org, so this impacts more than OSX server
... Looks like a nice clean patch to me.


October 26, 2004 - 11:21 : jvandyk

+1 from me. This reduces confusion among end users while retaining
caching ability for other mime types.


October 27, 2004 - 03:05 : wazdog

Does this end up having any effect on the RSS conditional GETS? If not,
then +1 from me.
(The WordPress code does check for RSS, so I'm thinking this may set
them to expire too?)


October 27, 2004 - 20:58 : jvandyk

Attachment: http://drupal.org/files/issues/htaccess_0.patch (792 bytes)

Regarding the concern about RSS caching: this patch is identical to the
previous one except instead of targetting the default we target the
text/html MIME type.

<IfModule mod_expires.c>
  # Reduce the time dynamically generated HTML pages are cache-able.
  ExpiresByType text/html A1

This means that RSS feeds, which are MIME type text/xml, are not

View: http://drupal.org/node/5900
Edit: http://drupal.org/project/comments/add/5900

More information about the drupal-devel mailing list