Varnish and max-age=0

Guillaume Quintard guillaume at varnish-software.com
Fri Jul 21 09:49:23 CEST 2017


Common mistake, beresp.uncacheable isn't the opposite of beresp.ttl>0.
"uncacheable" tells Varnish that if it gets a HIT for that object, it
should convert it to a PASS/MISS (depending on the versions) and avoir
request coalescing. In that scenario too, the ttl is the time the object
will live in cache. ie. how long do you retain the memory that it's not
cacheable.

-- 
Guillaume Quintard

On Fri, Jul 21, 2017 at 12:09 AM, Girouard, Yanick <Yanick.Girouard at stm.info
> wrote:

> That's a good thought, but what would really be the impact of this setting
> if I've already set the ttl to a positive value after stripping all headers
> that would make Varnish consider the object as being uncacheable to begin
> with? Is there a case where it would be required?
>
>
> ________________________________
> De : Andrei <lagged at gmail.com>
> Envoyé : 20 juillet 2017 15:22
> À : Girouard, Yanick
> Cc : Reza Naghibi; varnish-misc at varnish-cache.org
> Objet : Re: Varnish and max-age=0
>
> Just a thought, if you're going to force an otherwise uncacheable request
> to be cached, you should probably: set beresp.uncacheable = false;
>
>
>
> On Thu, Jul 20, 2017 at 9:03 PM, Girouard, Yanick <
> Yanick.Girouard at stm.info<mailto:Yanick.Girouard at stm.info>> wrote:
> Hi Reza,
>
> Yes we are. Here's the default we apply. Those two subs are called in
> order in vcl_backend_response:
>
> /* REMOVE CACHE-CONTROL AND SURROGATE-CONTROL FROM BACKEND *
> ***********************************************************/
> sub stm_backend_resp_unset_cache_control_headers {
>                 unset beresp.http.Surrogate-Control;
>                 unset beresp.http.Cache-Control;
>                 unset beresp.http.Expires;
> }
>
> /* DEFAULT ALL TO: TTL 30MIN + GRACE 15MIN *
> *******************************************/
> sub stm_backend_resp_expiration_default {
>                 set beresp.ttl = 30m;
>                 set beresp.grace = 15m;
> }
>
> That doesn't seem to have any impact when the backend responds with a
> Cache-Control: max-age=0 header.
>
> Any idea?
>
>
> De : Reza Naghibi [mailto:reza at varnish-software.com<mailto:reza at varnish-
> software.com>]
> Envoyé : jeudi 20 juillet 2017 13:58
> À : Girouard, Yanick <Yanick.Girouard at stm.info<mailto:Yanick.Girouard at stm.
> info>>
> Cc : varnish-misc at varnish-cache.org<mailto:varnish-misc at varnish-cache.org>
> Objet : Re: Varnish and max-age=0
>
> The TTL is calculated before entering vcl_backend_response. So eventhough
> you unset the Cache-Control header, the value of TTL will be calculated
> based on it. Are you setting a new value for beresp.ttl? You need to do
> that:
>
> sub vcl_backend_response
> {
>   unset beresp.http.Cache-Control;
>   set beresp.ttl = 120s;
> }
>
> --
> Reza Naghibi
> Varnish Software
>
> On Thu, Jul 20, 2017 at 1:44 PM, Girouard, Yanick <
> Yanick.Girouard at stm.info<mailto:Yanick.Girouard at stm.info>> wrote:
> Hi,
>
> We use Varnish to cache for multiple backends and need Varnish to always
> control what is cached despite what backends could respond. In other words,
> even if a backend sets Cache-Control headers to never cache its pages, we
> still want Varnish to cache them based on defined rules (i.e. certain URL
> patterns or hosts have different TTLs).
>
> We have recently realized that one of our backend always set the following
> header: Cache-Control: max-age=0, private, must-revalidate
>
> Our VCL unsets the Cache-Control header in vcl_backend_response and sets
> its own before delivering. By unsetting the Cache-Control header in
> vcl_backend_response I would expect Varnish to ignore the max-age=0 value
> and still cache the page as per our other rules, but it seems that the
> second it sees max-age=0 in the response header, that it makrs the object
> as not cacheable.
>
> Other than by changing the backend's response to never set max-age=0, is
> there a way to force Varnish to cach pages even if it returned max-age=0?
>
> Is this even by design or is it a bug?
>
> Thanks,
> Yanick Girouard
>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at varnish-cache.org<mailto:varnish-misc at varnish-cache.org>
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at varnish-cache.org<mailto:varnish-misc at varnish-cache.org>
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20170721/a5f11762/attachment.html>


More information about the varnish-misc mailing list