[squid-users] vary headers

[Amos Jeffries]

On 5/05/2015 3:15 a.m., Hussam Al-Tayeb wrote:
> 
> 
>> Sent: Monday, May 04, 2015 at 12:49 PM
>> From: "Amos Jeffries" <squid3 at treenet.co.nz>
>> To: squid-users at lists.squid-cache.org
>> Subject: Re: [squid-users] vary headers
>>
>> On 4/05/2015 6:54 a.m., Hussam Al-Tayeb wrote:
>>>> Sent: Sunday, May 03, 2015 at 9:45 PM
>>>> From: "Yuri Voinov"
>>>
>>>>
>>>> I understand what do your want. But for what?
>>>>>
>>>
>>> because a "wget --server-response http://someurl" operation that
>>> replies with a "Vary: user-agent" header always results in a MISS
>>> even if the same wget version (same user-agent) and computer.
>>> Instead, multiple copies of the file are stored.
>>
>> That is not right, the wget being used twice should be MISS then HIT,
>> just like any oter cacheable traffic.
>>
>> The nasty thing with Vary:User-Agent is that browsers UA string embeds
>> so much plugin info they are changing between each different client
>> request. Which defeats the purpose of caching one clients reply for use
>> by other clients.
>>
>> NP: what you had with the store_miss should be working.
>>  Are you using Squid-3.5 ?
>>  How are you identifying a fail ?
>>

> Hello. I am using 3.5.4
> There are new objects on disk that have the Vary: User-Agent Http header.
> I can tell for example if type head -n13 /home/squid/04/D1/0004D122
> 

That is not a good way to identify. All it means is that the object used
a disk file for its transfer. Cache files are also sometimes used as
on-disk buffers.

If you check with store.log for ID (0004D122) you should expect to see
that file pushed to disk, then a cache index RELEASED action performed.
The file part may stay on disk until something else needs to use the
same filename.

The ways to identify caching activity is:
 * access.log - checking that no HIT or REFRESH occur on the relevant
URLs, or
 * store.log - checking that objects with the URLs are all getting that
RELEASED action.
 * cache.log - setting "debug_options 20,3" and watching for "store_miss
prohibits caching"

There is unfortunatly currently no easy debugs linking what URL
store_miss prohibited to correlate the logs :-(

Amos