varnishd command line syntax for pluggable acceptors?
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
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.
I've settled on suggesting
[name=][%<kind>,][listen_address[,PROTO|,option=value,...]]
now. Reasons:
-
%is never the first character of a valid hostname for listen_address -
%is highly unlikely as the first character of a unix domain socket - and if it is really intended as such,
%uds,%pathcan 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.