Default "Cache-Control" header to "public" for front-end siteaccesses so that Varnish / reverse proxies can cache

[benkmugo]

@peterkeung re-discovered and fixed the issue on a recent migration/upgrade.

In an eZ Platform + LegacyBridge + Lovestack setup Varnish was unable to cache the legacy responses due to the cache control header being sent as 'private'.

The updated setting fixes the issue so that when used in frontend siteaccesses Varnish can cache what needs to be cached.

The questions remaining:

enable this by default?
does it need further explanation?

[benkmugo]

Ping @pkamps

[pkamps]

I think we should change the default value to 'Cache-Control: public'. For the public siteaccesses it definitely should be the default. But even for the admin siteaccess I think we would want to have it set to public: we want a reverse-proxy (varnish) to cache admin pages - the cache variations (different users) needs to be handled differently (for example by the session id in the session cookie).

Maybe we add some example entries (commented out) to better explain how to use the Cache-Control header for a public site:

## Fallback Rule
#CustomHeader=enabled
#OnlyForContent=disabled
#Cache-Control[/]=max-age=180;100
# Make everything 3 levels under the following subtrees cached for 60 minutes
##Cache-Control[/World]=max-age=3600;7;3

It is not good enough to just set it to 'public' - you need to give it a max-age value to have the reverse-proxy caching it (unless the reverse-proxy has a default rule to cache everything for 15min)

[peterkeung]

Disagree about the admin pages -- on every one of our sites, the traffic to the admin pages is low enough that the performance benefit of caching them in a reverse proxy does not outweigh the extra complexity (and risk) in configuration.

[pkamps]

Test if the installation wizzard is using the new settings in the new siteaccess you setup within the wizzard.

[pkamps]

The installation wizard is completely ignoring the existing siteaccess directories. So there is no point updating those. Instead ezp uses the configuration from the downloaded package you choose in the installation wizard. For the lovestack, it's our own lovestack demo package. I made those change and I get your changes in the siteaccess the wizard creates: mugoweb/mugo_lovestack_demo@19a8ed2

I have not figured out if you can add comments but it looks like that it's not possible. So I only added your suggestion into the settings and not other examples.

Is that solution good enough to close this pull request?