Reintroduce a req.uncacheable flag

[Dridi Boukelmoune]

Hi Geoff,

It's been a while, I hope you are doing well :)

On Fri, May 28, 2021 at 5:22 PM Geoff Simmons <geoff at uplex.de> wrote:
>
> 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.

Correct, a tragic copy-pasta accident and yet I managed to make a
silly but valid statement anyway \o/

> 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?

I didn't want to jump too soon into implementation details but I have
to dip a toe now :)

Let's ignore bereq.uncacheable since it's read-only and determined
strictly by what happened on the client side. You can decide to make a
beresp uncacheable but you can't undo it. My assumption is that we
would want the same for req.uncacheable where assigning true takes
effect and false does nothing.

> 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?

Consider the backend transitions today:

- return(deliver)
- return(pass[...])

You have an explicit transition and a general one that will be
influenced by beresp.uncacheable.

On the client side that would be the same:

- return(hash) => influenced by req.uncacheable
- return(pass)

> 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.

Well, critical doesn't imply against, and your reply shows that my
first message was lacking a bit of context.

I'm not suggesting to remove the pass transition on the client side,
but to add a flag to signal that a lookup attempt should be neutered.
I am however suggesting that the built-in VCL replaces return(pass)
transitions with raising the req.uncacheable flag. This would for
example allow you to keep your cookie handling in vcl_req_cookie even
if your POST request was made uncacheable earlier.

Next implementation details, req.uncacheable would be read-write in
vcl_recv and vcl_hash, and read-only everywhere else.

If you return(pass) from vcl_recv, you can expect req.uncaheable to be
true in vcl_pass, vcl_deliver and vcl_synth.

The req.uncacheable flag would be reset to false after a return(restart).

I hope this clarifies things a bit.

Cheers,
Dridi