> Le 22 août 2019 à 14:40, Willy Tarreau <[email protected]> a écrit : > > On Thu, Aug 22, 2019 at 11:36:00AM +0200, Geoff Simmons wrote: > >> I suspect that there are other ways that the authority TLV can be useful >> for haproxy besides the specific Varnish case. Someone connecting via >> TLS, for example, might want to send the TLV to "override" the SNI for >> certain backends. > > It's definitely useful for other cases, which is why I'm interested in > seeing it addressed properly. Right now we do emit a few fields in the > PPv2 but we ignore them on receipt, which is a bit sad. For example, if > you use multi-process to chain two haproxy instances, one with TLS > offloading, passing to the next level using PPv2, you currently lose the > SNI information. With your change it would finally work. >
Indeed, the receipt part of PPv2 has been postponed until needed. With authority received from PPv2 (Geoff patch), i see use cases (one is to test configuration like chaining tow haproxy :-) ) To generalize the usage of authority, i will see a get_authority func in xprt_ops. With a ssl connection: return the sni (aka ssl authority). With a tcp connection: return the ppv2 authority. So a « send-proxy-v2 proxy-v2-options authority » server line will work in both cases. To override the authority, is like « sni » for server line, we could used « authority ». « send-proxy-v2 authority hdr(Host) proxy-v2-options authority » For server line with ssl, i thought that « authority » could replace « sni » but we can have both: « ssl sni hdr(Host),lower send-proxy-v2 authority hdr(Host) proxy-v2-options authority » Note: in my test « sni hdr(Host),lower » work but « sni var(req.host) » doesn’t (with http-request content set-var(req.host) hdr(host),lower ) What do you think? Manu
