> Le 22 août 2019 à 14:40, Willy Tarreau <w...@1wt.eu> 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 
configuration like chaining tow haproxy :-) )
To generalize the usage of authority,  i will see a get_authority func in 
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 »

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?


Reply via email to