I'll test the "setenv" approach soon.
I don't see a case were one would define a different check-sni or sni values from the "Host" header. I'm not even sure that differentiate "Host" header from SNI values is possible on softwares like Nginx or Apache. We should always use SNI & check-sni as the same value as the "Host" header value, which in many cases should be the same value as the FQDN from the server line. I also think SNI should be defaulted when using ssl over server backend. Check-sni should default to the same value as sni but re-writable. CDN providers like CloudFront or Akamai are using more and more SNI by blowing up prices on non-sni configurations (CloudFront bills 600$/month/vhost to avoid SNI) Vincent ________________________________ De : Willy Tarreau <[email protected]> Envoyé : mercredi 25 avril 2018 09:16 À : Jonathan Matthews Cc : GALLISSOT VINCENT; Lukas Tribus; [email protected] Objet : Re: Use SNI with healthchecks On Tue, Apr 24, 2018 at 06:50:13PM +0000, Jonathan Matthews wrote: > [Top post; fight me] Grrr.... > You could either read an environment variable inherited from outside the > process, or use "setenv" or "presetenv" as appropriate to DRY your config > out. > > The fine manual describes how you would refer to this envvar in section > 2.3, regardless of which of those options you use to set it. That's indeed a possibility. In Vincent's case I'm seeing that he uses the same name as the FQDN one. That makes me think we could possibly have a special check-sni value to use the FQDN from the server line. That would have the benefit of making it easier to place in a default-server statement. I just don't know how often it happens that the SNI used for checks has to match the FQDN declared in the configuration. Willy
