thoughts about vcl cleanup around (be)resp.body and abandon/synth

[Dridi Boukelmoune]

On Wed, Nov 30, 2016 at 9:44 AM, Nils Goroll <slink at schokola.de> wrote:
> On 29/11/16 21:45, Federico Schwindt wrote:
>> I will not object "unset beresp.body" but setting the body in the middle of
>> vcl_backend_response{} feels odd to me.
>
> This seems to be the item with the least consensus.
>
> For the use case of replacing the body while keeping headers, the alternative is
>
> - copy response headers to bereq or
>   - use a vmod to save them

I will merely point out that you can't iterate over a headers in VCL,
and you'd need a way to distinguish bereq headers from beresp headers
if you copy them in one place.

> - resurrect them in v_b_e
>
> While this is feasible, I sill don't understand why we would need a de-tour over
> v_b_e just to create a synthetic body.

The problem with using v_b_e is that you need to trick Varnish to get
there on purpose

It would work better like this:

- in v_b_r
  - some_vmod.save_headers(beresp) (with some priv_task-ness)
  - return synth or backend_synth(XXX)
- in a v_b_synth
  - check status is XXX
  - some_vmod.restore_headers(beresp)
  - set beresp.body

But as discussed on IRC yesterday after the initial use case was
reminded, I finally made up my mind and agreed it would make sense
having set beresp.body in v_b_r.

I also see a case for having synthetic (even cacheable if needed)
backend responses, eg via a vmod. This is doable today, but as I said
by tricking Varnish before the fetch and from v_b_r you can't jump
directly to v_b_e. Very convoluted for a simple need.

> Both need to abort the backend connection or drain the request in progress, the
> only difference would be if we end up with an empty ws non-empty object.

Ideally drain the response (you meant response?) because the backend
may not be a native h1/tcp one.

> P.S.: Actually this is something which worked in varnish2, where one could just
> call synthetic in vcl_fetch

Wut? There was a Varnish before 3.0?