cache problems - - drupal always shows outdated page [#38213]

I've set up a new drupal site on Drupal 4.6.3. Drupal always shows cached version of every page. For example I change settings in "admin/settings" and drupal gives me "The configuration options have been saved" only after I hit F5. Before that site behaves itself like no changes were made.

Steps to reproduce bug:

1. I point browser to home page (kneiphof.ru)
2. I log in (login:user, pass:user)
3. I point browser to home page again
4. Site shows me incorrect page (like I haven't logged in)
5. I press Refresh in browser (F5 in Firefox or Ctrl-F5 in IE)
6. Site shows me correct page (I've logged)

This happens to every page, for example admin/settings or admin/logs. Its impossible to administer site - changes appear only when I hit F5.

I've carefully read Drupal's issue Prevent browser page caching of dynamic content (marked closed). It propose 2 ways of solving this problem:

1. Patching .htaccess
2. Patching includes/bootstrap.inc

First way is already implemented in 4.6.3 AFAIK.

Second didn't solve my problem - pages are incorrect anyway. Also patch program (control-browser-caching_1.patch) says "Reversed (or previously applied) patch detected!" - what is this? I've tried to patch with control-browser-caching.patch - no changes in site behavior.

Headers from first request (one with incorrect response):

http://kneiphof.ru/

GET / HTTP/1.1
Host: kneiphof.ru
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051107 Firefox/1.5
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: ru,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://kneiphof.ru/node/1
Cookie: PHPSESSID=814e700925f159fef6724b3982fc4d36

HTTP/1.x 200 OK
Date: Fri, 18 Nov 2005 10:18:08 GMT
Server: Apache/1.3.33 (Unix)
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
<b>Age: 65</b>

Headers from second request (one with correct response):

http://kneiphof.ru/

GET / HTTP/1.1
Host: kneiphof.ru
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051107 Firefox/1.5
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: ru,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://kneiphof.ru/node/1
Cookie: PHPSESSID=814e700925f159fef6724b3982fc4d36
<b>Pragma: no-cache
Cache-Control: no-cache</b>

HTTP/1.x 200 OK
Date: Fri, 18 Nov 2005 10:20:08 GMT
Server: Apache/1.3.33 (Unix)
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

Forum discussions:

Comment	File	Size	Author
#22	bootstrap_0.inc	18.17 KB	a.k.karthikeyan
#1	bootstrap.inc	17.52 KB	dandaka

Comments

Comment #1

dandaka commented 30 November 2005 at 17:51

Status	File	Size
new	bootstrap.inc	17.52 KB

I've edited drupal_page_header() function in bootstrap.inc file (lines 424-429). Now drupal always gives me fresh uncached versions of all pages on my site.

I don't think its a best solution, but it solves my problem! Does anybody have ideas on way to fix this bug properly?

Comment #2

jo1ene commented 17 December 2005 at 00:25

I couldn't reproduce this.

Comment #3

jhorton commented 27 December 2005 at 23:19

Version:

4.6.3

» 4.6.5

Just wanted to confirm that this is also occurring on sites I am using, my notes:

* Occurs on a number of Drupal installations I have managed and so occurs on a number of servers (not server specific)
* Occurs in both ie and firefox (not browser specific)
* Does not occur on my localhost copies of those sites

This is quite a severe issue when you are trying to encourage repeat visitors to these sites, chances are if they do revisit they'll just see the same content from their first visit. It also makes editing the pages a pain as you have to continually refresh - to make sure you're logged in (or logged out) and to see the changes you've made

Comment #4

jhorton commented 27 December 2005 at 23:22

Apologies, should have also noted that I have tried:

The .htaccess fix
The bootstrap.inc fix

but with no success. I have turned off caching in Drupal as well.

Comment #5

dandaka commented 29 December 2005 at 15:29

"Does not occur on my localhost copies of those sites"

Same for me.

Comment #6

dandaka commented 12 January 2006 at 21:21

Version:

4.6.5

» 4.7.0-beta3

Just have beta3 installed - same issue.

Comment #7

Wesley Tanaka commented 13 January 2006 at 10:05

Status:

Active

» Closed (duplicate)

http://drupal.org/node/40597

Comment #8

Wesley Tanaka commented 13 January 2006 at 10:06

Status:

Closed (duplicate)

» Active

sorry, I got confused about which was reported earlier.

Comment #9

dandaka commented 13 January 2006 at 23:54

Again hacking bootstrap.inc file helped me.

Before:

function drupal_page_header() {
      if (variable_get('cache', 0)) {

After:

function drupal_page_header() {
<strong>      header("Expires: Sun, 19 Nov 1978 05:00:00 GMT");
      header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
      header("Cache-Control: no-store, no-cache, must-revalidate");
      header("Cache-Control: post-check=0, pre-check=0", false);
      header("Pragma: no-cache");</strong>
      if (variable_get('cache', 0)) {

Comment #10

peterx commented 14 January 2006 at 00:09

Can be ISP. The doc suggests caching is in the browser or server. ISPs cache to save costs and some ISPs implement only some cache rules so that they can save even more money. The joke used to be AOL caching things for 2 days instead of 2 hours. The result is a complex mix of anti caching HTML in an attempt to bypass every cache in the Internet. When you are performing your final tests, ask your friends to test on different ISPs including AOL.

Comment #11

dandaka commented 14 January 2006 at 14:41

How can I catch my ISP on cache cheating?

Maybe some test script, which will display headers in page body to compare with headers recieved by my browser? Any ideas?

Comment #12

dopry commented 2 February 2006 at 06:19

no, but I have been unable to reproduce this on uncached servers, but experienced similar issues experimenting with Drupal and some caching content delivery networks..

can anyone confirm or deny whether their isp's are using caches?

Comment #13

jetsetter commented 17 February 2006 at 09:40

I'm experiencing this as well. I find that it displays updated pages if i try logging in with a bad use name / valid user name.

rob

Comment #14

tangent commented 20 February 2006 at 16:55

Priority:

Critical

» Normal

Caching is a good thing. It prevents unnecessary downloads. Therefore, specifically disallowing caching as you have done is not a solution to anything.

I'm setting the priority to normal since 'having to hit F5 to refresh' is not a critical issue.

Comment #15

dandaka commented 22 February 2006 at 21:15

Priority:

Normal

» Critical

Please read description with proper attention.

If you have edited page with this bug, you will not see any changes after submitting information! This is critical bug which causes serious obstacles.

Comment #16

dries commented 23 February 2006 at 10:13

Taken from bootstrap.inc:

      // We store the time in the current user's $user->cache variable which
      // will be saved into the sessions table by sess_write().  We then
      // simulate that the cache was flushed for this user by not returning
      // cached data that was cached before the timestamp.
      $user->cache = time();

This might be a result of the session patch? Moshe? Looks like a problem for the session handling.

Then again, this is reported against Drupal 4.7.0-beta3 at which time the session handling wasn't touch upon yet.

Comment #17

moshe weitzman commented 23 February 2006 at 15:58

The original report was for 4.6. This isn't related to recent sessions handling change.

It sounds to me like this is aggressive caching on the part of some ISP or other intermediary (i.e. in your own office). It would be helpful if someone could look at their web logs and see if these cached requests are actually reaching the web server or not.

Drupal really ought to send explicit Cache-Control headers such as described in #9. I think the solution is at http://drupal.org/node/18390#comment-32126. That whole thread is informative. Somewhat less relevant is http://drupal.org/node/23287.

Matt Westgate looked into this area a couple of years ago. he might have some insight. I will email him.

Comment #18

moshe weitzman commented 23 February 2006 at 16:22

I just reread drupal_page_header() and it appears that we do try to send these cache-control headers so i'm not sure whats going on.

Comment #19

killes@www.drop.org commented 27 February 2006 at 19:15

Version:	4.7.0-beta3	» x.y.z
Priority:	Critical	» Normal

Whatever this is, it isn't reproducible by most people, so it can't be critical.

Comment #20

Wesley Tanaka commented 28 February 2006 at 14:31

I find that problems are much worse when browsing with squid than with no proxy. I'm using a squid that someone else set up, so I'm not sure if the settings are the defaults (for debian), but I would guess they were.

Comment #21

Donovan commented 4 June 2006 at 00:45

Version:	x.y.z	» 4.7.2
Priority:	Normal	» Critical

I'm having this same problem. It started happening a couple of months ago. I am using shared hosting from 1and1.com and Verizon Fios Internet service. It happens with IE, Firefox, Opera and AOL Explorer so it does not appear to be a browser setting problem. This is indeed a critical issue for anyone having the problem as it renders my Drupal sites practically unusable. Any additional information on how to correct?

Comment #22

a.k.karthikeyan commented 4 June 2006 at 13:10

Title:	cache problems - drupal always shows outdated page	» cache problems - Seems to work for me
Version:	4.7.2	» 4.6.8

Status	File	Size
new	bootstrap_0.inc	18.17 KB

Please find the modified bootstrap.inc file from line 480-485 . Note that there is no header("Cache-Control: no-store, no-cache, must-revalidate"); statement included as it causes file opening problems in IE. I am not sure about the logic behind this but it works for me.

Comment #23

beginner commented 19 June 2006 at 04:25

Title:	cache problems - Seems to work for me	» cache problems - - drupal always shows outdated page
Version:	4.6.8	» x.y.z

If the problem might still be in head, don't downgrade to a lower version.

Karryon, a patch would be welcome.

Comment #24

AjK commented 23 June 2006 at 14:35

Is this related to http://drupal.org/node/70075 for which I provided a patch. I does some hacking in drupal_page_header() regarding cache issues and external proxies. Maybe this is why it's hard to reproduce for many?

esp with #9 of this thread. The patch reworks how the "no proxy headers" get sent.

best regards
--AjK

Comment #25

magico commented 15 September 2006 at 20:45

A bit more information here http://drupal.org/node/41606

Comment #26

Wesley Tanaka commented 17 September 2006 at 02:37

commenting to subscribe

Comment #27

junyor commented 5 October 2006 at 02:56

Using Drupal 4.6.9, I can't reproduce the problem as described in the original issue report. Can someone provide a site and reproduction method for this issue? Does it only happen if Drupal's cache is enabled/disabled?