[PATCH] proxy-protocol dst variables and proxy-proxy-protocol
bjornar.ness at gmail.com
Thu Nov 10 00:06:54 UTC 2016
2016-11-10 0:52 GMT+01:00 Maxim Dounin <mdounin at mdounin.ru>:
> On Wed, Nov 09, 2016 at 08:52:14PM +0100, Bjørnar Ness wrote:
>> On Nov 9, 2016 19:20, "Maxim Dounin" <mdounin at mdounin.ru> wrote:
> The implementation of PROXY protocol in nginx basically mimics
> what is available via X-Forwarded-For in http.
> Extending it with destination data may simplify some use cases.
> But it will also complicate things and will make other use cases
> less intuitive. It is also more or less clear that destination
> can be identified using a separate destination within nginx
It is true that the way proxy protocol support in nginx is currently
it discards half of the information available, and only gives us access to the
src part. I think this is strange "halfway" implementation anyway.
> As previously said, I'm not convinced this should be merged, as
> suggested changes have obvious downsides in common cases and only
> beneficial for very specific use cases.
When one uses proxy-protocol, one allways has something in front that
generates it. Using multiple configurations (can be _lots_) and having to
do configuration management/reloads/whatever, seems like going backwards.
The overhead of this impl if proxy protocol is not used in listed is
just a couple
ptr's, and can for sure be reduced at the cost of more complex code.
>> > 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.
> Current question is:
> What "listen ... proxy_protocol" should mean in case of mail. In
> other modules, it just means that PROXY protocol header is parsed
> and appropriate variables are available for use. It would be good
> to have similar meaning in mail, but there are realip module and
> no variables in mail.
But Auth module can get the variables passed via headers, which is
certainly a usecase, also, to be able to send same proxy protocol header out
as you get in, the proxy-proxy-protocol scenario, it needs to be
This will work seemlessly on both mail, http and stream when proxy-protocol is
enabled in both listen and outgoing, think of it as a "transparent
> In the stream module similar problem was resolved by not
> introducing "listen ... proxy_protocol" till variables support was
> added, and by adding realip module at the same time. May be there
> are better options.
> I certainly dislike what is currently suggested, that is, just
> passing an address provided via PROXY protocol to backends via
> Introducing PROXY protocol to backends instead of XCLIENT looks
> as a separate thing.
I think adding more support for XCLIENT these days is not needed, as the
software in common use today supports proxy protocol native.
More information about the nginx-devel