[PATCH] proxy-protocol dst variables and proxy-proxy-protocol

[Bjørnar Ness]

On Nov 9, 2016 19:20, "Maxim Dounin" <mdounin at mdounin.ru> wrote:
>
> Hello!
>
> On Thu, Nov 03, 2016 at 08:37:04PM +0100, Bjørnar Ness wrote:
>
> > Maxim: what needs change to get this merged? Followup will be mail pp
> > support, which I saw a patch for today from somone else.
>
> If this was a question to me, then the answer is:
>
> I'm not convinced this should be merged.  For the use case of
> PROXY protocol bypass a more logical solution would be to avoid
> removing the PROXY protocol header at all.  If one needs to bypass
> it and extract the information at the same time, something similar
> to ssl preread as recently implemented in the stream module might
> be a better solution.

The usecase for getting access to the dst variables is that we have the:

external LB -> nginx -> foo

setup as mentioned earlier, and we want to take decisions based on the
destination inside nginx, this may for example be a multi-brand setup, where
the original destination address is a part of the query key to a database.
This will allow us to just do database changes, and nginx will immediately
be able to "see" for what destination this request was for.

The separate, but related usecase is the "proxy-proxy-protocol" usecase,
where the upstream also needs the original ip/port src/destination data for
logging or decisionmaking.

For this reason, I think it is practical to store the proxy protocol header as
a whole with ptr's in the connection struct, but I am fine with changing this
to inet_addr for example, will be more loc but a little less memory use.

> If you have some ideas on how to properly support PROXY protocol
> in mail - please comment on the relevant patch.

Reason for mentioning it here, is the mail proxy-protocol patch has the
functionality mentioned here as a dependency. Both exim and dovecot
understands proxy-protocol, and I want to pass it on after the auth is done,
hence proxy-proxy-protocol.

Regards,

--
Bjørnar