Support for If-None-Match header.

Jan Hugo Prins | BetterBe jprins at betterbe.com
Tue Jan 24 12:31:00 CET 2017


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 <mailto: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 <mailto: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
>>>>         <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 at betterbe.com
>>         <mailto:jprins at 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 at varnish-cache.org
>>         <mailto:varnish-misc at 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 at betterbe.com
>     <mailto:jprins at 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 at betterbe.com <mailto:jprins at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20170124/10f8ccb0/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/10f8ccb0/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/10f8ccb0/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/10f8ccb0/attachment-0005.png>


More information about the varnish-misc mailing list