Store site view in HTTP headers
morphir - January 16, 2007 - 19:22
| Project: | Drupal |
| Version: | 5.x-dev |
| Component: | base system |
| Category: | feature request |
| Priority: | normal |
| Assigned: | morphir |
| Status: | duplicate |
Description
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.
#1
Additional information:
drupal_page_header()
includes/bootstrap.inc, line 486
http://api.drupal.org/api/head/function/drupal_page_header
#2
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);
}
#3
I found out that only store is necessery. So store in stead of no-store.
#4
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.
#5
#6
now there is a patch.
#7
Code looks good to me!
More reference on this directive here: http://www.httpsniffer.com/http/1409.htm#sec14.9.2
#8
Should be backported as well after this goes in.
#9
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.
#10
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).
#11
I've committed this to CVS HEAD.
#12
Should be applied to 5.x as well. Probably even 4.7.x could see this too since the patch is trivial.
#13
#14
This was already committed in HEAD, it was never backported to 5, nor 4.7
#15
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.
#16
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.
#17
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.
#18
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.
#19
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.
#20
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.
#21
discussion stopped two month ago. any strong reasons why this did not get backported to 5 yet?
#22
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 ?
#23
Please do not change the title, thanks.
#24
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.
#25
Committed to 5.
#26
#27
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
#28
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.