Re: Re: Caching responses with "Vary" responses

> Possibly a bug. Vary is not supposed to make an object non-cacheable.
> Only to determine whether an existing cached object is usable, or
> needs
> to be replaced with a different variant.
>
>
> Please re-test to see if this has been resolved as of 3.2.0.20, and
> if
> it remains whether you can find anything like a solution.
>
>
> NP: The current 3.2 will also be able to provide you a full HTTP
> headers trace on both incoming and outgoing connections of Squid at
> "debug_options 11,2". All four sets of headers will be useful in
> tracing
> this.
>

Amos, I don't know where to get 3.2.0.20, but I confirm the problem on
3.2.0.18-20120711 build.

I have two questions regarding squid processing logic:
1) In the attached logfile I can see that squid is initially looking for
the hash C447BB767EC4BC4DAC1820CE7999F4C4 in the store, but writes to
two other different hashes: 1E15DC758CD473D4A5994110A9F6E58D and
4DB6DCFE80050CF0CA306DB8EDFF718E - thus he can never find the cached
copy.

This behavior seems to be 'Vary'-related, since without the 'Vary' for
the first time squid writes to the same hash it was looking for.

2) What are those 235 bytes that are written to the 'vary' storeEntry
(created in setPublicKey)? And what is the purpose of that additional
storeEntry?

-- 
Best wishes,
Alexander Komyagin