Re: Caching responses with "Vary" responses

On 10.07.2012 02:14, Alexander Komyagin wrote:
> Hi! I've just noticed that when remote server replies with Vary
> header
> parameter set, squid won't cache that reply. For example:
>
> aaa@bbb:~$ wget -O /dev/null -S http://www.ietf.org/rfc/rfc3280.txt
> --2012-07-09 18:03:20-- http://www.ietf.org/rfc/rfc3280.txt
> Connecting to 10.0.0.89:3128... connected.
> Proxy request sent, awaiting response...
> HTTP/1.1 200 OK
> Date: Mon, 09 Jul 2012 14:03:55 GMT
> Server: Apache/2.2.10 (Linux/SUSE) mod_ssl/2.2.10 OpenSSL/0.9.8h
> PHP/5.2.13 with Suhosin-Patch mod_python/3.3.1 Python/2.6
> mod_wsgi/3.3
> mod_perl/2.0.4 Perl/v5.10.0
> Last-Modified: Fri, 10 May 2002 00:17:43 GMT
> ETag: "9fe907-48284-3a095ba1a77c0"
> Accept-Ranges: bytes
> Content-Length: 295556
> Vary: Accept-Encoding
> Content-Type: text/plain
> X-Cache: MISS from my_proxy
> Via: 1.1 my_proxy (squid/3.2.0.16)
> Connection: close
> Length: 295556 (289K) [text/plain]
>
>
> Reason:
> StoreEntry::setPublicKey() is called for the reply, since originally
> it
> seems cacheable, but when "vary" header is detected
>
> /* if (mem_obj->vary_headers && !storeGetPublic(mem_obj->url,
> mem_obj->method)) */
>
> squid creates new StoreEntry (which is created with KEY_PRIVATE flag
> set, since neighbors_do_private_keys is 1) and
> writes to it -- this way the result won't be stored because
> KEY_PRIVATE
> is set (I failed to find any place where this flag shall be
> cleared).
>
> Is this behavior normal? Or is it a bug or something?

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.

Thank you
Amos
Received on Mon Jul 09 2012 - 22:41:58 MDT