There is no caching in headers by default in core.

  header("Cache-Control: no-store, no-cache, must-revalidate");
  header("Cache-Control: post-check=0, pre-check=0", FALSE); 

Now, where a user is reading lots of comments. And gets tempted to click a link, he then decides to return and needs to start all over again(at the top). This is literally just silly and annoying. Now caching the page view so he ends up where he was reading is the solution.

I have always thought that this was a browser issue. But I realize this pretty much happens when surfing drupal sites.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

morphir’s picture

Additional information:

drupal_page_header()
includes/bootstrap.inc, line 486

http://api.drupal.org/api/head/function/drupal_page_header

morphir’s picture

Status: Active » Reviewed & tested by the community
FileSize
26.11 KB

Line 487

Jippii. Drupal now caches the page. Again, I see notting but positive reasons this lines being changed to the following.

function drupal_page_header() {
  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: store, cache, must-revalidate");
  header("Cache-Control: post-check=0, pre-check=0", FALSE);
}
morphir’s picture

Title: Cache HTTP headers » Store site view in HTTP headers

I found out that only store is necessery. So store in stead of no-store.

RobRoy’s picture

Version: 5.x-dev » 6.x-dev
Status: Reviewed & tested by the community » Needs work

Please don't RTBC your own patches. Features go against next version. Also, your patch is not really a patch. See http://drupal.org/patch on how to make a patch.

morphir’s picture

Status: Needs work » Needs review
FileSize
701 bytes
morphir’s picture

now there is a patch.

m3avrck’s picture

Status: Needs review » Reviewed & tested by the community

Code looks good to me!

More reference on this directive here: http://www.httpsniffer.com/http/1409.htm#sec14.9.2

m3avrck’s picture

Should be backported as well after this goes in.

moshe weitzman’s picture

Status: Reviewed & tested by the community » Needs review

this moved to RTBC with just a code review. Thats insufficient. We need testing. For example, if a user is anon and then logs into site, does he see stored page when revisiting an URL? that would be a bug.

m3avrck’s picture

Moshe, maybe it wasn't clear from my post.

I posted a link to what the "store" directive means. It has nothing to do with caching the output of the page, it only affects information that is stored *about* the page.

For example, if you goto a page, enter some content in the forms, then navigate away and try and come back, all of the data is lost. Not only that, but your XY coords on the page are lost so it always puts you at the top.

This patch allows the browser to *store* this info, which greatly enhances the usability of Drupal.

It doesn't affect logging in/out. (and yes this has been confirmed by me, feel free to confirm my results though, but please notice how much more friendly the back button is now).

Dries’s picture

Status: Needs review » Fixed

I've committed this to CVS HEAD.

m3avrck’s picture

Version: 6.x-dev » 5.x-dev
Status: Fixed » Reviewed & tested by the community

Should be applied to 5.x as well. Probably even 4.7.x could see this too since the patch is trivial.

drumm’s picture

Version: 5.x-dev » 6.x-dev
m3avrck’s picture

Version: 6.x-dev » 5.x-dev

This was already committed in HEAD, it was never backported to 5, nor 4.7

killes@www.drop.org’s picture

I am not sure this shoudl be backported. It causes Drupal to behave differently. Untill now, all pages would get reloaded, this is no longer the case. This is a rather big change in UI.

m3avrck’s picture

It's a rather huge usability boost and makes Drupal work like all other websites :-)

It's a usability fix but it's really a bug fix---Drupal broke people's back button.

Chris Johnson’s picture

I think this should be backported to D5 and 4.7. The change in behavior is non-destructive, and brings Drupal behavior more in line with what most people expect.

drumm’s picture

Version: 5.x-dev » 6.x-dev
Status: Reviewed & tested by the community » Needs work

I think this might be okay for Drupal 5, but I think it needs to be fixed in 6 first.

Section 14.9, Cache control of RFC 2616, HTTP 1.1, has a list of cache response directives. 'no-store' is allowed, but 'store' is not mentioned. It might be a commonly used cache extension as specified in section 14.9.6, but we would have to show that some major browsers use it.

I think the 'store' bit can simply be omitted.

anders.fajerson’s picture

Could be worth noting that so far I've only seen the "non-store" behaviour in Firefox. Opera and IE6 remembers form and page states, and their back-buttons are as fast as ever. Only tested Windows browsers though. So potentially only Firefox is affected by this patch.

moshe weitzman’s picture

Status: Needs work » Reviewed & tested by the community

drumm is likely right, but i don't think thats sufficient reason to withhold this patch from backport. it has been deemed acceptable for HEAD, and loads of sites are sufferring without it. it is compleetly harmless to output a cache directive which is not implemented.

alaa’s picture

Version: 6.x-dev » 5.x-dev

discussion stopped two month ago. any strong reasons why this did not get backported to 5 yet?

tesliana’s picture

Title: Store site view in HTTP headers » Is this not a show stopper ?!?

Everybody seemed to agree that current behaviour is totally unacceptable and then the whole issue went frozen cold. What gives ? Should such Drupal NON USABILITY not be treated as a showstopper ?

m3avrck’s picture

Title: Is this not a show stopper ?!? » Store site view in HTTP headers

Please do not change the title, thanks.

Dries’s picture

Title: Store site view in HTTP headers » Store site view in HTTP headers

tesliana: the patch was committed to Drupal HEAD thus it will be part of the next Drupal version. It has not been backported to Drupal 5 yet, but that's up to Neil (branch maintainer) to decide. We've to be careful that we don't break other modules/features by committing this patch.

drumm’s picture

Status: Reviewed & tested by the community » Fixed

Committed to 5.

Anonymous’s picture

Status: Fixed » Closed (fixed)
ChrisOwens’s picture

Status: Closed (fixed) » Active

This breaks the download of file attachments using IE6 and IE7 when accessing the site via https

See
http://drupal.org/node/173697

See also
http://support.microsoft.com/kb/316431

drumm’s picture

Status: Active » Closed (duplicate)

There does not need to be two tickets open for the same issue. Please use http://drupal.org/node/173697, which has more detail on this specific problem.