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

Federico Schwindt fgsch at lodoss.net
Tue Nov 29 21:45:39 CET 2016


On Tue, Nov 29, 2016 at 3:30 PM, Nils Goroll <slink at schokola.de> wrote:

> [..]
> Suggestion:
>
> - retire synthetic and support (un)set (be)resp.body
>   (not directly related to the topic, but something we should do
>    for consistency)
>

set (be)resp.body is already supported, but restricted to vcl_backend_error
/ vcl_synth.
I did not retire it to maintain compatibility and because I'm was, and
still am, unclear as to what the future plans are wrt bodies.


> - add support for (un)set beresp.body to vcl_backend_response
>   if used:
>   -> short-term: silently abort the backend connection
>   -> better: discard-read the response body
>

I will not object "unset beresp.body" but setting the body in the middle of
vcl_backend_response{} feels odd to me.


> - add support for (un)set resp.body to vcl_deliver
>

Is this the same use case but for hits?
If so, I'm on the opinion of allowing to unset the body but not generating
one, same as above in the vcl_backend_response{} case.


> - rename vcl_backend_error to vcl_backend_synth to be consistent
>   with the client side
>

I'd object to this. I think the current name is fine and self-explanatory.


> - add status and reason to abandon which get pre-set for the call
>   to vcl_synth
>
>   503 as default
>

+1


> - add return(backend_synth(status, reason)) to vcl_backend_fetch
>   as an easy way to return synthetic content at backend request
>   time.
>

I'm all for adding return(error(code, reason)) to go to vcl_backend_error{}.
I think this subroutine should not be renamed.


> More thoughts:
>
> - if we want the (un)set beresp.body, should we maybe have
>
>         set beresp.body = fetch()
>
>   also?
>

I'd prefer to have a way to express the opposite, as in "unset beresp.body".



>   This would be the default if no other beresp.body action happend
>   in vcl_backend_response
>
> Thanks, Nils
>
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20161129/02b6aa66/attachment.html>


More information about the varnish-dev mailing list