Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

varnishd command line syntax for pluggable acceptors? #4169

Open
nigoroll opened this issue Sep 5, 2024 · 1 comment
Open

varnishd command line syntax for pluggable acceptors? #4169

nigoroll opened this issue Sep 5, 2024 · 1 comment

Comments

@nigoroll
Copy link
Member

nigoroll commented Sep 5, 2024

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: nigoroll@8fcb921

@nigoroll
Copy link
Member Author

nigoroll commented Sep 9, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant