On Tue, May 14, 2024, at 3:48 PM, Amaury Denoyelle wrote: > On Wed, May 08, 2024 at 11:43:11AM +0100, William Manley wrote: > > An attach-srv config line usually looks like this: > > tcp-request session attach-srv be/srv name ssl_c_s_dn(CN) > > while a rhttp server line usually looks like this: > > server srv rhttp@ sni req.hdr(host) > > The server sni argument is used as a key for looking up connection in the > > connection pool. The attach-srv name argument is used as a key for > > inserting connections into the pool. For it to work correctly they must > > match. There was a check that either both the attach-srv and server > > provide that key or neither does. > > It also checked that SSL and SNI was activated on the server. This is too > > strict. This patch removes that requirement. Now you can pass arbitrary > > expressions as the name expression. > > With this patch we also produce a more helpful and specific error message. > > I'm doing this as I want to use `fc_pp_unique_id` as the name. > > Arguably it would be easier to understand if instead of using `name` and > > `sni` for `attach-srv` and `server` rules it used the same term in both > > places - like "conn-pool-key" or something. That would make it clear that > > the two must match. But it's too late to change that now. > > [...] > > Many thanks for your new patch. I have just merged it with only small > adaptation in the commit message. Note that however I tried to use PROXY > protocol with reverse HTTP to test it, but it appears that for now it is > impossible due to several haproxy internal limitations.
Thanks for merging it. I've been using a somewhat complicated setup, with rhttp connecting (via a few other hops) to a `mode tcp` proxy which does SSL termination and adds the proxy header before connecting over localhost to the rhttp pool on the server. I'll describe our setup in a bit more detail in a future email. You'll be horrified ;) > The main issue is that send-proxy and other related options on a server > line used for reverse HTTP are simply ignored, thus you cannot connect > to a bind with accept-proxy. I managed to fix this, but this is not > enough as PROXY protocol in LOCAL mode seems to not work completely as > expected either... What is LOCAL mode? I couldn't see a mention of it in the manual. I found in my testing that: 1. The server (the one with `server srv rhttp@ sni req.hdr(host)`) requires `nbthread 1` to work 2. Conversely: the client (the one with `bind rhttp@`) wouldn't work with `nbthread 1` - the connections from the client to the server simply wouldn't be made in that configuration Thanks Will --- William Manley Stb-tester.com Stb-tester.com Ltd is a company registered in England and Wales. Registered number: 08800454. Registered office: 13B The Vale, London, W3 7SH, United Kingdom (This is not a remittance address.)
