[master] 5d8a6c001 For CLI commands forwarded indirectly to the worker (via mgt_cli_askchild() as opposed to directly through mcf_askchild()), a truncated CLI response is not a failure.

[Dridi Boukelmoune]

On Mon, Dec 2, 2019 at 10:10 PM Poul-Henning Kamp <phk at freebsd.org> wrote:
>
>
> commit 5d8a6c0012c05c2f095c3a59e9f1dbc89b9f2c55
> Author: Poul-Henning Kamp <phk at FreeBSD.org>
> Date:   Mon Dec 2 22:05:30 2019 +0000
>
>     For CLI commands forwarded indirectly to the worker (via
>     mgt_cli_askchild() as opposed to directly through mcf_askchild()),
>     a truncated CLI response is not a failure.
>
>     Fixes #3038

As explained in [3092] there is more to 3038, and in particular commands
going through VTE don't truncate as documented [*] in the varnishd manual:

> If the response exceeds this limit, the response code will be 201 instead
> of 200 and the last line will indicate the truncation.

The test case fails with either of the following changes:

> diff --git i/bin/varnishtest/tests/r03038.vtc w/bin/varnishtest/tests/r03038.vtc
> index ea942e6fe..fd35790dd 100644
> --- i/bin/varnishtest/tests/r03038.vtc
> +++ w/bin/varnishtest/tests/r03038.vtc
> @@ -19,7 +19,9 @@ varnish v1 -expect n_vcl_avail == 10
>  varnish v1 -cliok "param.set cli_limit 128b"
>
>  varnish v1 -clierr 201 "vcl.list"
> +varnish v1 -cliexpect "[response was truncated]"
>
>  varnish v1 -stop
>
>  varnish v1 -clierr 201 "vcl.list"
> +varnish v1 -cliexpect "[response was truncated]"

So in my opinion there is still work to be done in this area and keeping track
of the known CLI quirks should be done in a github issue.

Dridi

[3092] https://github.com/varnishcache/varnish-cache/pull/3092#issuecomment-560658131
[*] https://varnish-cache.org/docs/6.3/reference/varnishd.html#cli-limit