413936 - Allow pages to be cached

Status: VERIFIED FIXED

(support.mozilla.org :: General, defect)

Description

[Jason Barnabe (np)]

The headers in the response for PHP files on the site include

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Expires: Thu, 19 Nov 1981 08:52:00 GMT


If I understand correctly, "no-store" means pages should never be cached, and "must-revalidate" means that the page must not be used after its expiry date. This is making it so that even when you press Back or Forward, the page is always entirely reloaded.

mozillaZine uses

Cache-Control: no-cache, pre-check=0, post-check=0

which allows for Back/Forward without reload. We should do this as well.

Comment 1

[David Tenser [:djst]]

Ah, this explains why going Back/Forward is so slow on SUMO. Can you make a patch for this, Jason?

Comment 2

[Jason Barnabe (np)]

I tried searching for code that does this, and I couldn't find anything that would be setting this site-wide. Maybe it's in some other configuration file, like Apache or PHP?

Comment 3

[Jason Barnabe (np)]

This also results in data loss, for example if you enter a bunch of info but mess up the captcha, then try to go back, you lose what you wrote.

Comment 4

[Nelson Ko [:nkoth]]

I have added admin configurable fields for custom cache-control headers and Admin... General. Put no-cache, pre-check=0, post-check=0 in the field for BOTH options and it should work:

HTTP cache control header:, and
HTTP cache control header (no PHP session):

Give it a try. Although it might be tempting, don't set the second option to something that allows full caching for now. That has the side effect of causing the user to see a cached (unchanged) page after logging in, and until a mechanism to take care of that is available, allowing full caching could be problematic.

Comment 5

[David Tenser [:djst]]

Jason, can you test this?

Comment 6

[Jason Barnabe (np)]

It looks like it works in that the cache headers I set are honored.

The suggested setting for cache headers seem to be doing the job correctly as well.

Comment 7

[Marc Laporte]

Should this be upstreamed?

Comment 8

[James Socol [:jsocol, :james]]

(In reply to comment #7)
> Should this be upstreamed?

Having direct, granular control over headers, separated by HTTP/HTTPS, would be a powerful feature.

Comment 9

[Louis-Philippe Huberdeau]

Upstreamed current options, however, changed the preference names to fit better in conventions.

tiki_cachecontrol_session
tiki_cachecontrol_nosession

I also placed those in the performance panel rather than general.

The headers also don't have priority like they used to. The preference values are loaded as part of the normal phase rather than the init phase used for session and caching preferences.

r24644