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 fetchSome 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
signature.asc
Description: OpenPGP digital signature
