> It definitely must match in HTTP. However there's nothing making it mandatory > to send HTTP checks, let alone a Host header field (eg: if sending a simple > HTTP/1.0 request). However I'm noting the comment, because once we're able > to more easily configure the HTTP checks, we could imagine that we'd always > use SNI when "sni" is configured on the server line and an http check is in > use.
That would be awesome ! > > I'm not even sure that differentiate "Host" header from SNI values is > > possible on softwares like Nginx or Apache. > It should not, that would be a violation of HTTP over TLS. > > We should always use SNI & check-sni as the same value as the "Host" header > > value, > Yes, when we have one :-) > > which in many cases should be the same value as the FQDN from the server > > line. > This is where it's not always the case. Very commonly you'll have the > individual server name (server1, server2, etc) and you need the application > Host header. Yes indeed, that's the point. We use HAProxy mainly to proxy traffic from devices that don't like url/domain changes (like ISP boxes) to CDNs providers so we rewrite a lot of things at HAProxy side (including Host). I totally understand that most HAProxy users need it to forward traffic as it is and therefore to keep SNI and other values from front clients requests. > > I also think SNI should be defaulted when using ssl over server backend. > We could possibly consider making it a default in a future version, indeed, > but only once we have the ability to automatically retrieve correct values. Would definitely be awesome! > > Check-sni should default to the same value as sni but re-writable. > Except that SNI comes from forwarded traffic and there's no forwarded traffic > with the checks to extract the information from. > > 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) > I can easily understand why they're doing this. IP addresses are becoming > rare and it's a shame that some sites continue to waste them. With the > rapid growth of SSL over the last few years, I can easily imagine that > many sites have started to request their own IP addresses for no really > valid reason (I believe that MSIE6 was the last browser not to support SNI > but I could be wrong). Absolutely, what for use of default sni also in haproxy would be royal ;) Vincent > Willy
