Add the authority parameter to .director().

[slimhazard]

Previously this was always set to the value of the VRT_backend host header. That is still the default, but with the new parameter a different value may be set, or the parameter may be set to the empty string, to specify that no authority TLV should be sent.

[nigoroll]

I have the nagging feeling that I still need to think about this more, just some thoughts:

The share parameter exists to define under which circumstances connections can be reused. Historically, DIRECTOR was the only option: If different host names resulted in the same tcp endpoint, they would share that endpoint.

16576f0e796e56171c7478851c04a6989894e13e changed this because of basically two cases:

• For TLS, just because a hostname maps to an IP address in DNS does not mean it's good to be used for some other hostname for which DNS pints to the same address. This basically is the authority topic we are discussing here: We also want a TLS certificate to match the name.
• Similarly, (hosting) environments exist which, also for HTTP/1.1, assume that all requests on a single TCP connection are for the same hostname.

While, for the latter case, "sharing by host(name)" is adequate, I wonder if, for the former case, "sharing by authority" would actually be better.

Therefor, should we have a share = AUTHORITY option and make that the default for .via?

Somehow related, and in light of this question: While we probably would want to keep an authority parameter at the director level, I think that the more common use case would be to have it as a .backend() argument.

In my world, a common setup (by design, not necessarily in all cases) is to have just two directors:

new http = dynamic.director()
new https = dynamic.director(via = sslon, port = 443)

Then the usage pattern becomes

set bereq.backend = http.backend("http1.site");
# OR
set bereq.backend = https.backend("tls.site");

The way I understand this patch, the latter case would still work as before.

The way I understand the new use case, we now want to be able to do, say, a DNS lookup on "tls.site.cdn.com", but still require the certificate to be valid for authority "tls.site".

So should we support an optional authority argument?

set bereq.backend = https.backend("tls.site.cdn.com", authority="tls.site");

or would it make more sense to keep the semantics of the existing host argument as auhtority also and rather specify a different dns name?

set bereq.backend = https.backend("tls.site", dns="tls.site.cdn.com");

[SoerenSilkjaer]

Hi @nigoroll. I am trying to create a backend that uses tls, are the changes in this pr needed for that or is there already support for it in current release?

Edit: Nvm i found the answer in the documentation https://github.com/nigoroll/libvmod-dynamic/blob/762970fd0d208b6fa477d0f874fd14800a0b966c/src/vmod_dynamic.vcc#L522-L523

[nigoroll]

I think I have made up my mind, my opinion/judgement:

• I think there will not be many use cases for an authority argument as a dynamic.director() constructor argument, but we can have it as a default, similar to the host_header argument.
• The primary interface should be a .backend(authority=...) argument for these reasons:
  • consistency with the Varnish-Cache backend attribute
  • possibility to specify an empty authority argument to disable SNI
• The domain lookup key needs to be changed to include authority always. That is, .backend("foo.com") and .backend("cdn.foo.com", authority="foo.com") will return different directors.
• Consequently, backend sharing can stay at HOST.