[squid-users] Caching Google Chrome googlechromestandaloneenterprise64.msi

[Amos Jeffries]

On 24/10/2016 11:49 p.m., Yuri wrote:
> 
> 
> 24.10.2016 16:42, Alex Crow пишет:
>> On 24/10/16 11:26, Yuri wrote:
>>
>>> No, Amos, I'm not trolling your or another developers.
>>>
>>> I just really do not understand why there is a caching proxy, which
>>> is almost nothing can cache in the modern world. And that in vanilla
>>> version gives a maximum of 10-30% byte hit. From me personally, it
>>> needs no justification and no explanation. And the results.
>>>
>>> I can not explain to management why no result, referring to your
>>> explanations or descriptions of standards. I think it's understandable.
>>>
>>> At the present time to obtain any acceptable result it is necessary
>>> to make a hell of a lot of effort. To maintenance such installation
>>> is not easy.
>>>
>>> And as with every new version of the caching level it falls - and it
>>> is very easy to check - it is very difficult to explain to
>>> management, is not it?
>>>
>>> It's not my imagination - this is confirmed by dozens of Squid
>>> administrators, including me personally familiar. Therefore, I would
>>> heed to claim that I lie or deliberately introduce someone else astray.
>>>
>>
>> I'd rather have to explain to management about a low hitrate than have
>> to explain why they weren't seeing the content they expected to see,
>> or that some vital transaction did not go through, but, hey look here,
>> we're saving 80% of web traffic bill!
> So, what are you talking about - the smallest of the problems that can
> be easily testing and solving by existing functionality - such as no_cache.
> 
> In any case - it is the choice of each and I only wish to have all
> possible tools. And not to have my hands tied.

Squid is moving to HTTP/1.1 specifications. It no longer does some
things the HTTP/1.0-ish way.

I keep mentioning over and over again:  the controls you keep asking for
are only needed by the HTTP/1.0 behaviours ... to make the HTTP/1.0
proxy operate more like HTTP/1.1 !! But not quite identical to a 1.1
proxy/cache because it adds traffic problems that the true 1.1
proxy/cache does not allow to happen.

Squid is being converted to HTTP/1.1 native behaviour. The controls no
longer are needed in the bits that have been converted, the current
releases do *better* than what you are asking for when faced with
Cache-Control:no-cache, private etc. which have been converted already.

Having controls to force the old 1990's behaviour on todays Internet
traffic only leads to old bugs and problems being forced on clients. The
gains you got from those controls on HTTP/1.0 traffic are now just
happening naturally with HTTP/1.1 - no knobs need turning on/off for it
to happen.

So the old settings are going away (replaced). If the new behaviour
needs new settings that is something to discover as Squid improves.
Evidence so far is that there are few needed, but that could change.


So lets put it this way:
 You started with a proxy that could do X and be forced to also do a Y
and a Z thing.
 You then upgraded to a proxy that did X and Y, and be forced to do a Z
thing.
 So you complain that you can no longer force the new proxy to do Y thing.

Makes no sense to me unless I assume you are confused by the way the
forced-Y looks different to the real Y - though both are almost the same
thing. The difference being how real-Y fixed some nasty bugs caused by
forced-Y.


> 
> Especially when there are competing products that provide the desired
> results. Yes, they cost money. But management is not often ask - just
> buy what they need, by they opinion, and you - with Squid - went to look
> for a job. So simple.
> 

There will always be other products that do part of what Squid does
along with other things Squid does not. Just like Squid does part of
what they do and other things they do not.

Causing a product installation to produce corrupted traffic responses
does not help with that products reputation compared to 'the
competition' - no matter whether its Squid or something else. Whereas
reliable and accurate data transfer integrity is a cornerstone for good
reputation in any caching or networking product.

Amos