Mailing List Archive

On 01/23/2017 01:56 PM, Jan Hugo Prins | BetterBe wrote:
>
> Somewhere I found an old Trac Wiki document that describes
> something like this, but I can't figure out if this has been
> implemented or not.
> https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8

That
>
Wiki page is obsolete -- it was about an experimental branch that
was developed while Varnish 3 was the released version.

(Maybe we should delete the Wiki page, it's not the first time someone
has been led astray.)

Varnish has supported 304 responses to client requests with
If-Modified-Since/If-None-Match for as long as I've known about it
(going back to Varnish 2). Backend conditional requests have been
supported since Varnish 4.

However, by default that doesn't quite work as your flow chart
indicates, if I've understood it correctly. If the client request is
for a cached response with an unelapsed TTL, then Varnish delivers the
cached response unconditionally, without re-validating the response
with the backend. Conditional requests to backends are done for the
fetch after the TTL elapses.

That's the default, but I believe you can get your own VCL to
implement re-validation after cache hits. I haven't tried that myself
-- maybe someone reading the list has some working VCL they can share?


Best,
Geoff
--
** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstra?e 32
22301 Hamburg

Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753

http://uplex.de

Hi,

Short answer is : no, unless you want some very involved set.

BUT, what you can do is: let varnish work its magic, and just ban objects
based on ETAG when they become invalid.

--
Guillaume Quintard

On Mon, Jan 23, 2017 at 1:56 PM, Jan Hugo Prins | BetterBe <
jprins@betterbe.com> wrote:

> Hello,
>
> We are currently investigating the use of Varnish for our infrastructure.
> In the software we build, we depend on the If-None-Match header and the use
> of ETAG's.
> The API we have created creates mainly JSON objects, and they differ in
> size from a few hundreds of bytes to several megabytes. A lot of these JSON
> objects are perfectly suited for caching, until someone changes a parameter
> and this can happen at any moment. That is also why we keep a record of all
> ETAG's and we invalidate them when needed.
>
> What we would like to do is cache created JSON object in front of our
> production environment and when someone requests the same calculation that
> someone else has requested before and the ETAG is still valid, send out the
> cached object. But this basicly implies the following workflow:
>
>
>
> Somewhere I found an old Trac Wiki document that describes something like
> this, but I can't figure out if this has been implemented or not.
> https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?
> version=8
>
> Could someone tell me if the workflow I describe is possible? My first
> tests tell me that in the default setup it isn't working like this.
>
> Best regards,
> Jan Hugo Prins
>
>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc@varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>

What do you mean by "unless you want some very involved set"?
And sure, Varnish can ban objects when they become invalid, but then it
still needs to check the origin to see if the object is still valid.

Jan Hugo


On 01/23/2017 02:47 PM, Guillaume Quintard wrote:
> Hi,
>
> Short answer is : no, unless you want some very involved set.
>
> BUT, what you can do is: let varnish work its magic, and just ban
> objects based on ETAG when they become invalid.
>
> --
> Guillaume Quintard
>
> On Mon, Jan 23, 2017 at 1:56 PM, Jan Hugo Prins | BetterBe
> <jprins@betterbe.com <mailto:jprins@betterbe.com>> wrote:
>
> Hello,
>
> We are currently investigating the use of Varnish for our
> infrastructure. In the software we build, we depend on the
> If-None-Match header and the use of ETAG's.
> The API we have created creates mainly JSON objects, and they
> differ in size from a few hundreds of bytes to several megabytes.
> A lot of these JSON objects are perfectly suited for caching,
> until someone changes a parameter and this can happen at any
> moment. That is also why we keep a record of all ETAG's and we
> invalidate them when needed.
>
> What we would like to do is cache created JSON object in front of
> our production environment and when someone requests the same
> calculation that someone else has requested before and the ETAG is
> still valid, send out the cached object. But this basicly implies
> the following workflow:
>
>
>
> Somewhere I found an old Trac Wiki document that describes
> something like this, but I can't figure out if this has been
> implemented or not.
> https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8
> <https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8>
>
> Could someone tell me if the workflow I describe is possible? My
> first tests tell me that in the default setup it isn't working
> like this.
>
> Best regards,
> Jan Hugo Prins
>
>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc@varnish-cache.org <mailto:varnish-misc@varnish-cache.org>
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
> <https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc>
>
>

--

Met vriendelijke groet / Best regards,

Jan Hugo Prins
/Infra and Storage consultant/

BetterBe - Transforming automotive leasing worldwide
<https://www.betterbe.com>
Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
<tel:+31%20%280%29%2053%2048%2000%20694>
7547 AN Enschede *E* jprins@betterbe.com <mailto:jprins@betterbe.com>
CC no. 08097527
<https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
*M* +31 (0)6 26 358 951 <tel:+31%20%280%296%2026%20358%20951>
www.betterbe.com <https://www.betterbe.com>
BetterBe accepts no liability for the content of this email, or for the
consequences of any actions taken on the basis of the information
provided, unless that information is subsequently confirmed in writing.
If you are not the intended recipient you are notified that disclosing,
copying, distributing or taking any action in reliance on the contents
of this information is strictly prohibited.

*set up, sorry, fat fingers. I haven't studied the question in depth, but
i'm pretty sure you can bend varnish's arm and do what you ask, but that's
complicated.

Regarding your second question, Varnish doesn't need to check the origin if
the origin pushes the bans directly.

--
Guillaume Quintard

On Mon, Jan 23, 2017 at 3:05 PM, Jan Hugo Prins | BetterBe <
jprins@betterbe.com> wrote:

> What do you mean by "unless you want some very involved set"?
> And sure, Varnish can ban objects when they become invalid, but then it
> still needs to check the origin to see if the object is still valid.
>
> Jan Hugo
>
>
>
> On 01/23/2017 02:47 PM, Guillaume Quintard wrote:
>
> Hi,
>
> Short answer is : no, unless you want some very involved set.
>
> BUT, what you can do is: let varnish work its magic, and just ban objects
> based on ETAG when they become invalid.
>
> --
> Guillaume Quintard
>
> On Mon, Jan 23, 2017 at 1:56 PM, Jan Hugo Prins | BetterBe <
> jprins@betterbe.com> wrote:
>
>> Hello,
>>
>> We are currently investigating the use of Varnish for our infrastructure.
>> In the software we build, we depend on the If-None-Match header and the use
>> of ETAG's.
>> The API we have created creates mainly JSON objects, and they differ in
>> size from a few hundreds of bytes to several megabytes. A lot of these JSON
>> objects are perfectly suited for caching, until someone changes a parameter
>> and this can happen at any moment. That is also why we keep a record of all
>> ETAG's and we invalidate them when needed.
>>
>> What we would like to do is cache created JSON object in front of our
>> production environment and when someone requests the same calculation that
>> someone else has requested before and the ETAG is still valid, send out the
>> cached object. But this basicly implies the following workflow:
>>
>>
>>
>> Somewhere I found an old Trac Wiki document that describes something like
>> this, but I can't figure out if this has been implemented or not.
>> https://www.varnish-cache.org/trac/wiki/BackendConditionalRe
>> quests?version=8
>>
>> Could someone tell me if the workflow I describe is possible? My first
>> tests tell me that in the default setup it isn't working like this.
>>
>> Best regards,
>> Jan Hugo Prins
>>
>>
>>
>> _______________________________________________
>> varnish-misc mailing list
>> varnish-misc@varnish-cache.org
>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>>
>
>
> --
>
> Met vriendelijke groet / Best regards,
>
> Jan Hugo Prins
> *Infra and Storage consultant*
> [image: BetterBe - Transforming automotive leasing worldwide]
> <https://www.betterbe.com>
> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
> <+31%20%280%29%2053%2048%2000%20694>
> 7547 AN Enschede *E* jprins@betterbe.com
> CC no. 08097527
> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
> *M* +31 (0)6 26 358 951 <+31%20%280%296%2026%20358%20951> www.betterbe.com
> BetterBe accepts no liability for the content of this email, or for the
> consequences of any actions taken on the basis of the information provided,
> unless that information is subsequently confirmed in writing. If you are
> not the intended recipient you are notified that disclosing, copying,
> distributing or taking any action in reliance on the contents of this
> information is strictly prohibited.
>

Hi Jan,

You might want to consider using the libvmod-xkey and then having
backend changes just tell varnish to invalidate based on that secondary
key.

Cheers,

Craig



On 2017-01-23 06:56, Jan Hugo Prins | BetterBe wrote:
> Hello,
>
> We are currently investigating the use of Varnish for our
> infrastructure. In the software we build, we depend on the
> If-None-Match header and the use of ETAG's.
> The API we have created creates mainly JSON objects, and they differ
> in size from a few hundreds of bytes to several megabytes. A lot of
> these JSON objects are perfectly suited for caching, until someone
> changes a parameter and this can happen at any moment. That is also
> why we keep a record of all ETAG's and we invalidate them when needed.
>
>
> What we would like to do is cache created JSON object in front of our
> production environment and when someone requests the same calculation
> that someone else has requested before and the ETAG is still valid,
> send out the cached object. But this basicly implies the following
> workflow:


_______________________________________________
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc

You could vary on the Etag which will keep multiple Etag versions in cache
while allowing for 304 responses on each one:

---

vcl 4.0;

backend default
{
.host = "127.0.0.1";
.port = "80";
}

sub vcl_recv
{
if (req.http.If-None-Match) {
set req.http.ETag = req.http.If-None-Match;
}
}

sub vcl_backend_response
{
set beresp.http.Vary = "ETag";
}

---

I may have misunderstood the question, but your backend would have to
return the correct response matching upto the Etag.

--
Reza Naghibi
Varnish Software

On Mon, Jan 23, 2017 at 10:02 AM, Craig Servin <
cservin-varnish@cromagnon.com> wrote:

> Hi Jan,
>
> You might want to consider using the libvmod-xkey and then having backend
> changes just tell varnish to invalidate based on that secondary key.
>
> Cheers,
>
> Craig
>
>
>
> On 2017-01-23 06:56, Jan Hugo Prins | BetterBe wrote:
>
>> Hello,
>>
>> We are currently investigating the use of Varnish for our
>> infrastructure. In the software we build, we depend on the
>> If-None-Match header and the use of ETAG's.
>> The API we have created creates mainly JSON objects, and they differ
>> in size from a few hundreds of bytes to several megabytes. A lot of
>> these JSON objects are perfectly suited for caching, until someone
>> changes a parameter and this can happen at any moment. That is also
>> why we keep a record of all ETAG's and we invalidate them when needed.
>>
>>
>> What we would like to do is cache created JSON object in front of our
>> production environment and when someone requests the same calculation
>> that someone else has requested before and the ETAG is still valid,
>> send out the cached object. But this basicly implies the following
>> workflow:
>>
>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc@varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>

Actually, the VCL can be simplified greatly (I was expecting to change the
Etag while writing that):

---

sub vcl_backend_response
{
set beresp.http.Vary = "If-None-Match";
}

---

If there is a previous value of Vary, just append the If-None-Match.

--
Reza Naghibi
Varnish Software

On Mon, Jan 23, 2017 at 12:28 PM, Reza Naghibi <reza@varnish-software.com>
wrote:

> You could vary on the Etag which will keep multiple Etag versions in cache
> while allowing for 304 responses on each one:
>
> ---
>
> vcl 4.0;
>
> backend default
> {
> .host = "127.0.0.1";
> .port = "80";
> }
>
> sub vcl_recv
> {
> if (req.http.If-None-Match) {
> set req.http.ETag = req.http.If-None-Match;
> }
> }
>
> sub vcl_backend_response
> {
> set beresp.http.Vary = "ETag";
> }
>
> ---
>
> I may have misunderstood the question, but your backend would have to
> return the correct response matching upto the Etag.
>
> --
> Reza Naghibi
> Varnish Software
>
> On Mon, Jan 23, 2017 at 10:02 AM, Craig Servin <
> cservin-varnish@cromagnon.com> wrote:
>
>> Hi Jan,
>>
>> You might want to consider using the libvmod-xkey and then having backend
>> changes just tell varnish to invalidate based on that secondary key.
>>
>> Cheers,
>>
>> Craig
>>
>>
>>
>> On 2017-01-23 06:56, Jan Hugo Prins | BetterBe wrote:
>>
>>> Hello,
>>>
>>> We are currently investigating the use of Varnish for our
>>> infrastructure. In the software we build, we depend on the
>>> If-None-Match header and the use of ETAG's.
>>> The API we have created creates mainly JSON objects, and they differ
>>> in size from a few hundreds of bytes to several megabytes. A lot of
>>> these JSON objects are perfectly suited for caching, until someone
>>> changes a parameter and this can happen at any moment. That is also
>>> why we keep a record of all ETAG's and we invalidate them when needed.
>>>
>>>
>>> What we would like to do is cache created JSON object in front of our
>>> production environment and when someone requests the same calculation
>>> that someone else has requested before and the ETAG is still valid,
>>> send out the cached object. But this basicly implies the following
>>> workflow:
>>>
>>
>>
>> _______________________________________________
>> varnish-misc mailing list
>> varnish-misc@varnish-cache.org
>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>>
>
>

After reading this mail and doing a lot more searching in the
mailinglist and on the web, I think it is actually rather simple. At
least I think that I'm seeing the correct behaviour. I'm not sure
though, it could be that the response is first generated and that the
origin is only checked after the response has been send to the client.
What I have now in my vcl_backend_response is nothing more then:

sub vcl_backend_response {
if (beresp.http.Cache-Control ~ "must-revalidate") {
set beresp.ttl = 1s;
set beresp.keep = 3600s;
set beresp.grace = 3600s;
}
return (deliver);
}


Jan Hugo Prins



On 01/23/2017 02:20 PM, Geoff Simmons wrote:
> On 01/23/2017 01:56 PM, Jan Hugo Prins | BetterBe wrote:
>> Somewhere I found an old Trac Wiki document that describes
>> something like this, but I can't figure out if this has been
>> implemented or not.
>> https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8
> That
> Wiki page is obsolete -- it was about an experimental branch that
> was developed while Varnish 3 was the released version.
>
> (Maybe we should delete the Wiki page, it's not the first time someone
> has been led astray.)
>
> Varnish has supported 304 responses to client requests with
> If-Modified-Since/If-None-Match for as long as I've known about it
> (going back to Varnish 2). Backend conditional requests have been
> supported since Varnish 4.
>
> However, by default that doesn't quite work as your flow chart
> indicates, if I've understood it correctly. If the client request is
> for a cached response with an unelapsed TTL, then Varnish delivers the
> cached response unconditionally, without re-validating the response
> with the backend. Conditional requests to backends are done for the
> fetch after the TTL elapses.
>
> That's the default, but I believe you can get your own VCL to
> implement re-validation after cache hits. I haven't tried that myself
> -- maybe someone reading the list has some working VCL they can share?
>
>
> Best,
> Geoff

--

Met vriendelijke groet / Best regards,

Jan Hugo Prins
/Infra and Storage consultant/

BetterBe - Transforming automotive leasing worldwide
<https://www.betterbe.com>
Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
<tel:+31%20%280%29%2053%2048%2000%20694>
7547 AN Enschede *E* jprins@betterbe.com <mailto:jprins@betterbe.com>
CC no. 08097527
<https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
*M* +31 (0)6 26 358 951 <tel:+31%20%280%296%2026%20358%20951>
www.betterbe.com <https://www.betterbe.com>
BetterBe accepts no liability for the content of this email, or for the
consequences of any actions taken on the basis of the information
provided, unless that information is subsequently confirmed in writing.
If you are not the intended recipient you are notified that disclosing,
copying, distributing or taking any action in reliance on the contents
of this information is strictly prohibited.

Hello,

Indeed, with this vcl code, the object is checked asynchronously. So, if
the check fails, the user that triggered the check will have received the
outdated object. It may or may not be an issue depending on your use case.

Note that you can reduce the TTL further.

On Jan 24, 2017 03:11, "Jan Hugo Prins | BetterBe" <jprins@betterbe.com>
wrote:

> After reading this mail and doing a lot more searching in the mailinglist
> and on the web, I think it is actually rather simple. At least I think that
> I'm seeing the correct behaviour. I'm not sure though, it could be that the
> response is first generated and that the origin is only checked after the
> response has been send to the client. What I have now in my
> vcl_backend_response is nothing more then:
>
> sub vcl_backend_response {
> if (beresp.http.Cache-Control ~ "must-revalidate") {
> set beresp.ttl = 1s;
> set beresp.keep = 3600s;
> set beresp.grace = 3600s;
> }
> return (deliver);
> }
>
>
> Jan Hugo Prins
>
>
>
> On 01/23/2017 02:20 PM, Geoff Simmons wrote:
>
> On 01/23/2017 01:56 PM, Jan Hugo Prins | BetterBe wrote:
>
>
> Somewhere I found an old Trac Wiki document that describes
> something like this, but I can't figure out if this has been
> implemented or not. https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8
>
>
> That
>
> Wiki page is obsolete -- it was about an experimental branch that
> was developed while Varnish 3 was the released version.
>
> (Maybe we should delete the Wiki page, it's not the first time someone
> has been led astray.)
>
> Varnish has supported 304 responses to client requests with
> If-Modified-Since/If-None-Match for as long as I've known about it
> (going back to Varnish 2). Backend conditional requests have been
> supported since Varnish 4.
>
> However, by default that doesn't quite work as your flow chart
> indicates, if I've understood it correctly. If the client request is
> for a cached response with an unelapsed TTL, then Varnish delivers the
> cached response unconditionally, without re-validating the response
> with the backend. Conditional requests to backends are done for the
> fetch after the TTL elapses.
>
> That's the default, but I believe you can get your own VCL to
> implement re-validation after cache hits. I haven't tried that myself
> -- maybe someone reading the list has some working VCL they can share?
>
>
> Best,
> Geoff
>
>
> --
>
> Met vriendelijke groet / Best regards,
>
> Jan Hugo Prins
> *Infra and Storage consultant*
> [image: BetterBe - Transforming automotive leasing worldwide]
> <https://www.betterbe.com>
> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
> <+31%20%280%29%2053%2048%2000%20694>
> 7547 AN Enschede *E* jprins@betterbe.com
> CC no. 08097527
> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
> *M* +31 (0)6 26 358 951 <+31%20%280%296%2026%20358%20951> www.betterbe.com
> BetterBe accepts no liability for the content of this email, or for the
> consequences of any actions taken on the basis of the information provided,
> unless that information is subsequently confirmed in writing. If you are
> not the intended recipient you are notified that disclosing, copying,
> distributing or taking any action in reliance on the contents of this
> information is strictly prohibited.
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc@varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>

Is it possible in any way to force the check before the result is send
to the client?

Jan Hugo


On 01/24/2017 10:17 AM, Guillaume Quintard wrote:
> Hello,
>
> Indeed, with this vcl code, the object is checked asynchronously. So,
> if the check fails, the user that triggered the check will have
> received the outdated object. It may or may not be an issue depending
> on your use case.
>
> Note that you can reduce the TTL further.
>
> On Jan 24, 2017 03:11, "Jan Hugo Prins | BetterBe"
> <jprins@betterbe.com <mailto:jprins@betterbe.com>> wrote:
>
> After reading this mail and doing a lot more searching in the
> mailinglist and on the web, I think it is actually rather simple.
> At least I think that I'm seeing the correct behaviour. I'm not
> sure though, it could be that the response is first generated and
> that the origin is only checked after the response has been send
> to the client. What I have now in my vcl_backend_response is
> nothing more then:
>
> sub vcl_backend_response {
> if (beresp.http.Cache-Control ~ "must-revalidate") {
> set beresp.ttl = 1s;
> set beresp.keep = 3600s;
> set beresp.grace = 3600s;
> }
> return (deliver);
> }
>
>
> Jan Hugo Prins
>
>
>
> On 01/23/2017 02:20 PM, Geoff Simmons wrote:
>> On 01/23/2017 01:56 PM, Jan Hugo Prins | BetterBe wrote:
>>> Somewhere I found an old Trac Wiki document that describes
>>> something like this, but I can't figure out if this has been
>>> implemented or not.
>>> https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8
>>> <https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8>
>> That
>> Wiki page is obsolete -- it was about an experimental branch that
>> was developed while Varnish 3 was the released version.
>>
>> (Maybe we should delete the Wiki page, it's not the first time someone
>> has been led astray.)
>>
>> Varnish has supported 304 responses to client requests with
>> If-Modified-Since/If-None-Match for as long as I've known about it
>> (going back to Varnish 2). Backend conditional requests have been
>> supported since Varnish 4.
>>
>> However, by default that doesn't quite work as your flow chart
>> indicates, if I've understood it correctly. If the client request is
>> for a cached response with an unelapsed TTL, then Varnish delivers the
>> cached response unconditionally, without re-validating the response
>> with the backend. Conditional requests to backends are done for the
>> fetch after the TTL elapses.
>>
>> That's the default, but I believe you can get your own VCL to
>> implement re-validation after cache hits. I haven't tried that myself
>> -- maybe someone reading the list has some working VCL they can share?
>>
>>
>> Best,
>> Geoff
> --
>
> Met vriendelijke groet / Best regards, Jan Hugo Prins /Infra and
> Storage consultant/
>
> BetterBe - Transforming automotive leasing worldwide
> <https://www.betterbe.com>
> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
> <tel:+31%20%280%29%2053%2048%2000%20694>
> 7547 AN Enschede *E* jprins@betterbe.com
> <mailto:jprins@betterbe.com>
> CC no. 08097527
> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
> *M* +31 (0)6 26 358 951 <tel:+31%20%280%296%2026%20358%20951>
> www.betterbe.com <https://www.betterbe.com>
> BetterBe accepts no liability for the content of this email, or
> for the consequences of any actions taken on the basis of the
> information provided, unless that information is subsequently
> confirmed in writing. If you are not the intended recipient you
> are notified that disclosing, copying, distributing or taking any
> action in reliance on the contents of this information is strictly
> prohibited.
>
> _______________________________________________ varnish-misc
> mailing list varnish-misc@varnish-cache.org
> <mailto:varnish-misc@varnish-cache.org>
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
> <https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc>
>
--

Met vriendelijke groet / Best regards, Jan Hugo Prins /Infra and Storage
consultant/

BetterBe - Transforming automotive leasing worldwide
<https://www.betterbe.com>
Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
<tel:+31%20%280%29%2053%2048%2000%20694>
7547 AN Enschede *E* jprins@betterbe.com <mailto:jprins@betterbe.com>
CC no. 08097527
<https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
*M* +31 (0)6 26 358 951 <tel:+31%20%280%296%2026%20358%20951>
www.betterbe.com <https://www.betterbe.com>
BetterBe accepts no liability for the content of this email, or for the
consequences of any actions taken on the basis of the information
provided, unless that information is subsequently confirmed in writing.
If you are not the intended recipient you are notified that disclosing,
copying, distributing or taking any action in reliance on the contents
of this information is strictly prohibited.

Yes, you can:
- look for a match, and if you find one, note the etag, then restart. If no
match is found, fetch and deliver
- pass to the backend, if the etag doesn't match what you noted, ban the
object. Note the new etag, restart again
- if the new etag matches the one sent by the client, synthesize a 304,
otherwise deliver

But, is that really worth it? And is it easier than asking the backend to
purge?


--
Guillaume Quintard

On Tue, Jan 24, 2017 at 11:19 AM, Jan Hugo Prins | BetterBe <
jprins@betterbe.com> wrote:

> Is it possible in any way to force the check before the result is send to
> the client?
>
> Jan Hugo
>
>
>
> On 01/24/2017 10:17 AM, Guillaume Quintard wrote:
>
> Hello,
>
> Indeed, with this vcl code, the object is checked asynchronously. So, if
> the check fails, the user that triggered the check will have received the
> outdated object. It may or may not be an issue depending on your use case.
>
> Note that you can reduce the TTL further.
>
> On Jan 24, 2017 03:11, "Jan Hugo Prins | BetterBe" <jprins@betterbe.com>
> wrote:
>
>> After reading this mail and doing a lot more searching in the mailinglist
>> and on the web, I think it is actually rather simple. At least I think that
>> I'm seeing the correct behaviour. I'm not sure though, it could be that the
>> response is first generated and that the origin is only checked after the
>> response has been send to the client. What I have now in my
>> vcl_backend_response is nothing more then:
>>
>> sub vcl_backend_response {
>> if (beresp.http.Cache-Control ~ "must-revalidate") {
>> set beresp.ttl = 1s;
>> set beresp.keep = 3600s;
>> set beresp.grace = 3600s;
>> }
>> return (deliver);
>> }
>>
>>
>> Jan Hugo Prins
>>
>>
>>
>> On 01/23/2017 02:20 PM, Geoff Simmons wrote:
>>
>> On 01/23/2017 01:56 PM, Jan Hugo Prins | BetterBe wrote:
>>
>> Somewhere I found an old Trac Wiki document that describes
>> something like this, but I can't figure out if this has been
>> implemented or not. https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8
>>
>> That
>>
>> Wiki page is obsolete -- it was about an experimental branch that
>> was developed while Varnish 3 was the released version.
>>
>> (Maybe we should delete the Wiki page, it's not the first time someone
>> has been led astray.)
>>
>> Varnish has supported 304 responses to client requests with
>> If-Modified-Since/If-None-Match for as long as I've known about it
>> (going back to Varnish 2). Backend conditional requests have been
>> supported since Varnish 4.
>>
>> However, by default that doesn't quite work as your flow chart
>> indicates, if I've understood it correctly. If the client request is
>> for a cached response with an unelapsed TTL, then Varnish delivers the
>> cached response unconditionally, without re-validating the response
>> with the backend. Conditional requests to backends are done for the
>> fetch after the TTL elapses.
>>
>> That's the default, but I believe you can get your own VCL to
>> implement re-validation after cache hits. I haven't tried that myself
>> -- maybe someone reading the list has some working VCL they can share?
>>
>>
>> Best,
>> Geoff
>>
>> --
>>
>> Met vriendelijke groet / Best regards, Jan Hugo Prins *Infra and Storage
>> consultant*
>> [image: BetterBe - Transforming automotive leasing worldwide]
>> <https://www.betterbe.com>
>> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
>> <+31%20%280%29%2053%2048%2000%20694>
>> 7547 AN Enschede *E* jprins@betterbe.com
>> CC no. 08097527
>> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
>> *M* +31 (0)6 26 358 951 <+31%20%280%296%2026%20358%20951>
>> www.betterbe.com
>> BetterBe accepts no liability for the content of this email, or for the
>> consequences of any actions taken on the basis of the information provided,
>> unless that information is subsequently confirmed in writing. If you are
>> not the intended recipient you are notified that disclosing, copying,
>> distributing or taking any action in reliance on the contents of this
>> information is strictly prohibited.
>> _______________________________________________ varnish-misc mailing
>> list varnish-misc@varnish-cache.org https://www.varnish-cache.org/
>> lists/mailman/listinfo/varnish-misc
>
> --
>
> Met vriendelijke groet / Best regards, Jan Hugo Prins *Infra and Storage
> consultant*
> [image: BetterBe - Transforming automotive leasing worldwide]
> <https://www.betterbe.com>
> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
> <+31%20%280%29%2053%2048%2000%20694>
> 7547 AN Enschede *E* jprins@betterbe.com
> CC no. 08097527
> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
> *M* +31 (0)6 26 358 951 <+31%20%280%296%2026%20358%20951> www.betterbe.com
> BetterBe accepts no liability for the content of this email, or for the
> consequences of any actions taken on the basis of the information provided,
> unless that information is subsequently confirmed in writing. If you are
> not the intended recipient you are notified that disclosing, copying,
> distributing or taking any action in reliance on the contents of this
> information is strictly prohibited.
>

The problem is that asking the backend to purge is not an option because
that would not scale. If we would want to do that we need to know at the
backend how many varnish nodes the cluster has and how to reach them all
to purge the object effectively. Scaling the landscape would very soon
become a big nightmare.

The solution you provide here sounds like something that is programmable
by someone familiar with VCL. VCL is completely new to me so I will
start creating a flow diagram to see if I can understand that way what
you wrote down. If you have any example code that would help me in the
right direction I would be very happy.

Best regards,
Jan Hugo Prins


On 01/24/2017 11:35 AM, Guillaume Quintard wrote:
> Yes, you can:
> - look for a match, and if you find one, note the etag, then restart.
> If no match is found, fetch and deliver
> - pass to the backend, if the etag doesn't match what you noted, ban
> the object. Note the new etag, restart again
> - if the new etag matches the one sent by the client, synthesize a
> 304, otherwise deliver
>
> But, is that really worth it? And is it easier than asking the backend
> to purge?
>
>
> --
> Guillaume Quintard
>
> On Tue, Jan 24, 2017 at 11:19 AM, Jan Hugo Prins | BetterBe
> <jprins@betterbe.com <mailto:jprins@betterbe.com>> wrote:
>
> Is it possible in any way to force the check before the result is
> send to the client?
>
> Jan Hugo
>
>
>
> On 01/24/2017 10:17 AM, Guillaume Quintard wrote:
>> Hello,
>>
>> Indeed, with this vcl code, the object is checked asynchronously.
>> So, if the check fails, the user that triggered the check will
>> have received the outdated object. It may or may not be an issue
>> depending on your use case.
>>
>> Note that you can reduce the TTL further.
>>
>> On Jan 24, 2017 03:11, "Jan Hugo Prins | BetterBe"
>> <jprins@betterbe.com <mailto:jprins@betterbe.com>> wrote:
>>
>> After reading this mail and doing a lot more searching in the
>> mailinglist and on the web, I think it is actually rather
>> simple. At least I think that I'm seeing the correct
>> behaviour. I'm not sure though, it could be that the response
>> is first generated and that the origin is only checked after
>> the response has been send to the client. What I have now in
>> my vcl_backend_response is nothing more then:
>>
>> sub vcl_backend_response {
>> if (beresp.http.Cache-Control ~ "must-revalidate") {
>> set beresp.ttl = 1s;
>> set beresp.keep = 3600s;
>> set beresp.grace = 3600s;
>> }
>> return (deliver);
>> }
>>
>>
>> Jan Hugo Prins
>>
>>
>>
>> On 01/23/2017 02:20 PM, Geoff Simmons wrote:
>>> On 01/23/2017 01:56 PM, Jan Hugo Prins | BetterBe wrote:
>>>> Somewhere I found an old Trac Wiki document that describes
>>>> something like this, but I can't figure out if this has been
>>>> implemented or not.
>>>> https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8
>>>> <https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8>
>>> That
>>> Wiki page is obsolete -- it was about an experimental branch that
>>> was developed while Varnish 3 was the released version.
>>>
>>> (Maybe we should delete the Wiki page, it's not the first time someone
>>> has been led astray.)
>>>
>>> Varnish has supported 304 responses to client requests with
>>> If-Modified-Since/If-None-Match for as long as I've known about it
>>> (going back to Varnish 2). Backend conditional requests have been
>>> supported since Varnish 4.
>>>
>>> However, by default that doesn't quite work as your flow chart
>>> indicates, if I've understood it correctly. If the client request is
>>> for a cached response with an unelapsed TTL, then Varnish delivers the
>>> cached response unconditionally, without re-validating the response
>>> with the backend. Conditional requests to backends are done for the
>>> fetch after the TTL elapses.
>>>
>>> That's the default, but I believe you can get your own VCL to
>>> implement re-validation after cache hits. I haven't tried that myself
>>> -- maybe someone reading the list has some working VCL they can share?
>>>
>>>
>>> Best,
>>> Geoff
>> --
>>
>> Met vriendelijke groet / Best regards, Jan Hugo Prins /Infra
>> and Storage consultant/
>>
>> BetterBe - Transforming automotive leasing worldwide
>> <https://www.betterbe.com>
>> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
>> <tel:+31%20%280%29%2053%2048%2000%20694>
>> 7547 AN Enschede *E* jprins@betterbe.com
>> <mailto:jprins@betterbe.com>
>> CC no. 08097527
>> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
>> *M* +31 (0)6 26 358 951
>> <tel:+31%20%280%296%2026%20358%20951> www.betterbe.com
>> <https://www.betterbe.com>
>> BetterBe accepts no liability for the content of this email,
>> or for the consequences of any actions taken on the basis of
>> the information provided, unless that information is
>> subsequently confirmed in writing. If you are not the
>> intended recipient you are notified that disclosing, copying,
>> distributing or taking any action in reliance on the contents
>> of this information is strictly prohibited.
>>
>> _______________________________________________ varnish-misc
>> mailing list varnish-misc@varnish-cache.org
>> <mailto:varnish-misc@varnish-cache.org>
>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>> <https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc>
>>
>>
> --
>
> Met vriendelijke groet / Best regards, Jan Hugo Prins /Infra and
> Storage consultant/
>
> BetterBe - Transforming automotive leasing worldwide
> <https://www.betterbe.com>
> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
> <tel:+31%20%280%29%2053%2048%2000%20694>
> 7547 AN Enschede *E* jprins@betterbe.com
> <mailto:jprins@betterbe.com>
> CC no. 08097527
> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
> *M* +31 (0)6 26 358 951 <tel:+31%20%280%296%2026%20358%20951>
> www.betterbe.com <https://www.betterbe.com>
> BetterBe accepts no liability for the content of this email, or
> for the consequences of any actions taken on the basis of the
> information provided, unless that information is subsequently
> confirmed in writing. If you are not the intended recipient you
> are notified that disclosing, copying, distributing or taking any
> action in reliance on the contents of this information is strictly
> prohibited.
>
--

Met vriendelijke groet / Best regards, Jan Hugo Prins /Infra and Storage
consultant/

BetterBe - Transforming automotive leasing worldwide
<https://www.betterbe.com>
Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
<tel:+31%20%280%29%2053%2048%2000%20694>
7547 AN Enschede *E* jprins@betterbe.com <mailto:jprins@betterbe.com>
CC no. 08097527
<https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
*M* +31 (0)6 26 358 951 <tel:+31%20%280%296%2026%20358%20951>
www.betterbe.com <https://www.betterbe.com>
BetterBe accepts no liability for the content of this email, or for the
consequences of any actions taken on the basis of the information
provided, unless that information is subsequently confirmed in writing.
If you are not the intended recipient you are notified that disclosing,
copying, distributing or taking any action in reliance on the contents
of this information is strictly prohibited.

Sadly, I don't have time to work on this at the moment, I recommend you
have a look at the wiki
https://www.varnish-software.com/wiki/start/index.html and at the
documentation https://www.varnish-cache.org/docs/trunk/.

You have to understand that with this logic, when an object changes, you
still have to send a first, extra request to check its freshness.

--
Guillaume Quintard

On Tue, Jan 24, 2017 at 12:31 PM, Jan Hugo Prins | BetterBe <
jprins@betterbe.com> wrote:

> The problem is that asking the backend to purge is not an option because
> that would not scale. If we would want to do that we need to know at the
> backend how many varnish nodes the cluster has and how to reach them all to
> purge the object effectively. Scaling the landscape would very soon become
> a big nightmare.
>
> The solution you provide here sounds like something that is programmable
> by someone familiar with VCL. VCL is completely new to me so I will start
> creating a flow diagram to see if I can understand that way what you wrote
> down. If you have any example code that would help me in the right
> direction I would be very happy.
>
> Best regards,
> Jan Hugo Prins
>
>
> On 01/24/2017 11:35 AM, Guillaume Quintard wrote:
>
> Yes, you can:
> - look for a match, and if you find one, note the etag, then restart. If
> no match is found, fetch and deliver
> - pass to the backend, if the etag doesn't match what you noted, ban the
> object. Note the new etag, restart again
> - if the new etag matches the one sent by the client, synthesize a 304,
> otherwise deliver
>
> But, is that really worth it? And is it easier than asking the backend to
> purge?
>
>
> --
> Guillaume Quintard
>
> On Tue, Jan 24, 2017 at 11:19 AM, Jan Hugo Prins | BetterBe <
> jprins@betterbe.com> wrote:
>
>> Is it possible in any way to force the check before the result is send to
>> the client?
>>
>> Jan Hugo
>>
>>
>>
>> On 01/24/2017 10:17 AM, Guillaume Quintard wrote:
>>
>> Hello,
>>
>> Indeed, with this vcl code, the object is checked asynchronously. So, if
>> the check fails, the user that triggered the check will have received the
>> outdated object. It may or may not be an issue depending on your use case.
>>
>> Note that you can reduce the TTL further.
>>
>> On Jan 24, 2017 03:11, "Jan Hugo Prins | BetterBe" <jprins@betterbe.com>
>> wrote:
>>
>>> After reading this mail and doing a lot more searching in the
>>> mailinglist and on the web, I think it is actually rather simple. At least
>>> I think that I'm seeing the correct behaviour. I'm not sure though, it
>>> could be that the response is first generated and that the origin is only
>>> checked after the response has been send to the client. What I have now in
>>> my vcl_backend_response is nothing more then:
>>>
>>> sub vcl_backend_response {
>>> if (beresp.http.Cache-Control ~ "must-revalidate") {
>>> set beresp.ttl = 1s;
>>> set beresp.keep = 3600s;
>>> set beresp.grace = 3600s;
>>> }
>>> return (deliver);
>>> }
>>>
>>>
>>> Jan Hugo Prins
>>>
>>>
>>>
>>> On 01/23/2017 02:20 PM, Geoff Simmons wrote:
>>>
>>> On 01/23/2017 01:56 PM, Jan Hugo Prins | BetterBe wrote:
>>>
>>> Somewhere I found an old Trac Wiki document that describes
>>> something like this, but I can't figure out if this has been
>>> implemented or not. https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8
>>>
>>> That
>>>
>>> Wiki page is obsolete -- it was about an experimental branch that
>>> was developed while Varnish 3 was the released version.
>>>
>>> (Maybe we should delete the Wiki page, it's not the first time someone
>>> has been led astray.)
>>>
>>> Varnish has supported 304 responses to client requests with
>>> If-Modified-Since/If-None-Match for as long as I've known about it
>>> (going back to Varnish 2). Backend conditional requests have been
>>> supported since Varnish 4.
>>>
>>> However, by default that doesn't quite work as your flow chart
>>> indicates, if I've understood it correctly. If the client request is
>>> for a cached response with an unelapsed TTL, then Varnish delivers the
>>> cached response unconditionally, without re-validating the response
>>> with the backend. Conditional requests to backends are done for the
>>> fetch after the TTL elapses.
>>>
>>> That's the default, but I believe you can get your own VCL to
>>> implement re-validation after cache hits. I haven't tried that myself
>>> -- maybe someone reading the list has some working VCL they can share?
>>>
>>>
>>> Best,
>>> Geoff
>>>
>>> --
>>>
>>> Met vriendelijke groet / Best regards, Jan Hugo Prins *Infra and
>>> Storage consultant*
>>> [image: BetterBe - Transforming automotive leasing worldwide]
>>> <https://www.betterbe.com>
>>> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
>>> <+31%20%280%29%2053%2048%2000%20694>
>>> 7547 AN Enschede *E* jprins@betterbe.com
>>> CC no. 08097527
>>> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
>>> *M* +31 (0)6 26 358 951 <+31%20%280%296%2026%20358%20951>
>>> www.betterbe.com
>>> BetterBe accepts no liability for the content of this email, or for the
>>> consequences of any actions taken on the basis of the information provided,
>>> unless that information is subsequently confirmed in writing. If you are
>>> not the intended recipient you are notified that disclosing, copying,
>>> distributing or taking any action in reliance on the contents of this
>>> information is strictly prohibited.
>>> _______________________________________________ varnish-misc mailing
>>> list varnish-misc@varnish-cache.org https://www.varnish-cache.org/
>>> lists/mailman/listinfo/varnish-misc
>>
>> --
>>
>> Met vriendelijke groet / Best regards, Jan Hugo Prins *Infra and Storage
>> consultant*
>> [image: BetterBe - Transforming automotive leasing worldwide]
>> <https://www.betterbe.com>
>> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
>> <+31%20%280%29%2053%2048%2000%20694>
>> 7547 AN Enschede *E* jprins@betterbe.com
>> CC no. 08097527
>> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
>> *M* +31 (0)6 26 358 951 <+31%20%280%296%2026%20358%20951>
>> www.betterbe.com
>> BetterBe accepts no liability for the content of this email, or for the
>> consequences of any actions taken on the basis of the information provided,
>> unless that information is subsequently confirmed in writing. If you are
>> not the intended recipient you are notified that disclosing, copying,
>> distributing or taking any action in reliance on the contents of this
>> information is strictly prohibited.
>>
> --
>
> Met vriendelijke groet / Best regards, Jan Hugo Prins *Infra and Storage
> consultant*
> [image: BetterBe - Transforming automotive leasing worldwide]
> <https://www.betterbe.com>
> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
> <+31%20%280%29%2053%2048%2000%20694>
> 7547 AN Enschede *E* jprins@betterbe.com
> CC no. 08097527
> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
> *M* +31 (0)6 26 358 951 <+31%20%280%296%2026%20358%20951> www.betterbe.com
> BetterBe accepts no liability for the content of this email, or for the
> consequences of any actions taken on the basis of the information provided,
> unless that information is subsequently confirmed in writing. If you are
> not the intended recipient you are notified that disclosing, copying,
> distributing or taking any action in reliance on the contents of this
> information is strictly prohibited.
>

This can also be approached by sending the request to an intermediary
"fanout"/request duplication endpoint. That way, the backends will always
send the purge request to a single location, which then duplicates the
requests to the related varnish nodes/clusters.

On Tue, Jan 24, 2017 at 1:31 PM, Jan Hugo Prins | BetterBe <
jprins@betterbe.com> wrote:

> The problem is that asking the backend to purge is not an option because
> that would not scale. If we would want to do that we need to know at the
> backend how many varnish nodes the cluster has and how to reach them all to
> purge the object effectively. Scaling the landscape would very soon become
> a big nightmare.
>
> The solution you provide here sounds like something that is programmable
> by someone familiar with VCL. VCL is completely new to me so I will start
> creating a flow diagram to see if I can understand that way what you wrote
> down. If you have any example code that would help me in the right
> direction I would be very happy.
>
> Best regards,
> Jan Hugo Prins
>
>
> On 01/24/2017 11:35 AM, Guillaume Quintard wrote:
>
> Yes, you can:
> - look for a match, and if you find one, note the etag, then restart. If
> no match is found, fetch and deliver
> - pass to the backend, if the etag doesn't match what you noted, ban the
> object. Note the new etag, restart again
> - if the new etag matches the one sent by the client, synthesize a 304,
> otherwise deliver
>
> But, is that really worth it? And is it easier than asking the backend to
> purge?
>
>
> --
> Guillaume Quintard
>
> On Tue, Jan 24, 2017 at 11:19 AM, Jan Hugo Prins | BetterBe <
> jprins@betterbe.com> wrote:
>
>> Is it possible in any way to force the check before the result is send to
>> the client?
>>
>> Jan Hugo
>>
>>
>>
>> On 01/24/2017 10:17 AM, Guillaume Quintard wrote:
>>
>> Hello,
>>
>> Indeed, with this vcl code, the object is checked asynchronously. So, if
>> the check fails, the user that triggered the check will have received the
>> outdated object. It may or may not be an issue depending on your use case.
>>
>> Note that you can reduce the TTL further.
>>
>> On Jan 24, 2017 03:11, "Jan Hugo Prins | BetterBe" <jprins@betterbe.com>
>> wrote:
>>
>>> After reading this mail and doing a lot more searching in the
>>> mailinglist and on the web, I think it is actually rather simple. At least
>>> I think that I'm seeing the correct behaviour. I'm not sure though, it
>>> could be that the response is first generated and that the origin is only
>>> checked after the response has been send to the client. What I have now in
>>> my vcl_backend_response is nothing more then:
>>>
>>> sub vcl_backend_response {
>>> if (beresp.http.Cache-Control ~ "must-revalidate") {
>>> set beresp.ttl = 1s;
>>> set beresp.keep = 3600s;
>>> set beresp.grace = 3600s;
>>> }
>>> return (deliver);
>>> }
>>>
>>>
>>> Jan Hugo Prins
>>>
>>>
>>>
>>> On 01/23/2017 02:20 PM, Geoff Simmons wrote:
>>>
>>> On 01/23/2017 01:56 PM, Jan Hugo Prins | BetterBe wrote:
>>>
>>> Somewhere I found an old Trac Wiki document that describes
>>> something like this, but I can't figure out if this has been
>>> implemented or not. https://www.varnish-cache.org/trac/wiki/BackendConditionalRequests?version=8
>>>
>>> That
>>>
>>> Wiki page is obsolete -- it was about an experimental branch that
>>> was developed while Varnish 3 was the released version.
>>>
>>> (Maybe we should delete the Wiki page, it's not the first time someone
>>> has been led astray.)
>>>
>>> Varnish has supported 304 responses to client requests with
>>> If-Modified-Since/If-None-Match for as long as I've known about it
>>> (going back to Varnish 2). Backend conditional requests have been
>>> supported since Varnish 4.
>>>
>>> However, by default that doesn't quite work as your flow chart
>>> indicates, if I've understood it correctly. If the client request is
>>> for a cached response with an unelapsed TTL, then Varnish delivers the
>>> cached response unconditionally, without re-validating the response
>>> with the backend. Conditional requests to backends are done for the
>>> fetch after the TTL elapses.
>>>
>>> That's the default, but I believe you can get your own VCL to
>>> implement re-validation after cache hits. I haven't tried that myself
>>> -- maybe someone reading the list has some working VCL they can share?
>>>
>>>
>>> Best,
>>> Geoff
>>>
>>> --
>>>
>>> Met vriendelijke groet / Best regards, Jan Hugo Prins *Infra and
>>> Storage consultant*
>>> [image: BetterBe - Transforming automotive leasing worldwide]
>>> <https://www.betterbe.com>
>>> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
>>> <+31%20%280%29%2053%2048%2000%20694>
>>> 7547 AN Enschede *E* jprins@betterbe.com
>>> CC no. 08097527
>>> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
>>> *M* +31 (0)6 26 358 951 <+31%20%280%296%2026%20358%20951>
>>> www.betterbe.com
>>> BetterBe accepts no liability for the content of this email, or for the
>>> consequences of any actions taken on the basis of the information provided,
>>> unless that information is subsequently confirmed in writing. If you are
>>> not the intended recipient you are notified that disclosing, copying,
>>> distributing or taking any action in reliance on the contents of this
>>> information is strictly prohibited.
>>> _______________________________________________ varnish-misc mailing
>>> list varnish-misc@varnish-cache.org https://www.varnish-cache.org/
>>> lists/mailman/listinfo/varnish-misc
>>
>> --
>>
>> Met vriendelijke groet / Best regards, Jan Hugo Prins *Infra and Storage
>> consultant*
>> [image: BetterBe - Transforming automotive leasing worldwide]
>> <https://www.betterbe.com>
>> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
>> <+31%20%280%29%2053%2048%2000%20694>
>> 7547 AN Enschede *E* jprins@betterbe.com
>> CC no. 08097527
>> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
>> *M* +31 (0)6 26 358 951 <+31%20%280%296%2026%20358%20951>
>> www.betterbe.com
>> BetterBe accepts no liability for the content of this email, or for the
>> consequences of any actions taken on the basis of the information provided,
>> unless that information is subsequently confirmed in writing. If you are
>> not the intended recipient you are notified that disclosing, copying,
>> distributing or taking any action in reliance on the contents of this
>> information is strictly prohibited.
>>
> --
>
> Met vriendelijke groet / Best regards, Jan Hugo Prins *Infra and Storage
> consultant*
> [image: BetterBe - Transforming automotive leasing worldwide]
> <https://www.betterbe.com>
> Auke Vleerstraat 140 E *T* +31 (0) 53 48 00 694
> <+31%20%280%29%2053%2048%2000%20694>
> 7547 AN Enschede *E* jprins@betterbe.com
> CC no. 08097527
> <https://www.kvk.nl/orderstraat/product-kiezen/?kvknummer=080975270000>
> *M* +31 (0)6 26 358 951 <+31%20%280%296%2026%20358%20951> www.betterbe.com
> BetterBe accepts no liability for the content of this email, or for the
> consequences of any actions taken on the basis of the information provided,
> unless that information is subsequently confirmed in writing. If you are
> not the intended recipient you are notified that disclosing, copying,
> distributing or taking any action in reliance on the contents of this
> information is strictly prohibited.
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc@varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>