[squid-users] Caching Google Chrome googlechromestandaloneenterprise64.msi

Yuri Voinov yvoinov at gmail.com
Sat Oct 22 13:45:45 UTC 2016


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
 


22.10.2016 19:32, garryd at comnet.uz пишет:
> 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 at comnet.uz 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
Well, what of it? What developers RFC got good money from Google for
ignoring caching level standards. Because that Google is profitable.
"Hey - they say - these dumb bastards all unlimited internet! Let it pay!"

And Google is not the only example in this case. I have seen, for
example, http://www.example.com/big_fucking_favicon.ico?null=0 design.
Where the size of the icons was hundreds of kilobytes! How about this?
Do not tell me that this is required for the functioning of the site - a
code may be in the picture?

What's the bottom line? Let's continue to sit on horseback, dressed in
white, and pray to the RFC!

> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
 
iQEcBAEBCAAGBQJYC22IAAoJENNXIZxhPexGELAH/02opOgF+Jh4fff/6T15ECMB
kqobxY+RYdLgkzGV23Fx88dLD4AHDQIapw7tlbpgzGpjc8N4z78AY/TSBRT/l3AP
l7wfQ+Egq9DRC2Z+XXN5oQT0naIgHmGbJl73btpG9t59u84N9jqMrA4i3fnVy0aO
fY1dq5+aG6jo4aGB17QzL9JGJxFsBkVbAvI6ZVJ445RMmoeh4+MHOUoewv7h/xY6
GSRN9kwdAfhqkGtiRAH4y8mpexRAztpTB6EOpGXupJzRuTuAujB2LGKlbnHYvXL4
a+PzlcvG8n2ZHy4YtjxRg0mymbM59F7SZvMTTRaQ7knD/2/cnXTx5U22roT57Io=
=kpXt
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x613DEC46.asc
Type: application/pgp-keys
Size: 2437 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20161022/5a19aed5/attachment.key>


More information about the squid-users mailing list