Re: [squid-users] inconsistency with objects in squid cache

On 8/04/2014 2:02 a.m., Sylvio Cesar wrote:
> 2014-04-06 13:46 GMT-03:00, Eliezer Croitoru <eliezer_at_ngtech.co.il>:
>> On 04/06/2014 05:29 PM, Sylvio Cesar wrote:
>>> but this happens only in the network 10.21.155.0/24.
>> then squid.conf and the debug_options output would help to understand if
>> it is the reason or there is another reason.
>>
>> Eliezer
>>
>
> Hi Eliezer,
>
> I noticed that when there is the header "Vary:
> Accept-Encoding,User-Agent" the object is not cached.

The object *is* cached...

> ------
>
> KEY 7351B3AA6DB80247DE63873CAB59CFE8
> STORE_OK IN_MEMORY SWAPOUT_DONE PING_DONE
> CACHABLE,DISPATCHED,VALIDATED

Note the "CACHEABLE" and "STORE_OK" and "SWAPOUT_DONE".

> LV:1396873562 LU:1396873566 LM:1394577094 EX:-1
> 0 locks, 0 clients, 1 refs
> Swap Dir 0, File 0X000001
> GET http://xxx.example/video/video.flv
> vary_headers: accept-encoding,
> user-agent="curl%2F7.19.0%20(i686-suse-linux-gnu)%20libcurl%2F7.19.0%20OpenSSL%2F0.9.8h%20zlib%2F1.2.3%20libidn%2F1.10"

However only a client which sends the *exact* headers marked above will
be able to fetch it.

> inmem_lo: 0
> inmem_hi: 15089604
> swapout: 15089604 bytes queued
>
>
> KEY E08FBDC74EAD09CEBCC38380DACCF63F
> STORE_OK IN_MEMORY SWAPOUT_DONE PING_NONE
> CACHABLE,VALIDATED
> LV:1396873566 LU:1396873566 LM:-1 EX:1396973566
> 0 locks, 0 clients, 0 refs
> Swap Dir 0, File 00000000
> GET http://xxx.example/video/video.flv
> inmem_lo: 0
> inmem_hi: 227
> swapout: 227 bytes queued
>
>
> How to make squid perform the object cache when found in the header
> "Vary: Accept-Encoding,User-Agent"???
>

Always fetch using the same browser agent. Any time the Accept-Encoding
OR User-Agent header changes (even by 1 byte) a new object will be
fetched and cached.
 ... this is not a reasonable thing for real users to do. They all
choose a mix of browsers, players and versions.

Alternatively if you have control over the web server it needs
redesigning in a way that prevents Vary:User-Agent from being sent.

Amos
Received on Mon Apr 07 2014 - 23:49:45 MDT