[squid-users] Caching Google Chrome googlechromestandaloneenterprise64.msi

[garryd at comnet.uz]

On 2016-10-23 18:31, Amos Jeffries wrote:
> On 23/10/2016 2:32 a.m., garryd wrote:
>> Since I started use Squid, it's configuration always RFC compliant by
>> default, _but_ there were always knobs for users to make it HTTP
>> violent. It was in hands of users to decide how to handle a web
>> resource. Now it is not always possible, and the topic is an evidence.
>> For example, in terms of this topic, users can't violate this RFC
>> statement [1]:
>> 
>>    A Vary field value of "*" signals that anything about the request
>>    might play a role in selecting the response representation, 
>> possibly
>>    including elements outside the message syntax (e.g., the client's
>>    network address).  A recipient will not be able to determine 
>> whether
>>    this response is appropriate for a later request without forwarding
>>    the request to the origin server.  A proxy MUST NOT generate a Vary
>>    field with a "*" value.
>> 
>> [1] https://tools.ietf.org/html/rfc7231#section-7.1.4
> 
> 
> Please name the option in any version of Squid which allowed Squid to
> cache those "Vary: *" responses.
> 
> No such option ever existed. For the 20+ years Vary has existed Squid
> has behaved in the same way it does today. For all that time you did 
> not
> notice these responses.

You are absolutely right, but there were not such abuse vector in the 
past (at least in my practice). There were tools provided by devs to 
admins to protect against trending abuse cases. So, the question arised, 
what changed in Squid development policy? Why there is no configuration 
option like 'ignore_vary [acl]', so highly demanded by many users in the 
list? Personally, I'm no affected by the Vary abuse, but I suppose there 
will be increasing number of abuse cases in the future. One of your 
answers confirmed my assumption regarding the question:

>  - 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.

Garri