Support for If-None-Match header.

Tue Jan 24 15:13:10 CET 2017

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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 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/20170124/8bd35b30/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 10832 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20170124/8bd35b30/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 10832 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20170124/8bd35b30/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: betterbe_handtekening_v1_logo.png
Type: image/png
Size: 10832 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20170124/8bd35b30/attachment-0005.png>