[squid-users] Caching Google Chrome googlechromestandaloneenterprise64.msi

[Amos Jeffries]

On 23/10/2016 1:43 a.m., garryd at comnet.uz wrote:
> 
> Nevertheless, I believe that core developers should publish an
> _official_ explanations regarding the tendency, as it often becomes a
> "center of gravity" of many topics.
> 

I did so. Back when these removals started:

<https://squidproxy.wordpress.com/2012/10/16/squid-3-2-pragma-cache-control-no-cache-versus-storage/>

The later options have all been documented (but less in-depth) in the
release announcements for the version which changed, in release notes,
and in squid.conf docs for the series (eg.
<http://www.squid-cache.org/Doc/config/refresh_pattern/>). With a
statement of what they have been replaced with.

They all have been *replaced* with updated behaviour, not simply dropped
as some noisy complainers keep stating.


Also the notion that we have suddenly dropped any control over Vary is
simply false. Squid has never had any way to violate Vary
specifications. The old "broken_vary" feature *prevented* caching of
some Vary. The recent proposal is the opposite of that, about ignoring
Vary for purely the purpose of polluting client users traffic with false
data.

 - there is zero benefit to anyone else in the HTTP ecosystem (and
Internet) beyond the individual sysadmin who proposes doing it.

 - there is serious negative effects to everyone. Including the sysadmin
proposing doing it.

 - there is a very high risk of copy-and-paste sysadmin spreading the
problems without realising what they are doing. Particularly since those
proposing it are so vocal about how great it *seems* for them.

 - there is zero wiggle room in HTTP specifications to work with. These
are absolute "MUST NOT" criterion with no similar mechanism to pretend
was received that would leave HTTP even partially working. (at least not
until Key header exists).

Amos