[squid-users] Caching Google Chrome googlechromestandaloneenterprise64.msi

[Amos Jeffries]

On 23/10/2016 2:32 a.m., garryd wrote:
> On 2016-10-22 17:56, Antony Stone wrote:
>> Disclaimer: I am not a Squid developer.
>>
>> On Saturday 22 October 2016 at 14:43:55, garryd wrote:
>>
>>> IMO:
>>>
>>> The only reason I believe [explains] why core developers of Squid
>>> tend to
>>> move HTTP violating settings from average users is to prevent possible
>>> abuse/misuse.
>>
>> I believe the reason is that one of Squid's goals is to be RFC compliant,
>> therefore it does not contain features which violate HTTP.
>>
>>> 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.
>>
>> Which "tendency"?
>>
>> What are you asking for an official explanation of?
>>
>>
>> Antony.
> 
> 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.

The one thing that has changed is that we have slowly added support for
the RFC bits that allowed more and more objects to be cached. So this
has become more and more noticable as an outstanding non-cacheable response.


Amos