[squid-users] Vary object loop returns

[Yuri Voinov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
 
The world is not perfect, unfortunately. The ivory tower is revered
standards and regulations. In the real world they spit when it is
profitable. Especially when this recommendation and not rigid protocol
requirements. :)

We are also talking about money. Traffic is money. Therefore, the more
we will be able to properly and efficiently to cache - the better.


07.06.2016 17:00, Amos Jeffries пишет:
> On 7/06/2016 9:12 p.m., Yuri Voinov wrote:
>>
>>
>>
>> 07.06.2016 5:13, Amos Jeffries пишет:
>>> On 7/06/2016 6:20 a.m., Yuri Voinov wrote:
>>>>
>>>> By the way, we have another problem. Caching is greatly reduced by the
>>>> presence of User-Agent header Vary. Although I know that Amos says - he
>>>> says, we should break the Internet and cached separately all types of
>>>> user agents.
>>
>>> Please do not put your own beliefs into my mouth. I am very much in
>> Sorry, Amos. This was sarcasm. May be, not too relevant.
>>
>>> favour of denying Vary:User-Agent from being cached *at all* until the
>>> UA start sending sensible contents in the header. That would lower your
>>> precious HIT ratio a tiny amount.
>> Maybe. However, this greatly increases the content duplication. Аgree?
>
> I'm not sure what you are asking me to agree with there.
>
> The Vary:User-Agent has three cases that can happen:
>
> 1) caching it properly results in huge number of probably duplicated
> variants in the cache. Each response though is guaranteed to be correct
> for that UA when HIT happen.
>  I think we agree that situation is bad. Currently the store_miss
> directive is the best way to avoid that. Which makes #2 happen instead
> of this #1 case.
>
> 2) not caching it at all will lower the HIT ratio from sites using it.
> However a potentially large amount of cache space will become available
> for other better caching sites to use and raise their HIT ratio.
> Again each response is guaranteed to be correct for that UA.
>
> 3) caching one random copy from the server and delivering it to all
> clients regardless of their UA will produce a high HIT ratio. Something
> like the HIT ratio from #1 plus ratio gained by #2.
>  However, each response will randomy break a) clients expectations, b)
> the servers expectations, and c) the site authors behaviour expectations
> (ie security model).
>
> I believe #2 is the best tradeoff. You seem to be arguing for #3 solely
> on the IT ratio numbers, without considering the actual nasty side effect.
>
>
>>
>>> BTW: Do you know what "breaking the Internet" actually means? It's a bit
>>> ironic that you would throw that insult at me while praising what these
>>> patches currently do.
>> :) Really sorry.
>>
>> Sometimes our experiments scratching the hell out of the display content
>> in browsers. That's what I called "break the Internet". :) But
>> seriously, we're trying to find a compromise between a high cache and
>> the desire to satisfy customers. It seems to me, mutually exclusive
things.
>
> Ah. What I have been trying to get across is that they are not mutually
> exclusive like that.
>
> You have seen the display breakage. That is caused directly by things
> like client requesting identity encoding but being delivered a cached
> gzip object. Or worse, the garbage output from trying to decompress an
> identity object with gzip decompressor. The display gets F*'d.
>
> Note that the reason the wrong content came back in all the above
> display problems was that it was a cache HIT and the proxy ignored part
> of the Vary header when producing its response.
>
>
>>
>> Meanwhile, Amos, I still believe that the team should now, in 2016, to
>> seriously reconsider attitude to compress the content and possibly
>> revise Vary processing algorithms in favor of more vysokgo cache hit
>> ratio. Under the conditions of high-speed Internet only a high hit ratio
>> justifies the use of caching proxy.
>
> What attitude? For my part the response (to every submission) is that a
> patch doing it right will go in, not another hacked up job.
>
> Who is this "the team" ? It is all of us including you.
>
> We cannot revise the Vary algorithm, it is RFC defined. The best we can
> do for the forseeable future is hacked up tricks like filtering what
> headers get sent through to the server. I am part-time working with the
> Apache and Chrome devs in IETF to design a replacement Key header that
> works far better.
>
> Amos
> _______________________________________________
> 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
 
iQEcBAEBCAAGBQJXVrAgAAoJENNXIZxhPexGTIoIAI6myhj+dmayOOtBkfZxZfV3
i6xIldv7rpYNCI4RbPSCKhzsuA2/J+CzXkdFaimP4QaiJPljYn+u5ZNe4P/SxM3f
8xVR9VBhvdccGI4RhL3gJ+3VGSv55/xeIi6f4F2Hgkj1BNozLzg8h5G6Z+NpHi4b
xJ1ZR/KHPDUEToX1nLa1H5iLyXFfaMO9GcjEaCPIUsUO0zuuIi43xc3U9jrV2IIX
9zJ2TiSyorG4uOQYmEaks170SX2osizmD2+jYx1zPSm8ap//pMR+2WchdoeA+l/K
CpN4as9UaB+05IQp0AiYpLomiqr8YRbwq4woqbYQ8Nqu/VAXW9rbGM7rgmYu03I=
=+lJH
-----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/20160607/e3c5e5c7/attachment.key>