[squid-users] Squid 3.5.16 and vary loop objects (bug ?)

[Amos Jeffries]

On 7/04/2016 5:05 a.m., joe wrote:
> amos question ?
> 
> off topic sorry for that 
> 
> vary is the second key store right ?

I'm not sure what you mean by "second key store". Its a bit ambiguous.

Squid looks up the URL and finds an object saying there is Vary header
details also needed.
Squid does a second lookup (on the same cache) for a string containing
URL + extras.
Squid then verifies that the object found by that second lookup actually
matches the URL *and* that it has a correct Vary header for the pattern
being looked up (to make sure its from the current Vary set and not some
older obsolete set).

> 
> same object with 2 browser  firefox
> accept-encoding="gzip,%20deflate"
> 
> chrome
> accept-encoding="gzip,%20deflate,%20sdch"
> 
> so if they ar 2*1 object stored is that right   ? 

 (2 +1) objects. Add not multiply.

> and other browser might have more compression 
> accept-encoding="gzip,%20deflate,%xxxxxxxxxxx
> that will be 3*1   right  if yes

That would be a third variant, yes.

>   why not filtering only the one has (not
> %) = accept-encoding="gzip"
> and use that only it will be beter hit and save more storage
> just idea what you think  ??  since "%"  meaning those compression not used
> for the object only
> the one without it 

The object encoding is not relevant. Surprising maybe, but true.

Think of it like this:

 If you request from me a drink, indicating that you will take Coffee or
Tea. I hand you a Coffee.
 *  Does that mean I dont have plain Water? of course not.

 If you asked me for a drink and indicated you will take Coffee, Tea or
Water. I might hand you Water.

 If you asked for Coffee or Tea a second time. I might hand you Tea.

 If you asked for Beer or Coffee. I might hand you Water. (Even though I
did have Coffee earlier, and I might have Beer but not be willing to
deliver it yet)


The one thing in common with all the requests above was Coffee. But
notice how the most common thing delivered was actually Water, and
sometimes Tea.



Back to caching.

The variant object stored at cache location:
   URL + 'accept-encoding="gzip,%20deflate"'

... is *only* guaranteed to be whatever object needs to be delivered
when the client sends "Accept-Encoding: gzip, deflate". That is all.


When the server response contains "Vary: Accept-Encoding" then even a
single-character difference in two client requests Accept-Encoding
header means a different cache variant object. Because that small
difference does mean it could be a different type coming back. Including
the *absence* of that header being one possible variant.

Amos