Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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.
Comment | File | Size | Author |
---|---|---|---|
#6 | bootstrap-store-page-view_0.patch | 701 bytes | morphir |
#5 | bootstrap-store-page-view.patch | 701 bytes | morphir |
#2 | bootstrap_1.inc | 26.11 KB | morphir |
Comments
Comment #1
morphir CreditAttribution: morphir commentedAdditional information:
drupal_page_header()
includes/bootstrap.inc, line 486
http://api.drupal.org/api/head/function/drupal_page_header
Comment #2
morphir CreditAttribution: morphir commentedLine 487
Jippii. Drupal now caches the page. Again, I see notting but positive reasons this lines being changed to the following.
Comment #3
morphir CreditAttribution: morphir commentedI found out that only store is necessery. So store in stead of no-store.
Comment #4
RobRoy CreditAttribution: RobRoy commentedPlease 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.
Comment #5
morphir CreditAttribution: morphir commentedComment #6
morphir CreditAttribution: morphir commentednow there is a patch.
Comment #7
m3avrck CreditAttribution: m3avrck commentedCode looks good to me!
More reference on this directive here: http://www.httpsniffer.com/http/1409.htm#sec14.9.2
Comment #8
m3avrck CreditAttribution: m3avrck commentedShould be backported as well after this goes in.
Comment #9
moshe weitzman CreditAttribution: moshe weitzman commentedthis 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.
Comment #10
m3avrck CreditAttribution: m3avrck commentedMoshe, 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).
Comment #11
Dries CreditAttribution: Dries commentedI've committed this to CVS HEAD.
Comment #12
m3avrck CreditAttribution: m3avrck commentedShould be applied to 5.x as well. Probably even 4.7.x could see this too since the patch is trivial.
Comment #13
drummComment #14
m3avrck CreditAttribution: m3avrck commentedThis was already committed in HEAD, it was never backported to 5, nor 4.7
Comment #15
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedI 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.
Comment #16
m3avrck CreditAttribution: m3avrck commentedIt'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.
Comment #17
Chris Johnson CreditAttribution: Chris Johnson commentedI 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.
Comment #18
drummI 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.
Comment #19
anders.fajerson CreditAttribution: anders.fajerson commentedCould 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.
Comment #20
moshe weitzman CreditAttribution: moshe weitzman commenteddrumm 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.
Comment #21
alaa CreditAttribution: alaa commenteddiscussion stopped two month ago. any strong reasons why this did not get backported to 5 yet?
Comment #22
tesliana CreditAttribution: tesliana commentedEverybody 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 ?
Comment #23
m3avrck CreditAttribution: m3avrck commentedPlease do not change the title, thanks.
Comment #24
Dries CreditAttribution: Dries commentedtesliana: 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.
Comment #25
drummCommitted to 5.
Comment #26
(not verified) CreditAttribution: commentedComment #27
ChrisOwens CreditAttribution: ChrisOwens commentedThis 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
Comment #28
drummThere 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.