Support for If-None-Match header.

[Guillaume Quintard]

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