[squid-users] Caching Google Chrome googlechromestandaloneenterprise64.msi

[Yuri Voinov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
 
I will explain why I am extremely outraged by this position. Every
single major players - both from the Web companies and from suppliers
caching solutions (BlueCoat, ThunderCache etc.) - to one degree or
another violate RFC. And developers of position - is to be paladins in
white robes, who strictly follow these _recommendations_ (not standard,
please note!) And to be holier than the Pope, even at the expense of its
users!

And, what is the strangest thing, while being the most support among the
users.

At the same time, for a moment, everybody forgets one simple thing.
Traffic - is money. A lot of money. Almost nowhere is there any truly
unlimited Internet, and we - the users - are paying money for it. And
because of the position of developers, we lose money. Anybody are told -
"Relax, you can always make a fork Or you can always make some crutches
as you like. This OpenSource, baby!". We can - and do. But this is - not
the solution. This is problem disregard.

Yes, we can make a fork. Yes, we can buy a commercial solution. But then
the question arises - why, in fact, if at all there is Squid? For
pathos? Or, as a source of commercial forks?

The trend is that the one who can with impunity violate RFC - he got a
lot of money. Remaining calm myself that this is the standard, it is
required to follow all. Go on! Most people believe that Squid is worth
nothing as a caching proxy! And - they right. Vanilla Squid makes not
above 10% byte hit. With increasing latency. Yes, I know that he is not
currently marketed as a caching proxy. Just in case, I'll take another
proxy, without the useless features that are not possible without the
need to break the RFC recommendations. Just - not needed.

22.10.2016 18:56, Antony Stone пишет:
> 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.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
 
iQEcBAEBCAAGBQJYC2X3AAoJENNXIZxhPexGgZYH/1/YbvICadk7nrFD/6znHC8y
JD74iAsB9XEKm9VSKKF+dEmKpBKs0iP4kJe75NZqJ8dBh6hM5H5FDAix7kvqkSj1
rJqxaqzZs2FfOO2+ylNYAVyjSVDWrsstpvX2fBMK8I4+WDXzAHzvYrFyo/KpP8uO
brdlrWrubMH0mfAJGIiVT/R3rNuRh7ZXkihakv2iLTg4ayZsQoDEgcbFfDW9ZN0M
mPWiPe2gofluXj2lYoAH/albY0NVypyvCSs0c9CBjvFwaMyj1pzbpHz0udsM1ix8
uZ7WTQPnuM4qh1lFNPHJ1bMUW3Fz9AiHXdrs2Ct0llppoj+pdGoAG4aQuefZhDw=
=pGxs
-----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/81922b68/attachment.key>