varnishd command line syntax for pluggable acceptors? - Githubissues

varnishcache / varnish-cache

Varnish Cache source code repository

https://www.varnish-cache.org

Other

3.71k stars 378 forks source link

varnishd command line syntax for pluggable acceptors? #4169

Open nigoroll opened 2 months ago

nigoroll commented 2 months ago

Working on a continuation of #3976 the question arose which command line syntax we want for pluggable acceptors. I see two basic options:

backwards compatible -a

  -a [name=][kind,][listen_address[,PROTO|,option=value,...]]

here, kind would be the acceptor kind, so a valid use case would be -a foo=tcp,127.0.0.1:4444

new, additional argument, for example -A, where kind is mandatory

  -a [name=]kind[,listen_address[,PROTO|,option=value,...]]

I like to avoid adding new options, but the first option comes with some ambiguity:

foo,bar

could mean

kind=foo, listen_address=bar

or

listen_address=foo, PROTO=bar

and, because of backwards compatibility, the error message might be confusing:

$ /tmp/sbin/varnishd -a foo=xxx,@foo -b @A -n /tmp/t
Error: Unknown protocol '@foo'

This can be tried out here: https://github.com/nigoroll/varnish-cache/commit/fe32476e7f8a1b4bf1ac2012670185cb210ad163

nigoroll commented 2 months ago

bugwash: phk is for not adding -a processing for VEXTs. He suggests a varnish.cf file which would allow for per-extension acceptors (which I appreciate!) and we would probably also need some -Eext.so,-a=...,-a=... or similar.

I still think that using -E to load extensions and then use a consistent -a and -s across all implementations is cleaner and would still prefer that.

nigoroll commented 3 weeks ago

I've settled on suggesting

[name=][%<kind>,][listen_address[,PROTO|,option=value,...]]

now. Reasons:

% is never the first character of a valid hostname for _listenaddress
% is highly unlikely as the first character of a unix domain socket
and if it is really intended as such, %uds,%path can be used

I did look at other alternatives, such as:

[name=][kind=<kind>,][listen_address[,PROTO|,option=value,...]] is ambiguous again
[name=][listen_address[,PROTO|,option=value,...]][,kind=<kind>] is bad because the option part should belong to the implementation

The implementation has been added to #4172 because plugging an acceptor is the basis for the test of this option.