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