On 23/10/2016 1:43 a.m., garryd@xxxxxxxxx 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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
