bereq.is_bgfetch? -- Guillaume Quintard
On Thu, Apr 12, 2018, 09:24 Danila Vershinin <[email protected]> wrote: > Couldn’t really find anything useful besides obj.hits which indirectly > tells us it’s a background fetch. So: > > sub vcl_deliver { > if (req.http.grace == "normal(limited)" && *obj.hits == 0* && > req.http.Varied-Header = 'value1') { > set req.http.Varied-Header = 'value2’; > unset req.http.grace; > return (restart); > } > } > > ? :) > > Best Regards, > Danila > > On 12 Apr 2018, at 00:24, Guillaume Quintard < > [email protected]> wrote: > > There's a beresp attribute for that last one (I'm on mobile, so I'm going > to point you to man vcl :-)) > > -- > Guillaume Quintard > > On Wed, Apr 11, 2018, 22:39 Danila Vershinin <[email protected]> wrote: > >> So I guess I’m looking into having one background fetch trigger another >> background fetch (to sequentially refresh different object variants). In >> this fashion: >> >> 1. Client PURGE request will do softpurge.softpurge(); return(restart); >> with GET method, etc. which will all lead to "return deliver()" in limited >> grace logic to fire background fetch . >> >> 2. Then in background fetch: >> → in its vcl_deliver() - the current object variation has already >> entered cache, so setting varied header to value2, removing grace limited >> flag and calling restart(). This way it should continue revalidation for >> the other object variant >> → we land inside limited grace logic again (as it’s a different object >> variant) and return deliver() again thus firing off second background fetch >> (which will refresh second object variant). >> >> So the standard grace logic + something like this: >> >> sub vcl_deliver { >> if (req.http.grace == "normal(limited)" && req.http.Varied-Header = >> 'value1') { >> set req.http.Varied-Header = 'value2’; >> unset req.http.grace; >> return (restart); >> } >> } >> >> However, it won’t work at least because req.http.grace flag will be set >> for both the background fetch and the request that kicked it off. (it will >> be there in vcl_deliver of both). >> Question is how can we tell if we are inside background fetch? >> >> Best Regards, >> Danila >> >> On 11 Apr 2018, at 12:37, Guillaume Quintard < >> [email protected]> wrote: >> >> Hi, >> >> That's indeed correct, a purge will kill all variations, and the restart >> only fetches one. >> >> The req.hash_always_miss trick however only kills/revalidate one >> variation. >> >> At this moment, we have no way to purge/revalidate all the object under >> one hash key. >> >> -- >> Guillaume Quintard >> >> On Wed, Apr 11, 2018 at 11:26 AM, Danila Vershinin <[email protected]> >> wrote: >> >>> Hi Guillaume, >>> >>> A bit puzzled on something. If we use Vary: by some header.. am I >>> correct that we need multiple restarts to refresh each object variation? >>> >>> Since the background fetch would only refresh the variation that matched >>> initial purge request. >>> >>> Sent from my iPhone >>> >>> On 9 Apr 2018, at 12:18, Guillaume Quintard < >>> [email protected]> wrote: >>> >>> Hi, >>> >>> You can purge then set the method to GET then restart. Would that work >>> for you? >>> >>> Other way is to use req.hash_always_miss that will only revalidate if we >>> are able to fetch a new object. >>> >>> -- >>> Guillaume Quintard >>> >>> On Sat, Apr 7, 2018 at 12:10 PM, Danila Vershinin <[email protected]> >>> wrote: >>> >>>> Hi, >>>> >>>> What I work with: >>>> >>>> * Grace mode configured to be 60 seconds when backend is healthy >>>> * Using softpurge module to adjust TTL to 0 upon PURGE. >>>> >>>> The whole idea is increasing chances that visitors will get cached page >>>> after cache was PURGEd for a page. >>>> >>>> Standard piece: >>>> >>>> sub vcl_hit { >>>> if (obj.ttl >= 0s) { >>>> # normal hit >>>> return (deliver); >>>> } >>>> >>>> if (std.healthy(req.backend_hint)) { >>>> # Backend is healthy. Limit age to 60s. >>>> if (obj.ttl + 60s > 0s) { >>>> set req.http.grace = "normal(limited)"; >>>> return (deliver); >>>> } else { >>>> return(fetch); >>>> } >>>> } else { >>>> # ... >>>> } >>>> } >>>> >>>> And use of softpurge: >>>> >>>> sub vcl_miss { >>>> if (req.method == "PURGE") { >>>> softpurge.softpurge(); >>>> return (synth(200, "Successful softpurge")); >>>> } >>>> } >>>> >>>> sub vcl_hit { >>>> if (req.method == "PURGE") { >>>> softpurge.softpurge(); >>>> return (synth(200, "Successful softpurge")); >>>> } >>>> } >>>> >>>> >>>> >>>> Current behaviour: >>>> >>>> * send PURGE for cached page >>>> * Visitor goes to the page within 60 seconds and sees a stale cached >>>> page (triggering background refresh) >>>> * Further visits to the page will show refreshed page >>>> >>>> What I’m looking for: >>>> >>>> Trigger the background refresh right after PURGE while still leveraging >>>> grace mode :) That is, serve stale cache for only as long as it takes to >>>> actually generate the new page, and not wait for 60 seconds: >>>> >>>> * upon PURGE: set TTL to 0 (softpurge) + trigger background page >>>> request (possible?) >>>> * serve stale cache only while the page is generated >>>> >>>> I could have adjusted the “healthy backend grace period” to lower than >>>> 60s, but I’m basically checking to see if it’s possible to refresh “nearly” >>>> immediately in this kind of setup. >>>> >>>> Hope I made any sense :) >>>> >>>> Best Regards, >>>> Danila >>>> >>>> >>>> _______________________________________________ >>>> varnish-misc mailing list >>>> [email protected] >>>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >>>> >>> >>> >> >> >
_______________________________________________ varnish-misc mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
