Reintroduce a req.uncacheable flag

[Geoff Simmons]

On 5/28/21 17:50, Dridi Boukelmoune wrote:
> 
> First, we already have a relationship between bereq.uncacheable and
> bereq.uncacheable: the former implies the latter.

Presumably you meant to write that bereq.uncacheable implies
beresp.uncacheable.

My quick and superficial first reaction to the proposal -- I don't quite
have my head around what you would write in VCL if you do in fact want
to return early out of vcl_recv, and you want to say that the response
will be uncacheable.

You could set req.uncacheable to true, and also say return(pass), but it
feels like saying the same thing twice.

VCL could also have one but not the other: req.uncacheable=false and
return(pass), or req.uncacheable=true and return(lookup). Which one
determines whether a cache lookup is attempted or bypassed?

The combination req.uncacheable=true and return(lookup) in particular
feels like a contradiction. But if the point-oh release eliminates
return(pass) as you considered, isn't return(lookup) the only way to
return early out of vcl_recv, unless you're going to something like pipe
or synth or fail? If so, then is req.uncacheable=true, suggesting no
lookup, and then return(lookup) the only way to accomplish what
return(pass) does now?

I guess this is starting to sound like I'm critical of the idea, which I
didn't intend, because there may be good answers to all of these
questions. Just trying to get it sorted in my head.


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20210528/d39a4d08/attachment.bin>