On 9/26/19 11:43, Emmanuel Hocdet wrote:
> 
> Proposal reworking after playing with « authority » and look at how « src »/« 
> dst » are working.
> 
> Authority » can come from transport layer (TLS), ProxyV2 TLV or « 
> set-authority ».
> « src/dst » is set from transport layer (TCP), overwrite by Proxy-protocol 
> and « set-{src,dst} »
> I propose to do the same for « authority » sample fetch:
> pick « authority » from « set-authority, Proxy-protocol, and transport layer 
> (in this order)
>  . It’s already what authority is in « proxy-v2-options authority"
>   => « fc_pp_authority » disappears in favour of the generic « authority » 
> sample fetch

Some thoughts that come to mind -- it sounds like there will be a bit of
"magic" at work here, so will it be transparent to the user? Will users
find that the authority field is being set and they wonder where it came
from?

And I wonder if there are situations in which someone will want to
specifically choose one source of truth for authority over the other.
Suppose an incoming connection uses TLS with an SNI, and the peer
component also sends an authority TLV via Proxy. Is a situation
imaginable in which only one of them is getting it "right", for the
purposes of haproxy, and the config author wants to be sure to catch
that one only?

To be honest I'm not sure, I'm still a bit of an "outsider" around here,
and other readers of the list will have better intuitions about what's
common and possible. So I'd be happy to be assured that this will be fine.

Incidentally, I too have not seen a patch on this thread since September
10th (not sure if you meant to send a new one today).


Best,
Geoff
-- 
** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstraße 32
22301 Hamburg

Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753

http://uplex.de

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to