326297 - Remove no-store from the headers sent in the Developer Control Panel

Status: RESOLVED WORKSFORME

(addons.mozilla.org Graveyard :: Public Pages, defect)

Description

[Thomas Bertels]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

The no-store header prevents Firefox from keeping a copy of the page in memory (which speed-up the back and forward navigation).
Due to the bug 215405, the scroll position isn't remembered either.
Please remove it, as it won't impact the page freshness but will allow a faster navigation.

Reproducible: Always

Steps to Reproduce:

Comment 1

[alanjstr]

I'd say this is server ops.  

Comment 2

[Dave Miller [:justdave]]

(In reply to comment #1)
> I'd say this is server ops.  

Nope, the server config is adding the following cache-related headers:

Expires at 1 day for gif, jpg, and png files;
Expires at 6 hours for css files;
Vary: user-agent

Anything else you're getting is coming directly from the app.

Comment 3

[Thomas Bertels]

I've just noticed that this only occures when we're logged in.
I don't remember if it was happening even when we're not logged in when I submitted this bug, so I don't know if it has silently been changed in the mean time.
Anyways, it would still be better to never send this header, the reload button is there and we know how to use it.
See also http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.2

Comment 4

[Michael Morgan [:morgamic]]

I can see the header, and it is not caused by anything setting it explicitly in the app -- I grepped for no-cache, got zero results.  So I read up on PHP sessions and found some info.

If you read the following on session config options in php.ini:
http://php.osuosl.org/session

Look for session.cache_limiter.

The explanation reads the by default in all PHP instances session headers will contain "nocache" as the default set of headers for sessions.  The default is to ensure people using a default PHP install don't cache sensitive pages unless they specifically change this value in php.ini or during runtime.

So I looked for some more detail about the actual headers PHP sends out based on the session.cache_limiter parameter.  I found this, which is a pretty good explanation:
http://www.php-mag.net/magphpde/magphpde_article/psecom,id,637,nodeid,21.html

We have two possible choices:
a) set the default session.cache_limiter to private
b) do nothing and just leave it the way it is

For me personally, I haven't had any problems caused by the no-cache header, so a WONTFIX or WORKSFORME would be just fine as far as I'm concerned.

It is a simple fix, local to iguana (not across all LVS nodes), so I'll step back and leave it up to the server team to determine whether or not changing the default could potentially affect other applications.

Comment 5

[Thomas Bertels]

I don't think it's a good thing to remove all the nocache headers: only the no-store is bad.
So just sending "Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0" should do the trick.
The default Cache-Control headers will then be discarded.
Remember that this only occurs in the Developer Control Panel (so when we are in /developers/).

Comment 6

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Following morgamic's WORKSFORME, if we reopen it should be as a server-ops bug.

Comment 7

[Thomas Bertels]

(In reply to comment #4)
There's a third choice:
c) use this command: header("Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0");
This will overwrite the default Cache-Control header without changing the session.cache_limiter parameter (which would also remove the no-cache, must-revalidate,... headers).
Additionally, the pages are encrypted, so they aren't cached by default.
Removing the "no-store" part of the Cache-Control header would allow faster back/forward browsing.
This change can and has to be done in the website code, so this isn't a server-ops bug.